c++ - suministros - La mejor forma de diseñar para la localización de cadenas
nodos primarios y secundarios (7)
Esta es una pregunta general, abierta a las opiniones. He estado tratando de encontrar una buena forma de diseñar para la localización de recursos de cadena para una aplicación Windows MFC y utilidades relacionadas. Mi lista de deseos es:
- Debe conservar los literales de cadena en el código (en lugar de reemplazarlos con la macro #definir ID de recursos), de modo que los mensajes aún puedan leerse en línea
- Debe permitir recursos de cadena localizados (duh)
- No debe imponer restricciones de entorno de tiempo de ejecución adicionales (por ejemplo: dependencia de .NET, etc.)
- Debe tener una obstrucción mínima en el código existente (cuanta menos modificación, mejor)
- Debe ser depurable
- Debe generar archivos de recursos que sean editables por herramientas comunes (es decir, formato común)
- No debería usar bloques de comentarios de copiar / pegar para conservar cadenas literales en el código o cualquier otra cosa que cree el potencial para la desincronización
- Sería bueno permitir la comprobación estática (en tiempo de compilación) de que cada cadena "anotada" está en el archivo (s) de recursos.
- Sería bueno permitir la agrupación de cadenas de recursos en varios idiomas (para componentes en varios idiomas, por ejemplo: C ++ nativo y .NET)
Tengo una manera que cumple con todos mis deseos hasta cierto punto, excepto por la comprobación estática, pero he tenido que desarrollar un poco de código personalizado para lograrlo (y tiene limitaciones). Me pregunto si alguien ha resuelto este problema de una manera particularmente buena.
Editar: La solución que tengo actualmente tiene este aspecto:
ShowMessage( RESTRING( _T("Some string") ) );
ShowMessage( RESTRING( _T("Some string with variable %1"), sNonTranslatedStringVariable ) );
Luego tengo una utilidad personalizada para analizar las cadenas desde dentro de los bloques ''RESTRINGIR'' y ponerlos en un archivo .resx para la localización, y un objeto COM C # separado para cargarlos desde archivos de recursos localizados con respaldo. Si el objeto C # no está disponible (o no se puede cargar), recurro a la cadena en el código. La macro se expande a una clase de plantilla que llama al objeto COM y realiza el formateo, etc.
De todos modos, pensé que sería útil agregar lo que tengo ahora como referencia.
Como está abierto a las opiniones, así es como lo hago.
Mi archivo de texto localizado es un archivo de texto delimitado por tabulaciones simple que se puede cargar en Excel y editar. La primera columna es para definir y cada columna a la derecha es un idioma posterior, por ejemplo:
ID ENGLISH FRENCH GERMAN
STRING_YES YES OUI YA
STRING_NO NO NON NEIN
Luego, en mi archivo MAKE, se encuentra un paso de creación de cusom que genera un archivo strings.h y un strings.dat. En mi caso, construye una lista de enumeración para los identificadores de cadena y luego un archivo binario con desplazamientos para el texto. Como en mi aplicación el usuario puede cambiar el idioma en cualquier momento, lo tengo todo en la memoria, pero puede hacer que el preprocesador genere un archivo de salida diferente para cada idioma si es necesario.
Lo que me gusta de este diseño es que si faltara alguna cadena, obtendría un error de compilación, mientras que si se buscaran las cadenas en el tiempo de ejecución, es posible que no sepas una cadena faltante en una parte del código rara vez utilizada hasta más adelante.
Desea una utilidad avanzada que siempre quise escribir, pero nunca tuve tiempo de hacerlo. Si no encuentra una herramienta de este tipo, es posible que desee recurrir a mis clases de contenedor CMsg () y CFMsg () que permiten extraer fácilmente cadenas de la tabla de recursos. (CFMsg incluso proporciona una envoltura de un solo lienzo de FormatMessage. Y sí, en ausencia de esa herramienta que está buscando, mantener una copia de la cadena en el comentario es una buena solución. Con respecto a la desincronización del comentario, recuerde que los literales de cadena son muy raramente cambiado
http://www.codeproject.com/KB/string/stringtable.aspx
Por cierto, los programas nativos Win32 y .NET tienen una administración de almacenamiento de recursos totalmente diferente. Te resultará difícil encontrar una solución común para ambos.
En un proyecto que había localizado en más de 10 idiomas, puse todo lo que se iba a localizar en un único dll de recursos únicos. En el momento de la instalación, el usuario seleccionó qué dll se instaló con su aplicación.
Solo tuve que entregar el dll en inglés al equipo de localización. Me devolvieron una dll localizada por cada idioma que incluí en la compilación.
Sé que no es perfecto, pero funcionó.
La forma simple es usar solo ID de cadena en su código, sin cadenas literales. A continuación, puede producir diferentes versiones del archivo .rc para cada idioma y crear DLL de solo recursos o simplemente compilaciones de idiomas diferentes.
Hay un par de utilidades de shareware para ayudar a localizar el archivo rc que maneja el cambio de tamaño de elementos de diálogo para idiomas con palabras más largas y warnign sobre traducciones faltantes.
Un problema más complicado es el orden de las palabras, si tiene varios números en un printf que deben estar en un orden diferente para la gramática de otro idioma. Hay algunas clases de printf extendidas en el proyecto de código que le permiten especificar cosas como printf ("palabra% 1s y% 2s", var1, var2) para que pueda cambiar% 1s y% 2s si es necesario.
No sé mucho sobre cómo se hace normalmente en Windows, pero la forma en que se manejan las cadenas localizadas en el marco Cocoa de Apple funciona bastante bien. Tienen un archivo de formato de texto muy básico que puede enviar a un traductor y algunas macros de preprocesador para recuperar los valores de los archivos.
En su código, verá las cadenas en su idioma nativo, en lugar de identificadores opacos.
Su solución es bastante similar a la solución " gettext " de Unix / Linux. De hecho, no necesitaría escribir las rutinas de extracción.
No estoy seguro de por qué quiere que la macro _RESTRING maneje varios argumentos. Mi código (usando el soporte de wxWidgets para gettext) se ve así: MyString.Format(_("Some string with variable %ls"), _("variable")); . Es decir, String :: Format (...) obtiene dos argumentos traducidos individualmente. En retrospectiva, Boost :: Format hubiera sido mejor, pero también permitiría el boost::format(_("Some string with variable %1")) % _("variable");
(Usamos la macro _() para abreviar)
Usamos la cadena en inglés como ID.
Si falla la búsqueda desde el objeto de recurso internacional (cargado desde el dll de I18N instalado), de forma predeterminada, tendremos la cadena de ID.
El código se ve así:
doAction(I18N.get("Press OK to continue"));
Como parte de los procesos de compilación, tenemos una secuencia de comandos de Perl que analiza todas las fuentes de las constantes de cadena. Construye un archivo temporal de todas las cadenas en la aplicación y luego las compara con las cadenas de recursos en cada local para ver si existen. Cualquier cadena faltante genera un correo electrónico al equipo de traducción apropiado.
Podemos tener múltiples dll para cada local. El nombre de la dll se basa en RFC 3066
language [_territory] [. codeset] [@ modifier]
Intentamos extraer la configuración regional de la máquina y ser lo más específico posible al cargar el dll I18N pero retroceder a las variaciones locales menos específicas si la versión más específica no está presente.
Ejemplo:
En el Reino Unido: si el local era en_GB.UTF-8
(Uso el término dll libremente, no en el sentido específico de Windows).
Primero busque el dll I18N.en_GB.UTF-8 . Si este dll no existe, vuelva a I18N.en_GB . Si este dll no existe, retroceda a I18N.en si este dll no existe, caiga en I18N.default
La única excepción a esta regla es: chino simplificado (zh_CN) donde la reserva es inglés de EE. UU. (En_US). Si la máquina no es compatible con chino simplificado, es poco probable que sea compatible con chino completo.