Al menos en Linux y muchos otros sistemas POSIX, debería estar interesado en gettext(3) (y en los argumentos de posicionamiento en printf(3) , por ejemplo, %3$d en lugar de %d en la cadena de formato de control).

Entonces codificarás

 printf(gettext("here x is %d and y is %d"), x, y);

y eso es lo suficientemente común como para tener el hábito de

 #define _(X) gettext(X)

y código más tarde

 printf(_("here x is %d and y is %d"), x, y);

También querrá procesar catálogos de mensajes con msgfmt(1)

Encontrará varios documentos sobre internacionalización ( i18n ) y localización, por ejemplo, Debian Introducción a i18n . Lea también locale(7) . Y probablemente siempre debería usar UTF-8 hoy.

La ventaja de tales catálogos de mensajes (¡todo esto ya está disponible por defecto en los sistemas Linux!) es que la internacionalización ocurre en tiempo de ejecución . No hay razón para restringir que suceda en tiempo de compilación. Los catálogos de mensajes pueden (y a menudo lo son) traducidos por otras personas además de los desarrolladores. Tendrá directorios en su sistema de archivos (por ejemplo, en alguna memoria flash barata, como algún chip SD) que contengan estos.

Tenga en cuenta que la internacionalización y localización es un tema difícil (lea más documentación para comprender lo difícil que puede ser, una vez que quiera manejar idiomas no europeos), y la infraestructura de Linux lo ha diseñado bastante bien (probablemente mejor y más eficiente que lo que estás sugiriendo con tus macros). Y Qt y Gtk también tienen un amplio soporte para la internacionalización (basado en gettext , etc.).

Déjame aclarar esto: quieres saber que si las variables definidas por el preprocesador (en tu caso, relacionadas con i18n) se intercambiaran antes de la compilación, (a) tomarían la misma cantidad de memoria (entre la macro y no- versión macro) y (b) almacenarse en el mismo segmento de programa ?

La respuesta corta es (a) sí y (b) sí-ish .

Para la primera parte, esto es fácil. El preprocesador reemplaza el texto completo de las constantes definidas por el preprocesador con sus valores #define 'd antes de pasar al compilador. Entonces, para el compilador,

 #define SELECT_MENU "Please select menu" // ... SomeMethod(SELECT_MENU);

se lee como

 SomeMethod("Please select menu");

y, por lo tanto, será idéntico para todos los efectos, excepto en lo que le parece al programador.

Para la segunda parte, esto es un poco más complejo. Si tiene literales de cadena constantes en un programa C, se asignarán al segmento de datos del programa o (si se declaran como el contenido inicial de una matriz de caracteres de asignación char ) se construirán dinámicamente dentro del segmento de código del programa y se almacenarán en la pila o el montón, si no me equivoco (como se discutió en las respuestas a esta pregunta ). Esto depende de cómo se use la constante definida por el preprocesador en el programa .

Teniendo en cuenta lo que dije en la primera parte, si tiene char buffer[] = MY_CONSTANT; , es probable que se almacene como un asignador de espacio de pila e inicializador donde se usa en el programa, y aumentará el segmento de código (y posiblemente el BSS ). Si tiene someFunction(MY_CONSTANT); , o char* c_str = MY_CONSTANT; , entonces probablemente se almacenará en el segmento de datos y recibirá un puntero a esa área en tiempo de ejecución. Hay muchas maneras en que esto puede manifestarse en su programa real; tener las variables #define 'd no determina de manera confiable cómo se almacenarán en su programa compilado, aunque si se usan solo de ciertas maneras, entonces puede estar razonablemente seguro de dónde se almacenarán .

EDITAR Se modificó la primera mitad de la respuesta para abordar con precisión lo que se pregunta, gracias al comentario de @esm.

Para responder a la pregunta de si esto ocupará la misma cantidad de memoria y las cadenas se colocarán en la misma sección del programa para la versión en inglés sin macro cuando se usa la versión en inglés con macro, la respuesta es sí.

El preprocesador C (CPP) reemplazará todas las instancias de la macro con la cadena de idioma correcta para el idioma dado y después de la ejecución de CPP, será como si las macros nunca hubieran estado allí. Las cadenas aún se colocarán en la sección de datos de solo lectura del binario, suponiendo que sea compatible , como si no usara macros.

Entonces, para resumir, la versión en inglés con macros y la versión en inglés sin macros son las mismas en lo que respecta al compilador C, consulte el enlace