¿Globalizar una aplicación existente de Windows Forms?

Question

Tengo una aplicación de winforms existente desarrollada usando VS 2005 y .NET framework 2.0.

Ahora tenemos que globalizar esta aplicación. Los dos locales son alemán y japonés.

Sé que podemos usar la propiedad localize del formulario para crear recursos forma localizada y puede tener otros archivos de recursos para las cadenas utilizadas en los cuadros de mensaje, excepciones, etc ..

Quiero saber la mejor manera de globalizar una aplicación existente , debería establecer la propiedad localize en cada formulario o hay alguna herramienta que va a extraer los los nombres y control de etiqueta names..what consideraciones que deben tomarse para formatos de fecha, moneda, etc.

también hemos utilizado algunos composite cadenas en algunos lugares en el código para concatenar las cadenas de mensajes, ¿cómo se pueden localizar?

Migraremos la aplicación a VS 2008 y .net framework 3.5 antes de iniciar la actividad de globalización.

Answer 1

Solo he trabajado con idiomas LTR, y no he tocado el japonés. Con esto en mente, aquí están algunos de mis mejores prácticas de la parte superior de mi cabeza:

• Ponga todo lenguaje específico cadenas programáticas y fragmentos de cadena en un archivo .resx (me gusta usar un archivo .resx por cuadro de diálogo), luego invoque las cadenas utilizando las clases y propiedades generadas automáticamente. No debe haber cadenas específicas de idioma en el código (lo que significa que casi no hay cadenas en el código, punto). Un buen patrón es poner cadenas de formateo en .resx también, ya que la sintaxis de un idioma varía.
• Establezca la propiedad Localizable en True en todos sus formularios y realice cambios específicos del idioma allí directamente (use la propiedad Idioma).
• Diseñe sus formularios para que todo lo que muestre cadenas específicas del idioma tenga espacio adicional donde sea necesario (nota: el alemán es más largo que el inglés). OMI, los formularios no deberían tener que reorganizarse por completo para un cambio básico en el lenguaje; sin embargo, debe hacerse con un lenguaje como el japonés.
• Para controles como etiquetas que necesitan que su texto se establezca dinámicamente, configure el texto en el formulario para que sepa que es solo un marcador. Utilizo "##" para esto, que realmente se destaca. Evite configurar el texto en una "muestra" del texto dinámico, ya que nunca recordará qué controles se configuran dinámicamente con solo mirar el formulario.

Answer 2

Si está utilizando Visual Source Safe como su control de código fuente (esperemos que no eres), hagas lo que hagas, no añadir texto en japonés dentro de su propio código fuente. Aunque Visual Studio puede manejar archivos fuente Unicode, VSS no los maneja bien.

Trabajé en una aplicación que se tradujo al japonés, y la inclusión de japonés dentro del código fuente (para llamadas a una función tipo MessageBox) corrompió los archivos, y debido a que VSS está basado en diferencias, los archivos fueron corrompido todo el camino de regreso a las versiones originales registradas. Esta corrupción tomó la forma de la mayoría de los archivos de código que se convirtieron en un galimatías basado en caracteres japoneses, y se produjo porque VSS cambió partes de los archivos CS unicode (que usaban dos bytes por carácter) por un byte.

La reparación de estos archivos requirió una gran cantidad de trabajo manual, con mi jefe mirando por encima del hombro y gritando sobre lo condenados que estábamos, así que no hagas esto.

nuevo, aquí hay un par de otras preguntas StackOverflow sobre este tema:

Best way to implement multi-language/globalization in large .NET project

Best practice to make a multi language application in C#/WinForms?

Personalmente, prefiero un método más simple. Cree una lista en Excel o algo de cada texto en inglés de la aplicación que necesite traducir (controle las propiedades del texto, las cadenas para usar en las funciones de MessageBox, etc.) y envíe las hojas de cálculo a sus traductores. En su aplicación, llame a un método en el evento de carga de cada uno de sus formularios que recorre todos los controles del formulario y cambia sus propiedades de texto a los valores traducidos. Reemplace todas las llamadas a MessageBox con llamadas a una función intermedia que traduzca el texto que se mostrará, y luego llame a MessageBox con el texto traducido.

Usar los métodos de globalización integrados es mucho trabajo, porque tiene que crear manualmente cada forma globalizada y luego reemplazar manualmente todo el texto con las traducciones, y esta tarea requiere que el programador domine. El método que menciono se hace programáticamente y no requiere que el programador domine los idiomas traducidos.

Answer 3

Si desea que la comunidad lo localice, utilice un archivo XML externo. Mire http://www.codeplex.com/url2jpeg, este proyecto de fuente abierta está localizado de esta manera y usa Reflection para la localización automática de formularios.

Para una cadena, simplemente use la etiqueta oculta.

Answer 4

Es mejor establecer la propiedad de localización en cada formulario, que extraerá no solo las cadenas, sino también la geometría de los diversos componentes, en el archivo base .resx. Con los idiomas nominados, es bastante improbable que los tamaños originales de los componentes sean adecuados para la traducción.

Generalmente no se recomienda componer cadenas de fragmentos porque, en general, no se correlacionarán con el mismo patrón de fragmentos en un idioma diferente. El uso de cadenas formateadas (String.Format) para agregar valores, sí, pero es improbable que todo lo que dependa del orden gramatical y de las oraciones del idioma original encaje.