wpf - Internacionalizando la aplicación de escritorio dentro de un par de años... ¿Qué deberíamos hacer ahora?

winforms internationalization (6)

Agregaré para almacenar y manipular datos de cadena como Unicode (NVARCHAR en MS SQL).

Por lo tanto, estamos seguros de que llevaremos nuestro producto a nivel internacional y eventualmente tendremos que internacionalizarlo. ¿Cuánta internacionalización recomendaría que hagamos a medida que avanzamos?

Supongo que en otras palabras, ¿hay alguna internacionalización que sea fácil ahora pero puede ser mucho peor si dejamos que la base del código madure y eso no nos ralentizará mucho si decidimos comenzar a hacerlo ahora?

Tecnología utilizada: C #, WPF, WinForms

En mi humilde opinión, afirmar que algo va a suceder "en unos pocos años" se traduce literalmente como "esperamos algún día", lo que realmente significa "nunca". Aunque todavía leería varios tutoriales para asegurarme de que no comete ningún error horrendo. Hacer el correcto soporte de internacionalización ahora significará menos trabajo en el futuro, y una vez que se acostumbre a él, no tendrá ningún efecto real en la productividad actual. Pero si puede medir el objetivo en años, tal vez no valga la pena hacerlo en este momento.

He trabajado en dos proyectos que hicieron la internacionalización: una aplicación C # ASP.NET (que existía antes de unirme al proyecto) y una aplicación PHP (mi propio método fue mi propio método, utilizando un control de internacionalización gratuito y mi propia aplicación de administración).

Debe almacenar todo el texto (etiquetas, texto del botón, etc.) como datos dentro de una base de datos. Refiértalos con las teclas (prefiero usar las primeras 4 palabras, mayúsculas, los espacios convertidos en guiones bajos y no alfanuméricos eliminados) y cuando tenga un duplicado, añada un número al final. El beneficio de este método clave es que el programador tiene una comprensión bastante sólida del contenido del texto con sólo mirar la clave.

Escriba una utilidad para extraer los datos y compilar archivos de recursos .NET que agregue a su proyecto para compilarlos. Cree un archivo de recursos por separado para cada idioma. En su código, use la tecla para señalar la entrada correcta.

Me gustaría leer los documentos de MS sobre el tema: http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx

Algunas cosas básicas para evitar:

Nunca use software de traducción, contrate a un profesional o pasante que tome ese idioma en una universidad local.
nunca trate de crear texto agregando dos entradas existentes, porque la gramática difiere grandemente en cada idioma, esto nunca funcionará. Entonces, si tiene una cadena que dice "Hacer clic" y quiere una que diga "Haga clic ahora", no intente crear una configuración que combine dos entradas, o durante la traducción, copie la palabra para hacer clic y traduzca la palabra ahora. Trate cada cadena como una traducción totalmente nueva desde cero

Prepárelo ahora, antes de escribir todas las cadenas en la base de código en sí.

Todo después de ahora será demasiado tarde. ¡Es ahora o nunca!

Es cierto que es un esfuerzo extra para prepararse bien ahora, pero no hacerlo va a ser mucho más caro.

Si no sigue todas las pautas en los enlaces a continuación, al menos preste atención a los puntos 1, 2 y 7 del resumen, que son muy baratos de hacer ahora y que causan más dolor en mi experiencia.

Verifique estas pautas y compruebe usted mismo por qué es mejor comenzar ahora y tener todo preparado.

Pequeño extracto:

Mueva todos los recursos localizables a archivos DLL de solo recursos separados. Los recursos localizables incluyen elementos de interfaz de usuario como cadenas de caracteres, mensajes de error, cuadros de diálogo, menús y recursos de objetos incrustados. (Mover los recursos a una DLL después será un dolor)
No codifique cadenas o recursos de interfaz de usuario. (Si no se prepara, sabrá que codificará cadenas)
No coloque recursos no localizables en las DLL de solo recursos. Esto causa confusión para los traductores.
No utilice cadenas compuestas que estén compiladas en tiempo de ejecución a partir de frases concatenadas. Las cadenas compuestas son difíciles de localizar porque a menudo asumen un orden gramatical en inglés que no se aplica a todos los idiomas. (Después del diseño de la interfaz, cambiar frases es más difícil)
Evite construcciones ambiguas, como "Carpeta vacía", donde las cadenas se pueden traducir de forma diferente según las funciones gramaticales de los componentes de las cadenas. Por ejemplo, "vacío" puede ser un verbo o un adjetivo, y esto puede conducir a diferentes traducciones en idiomas como el italiano o el francés. (Mismo problema)
Evite el uso de imágenes e íconos que contengan texto en su aplicación. Son caros de localizar (Use texto renderizado sobre la imagen)
Deje suficiente espacio para la longitud de las cadenas para expandir en la interfaz de usuario. En algunos idiomas, las frases pueden requerir 50-75 por ciento más de espacio. (El mismo problema, si no lo planifica ahora, el rediseño es más caro)
Use la clase System.Resources.ResourceManager para recuperar recursos en función de la cultura.
Use Microsoft Visual Studio .NET para crear cuadros de diálogo de Windows Forms, para que puedan ser localizados usando el Editor de recursos de Windows Forms (Winres.exe). No codifique cuadros de diálogo de Windows Forms a mano.

La internacionalización permitirá que su producto sea utilizable en otros países, es fácil y debe hacerse desde el principio (de esta manera las personas de habla inglesa de todo el mundo pueden usar su software), esas 3 reglas lo llevarán la mayor parte del camino hasta allí:

Admite caracteres internacionales: utiliza solo tipos de datos Unicode en archivos y bases de datos.
Admita los formatos internacionales de fecha, hora y número: use CultureInfo.InvariantCulture cuando almacene datos en un archivo o en un almacenamiento legible por computadora, use CultureInfo.CurrentCulture cuando muestre datos o analice la información del usuario, nunca haga su propio análisis ni use ningún otro objeto cultural.
Los datos textuales ingresados por el usuario se deben considerar como un recuadro negro, no intente dividirlos en palabras o letras, especialmente cuando se lo muestre al usuario: diferentes idiomas tienen reglas de difracción y el sistema operativo sabe cómo mostrarlos de izquierda a texto correcto, no.

La localización está traduciendo el software a diferentes idiomas, esto es difícil y costoso, un buen comienzo es nunca codificar cadenas de caracteres y nunca crear oraciones con cadenas más pequeñas.

Si usa datos de prueba, use cadenas que no sean en inglés (p. Ej .: ruso, polaco, noruego, etc.). La codificación asoma es una pequeña cabeza fea en cada esquina. Si no está en sus propias bibliotecas, entonces en las externas.

Personalmente, estoy a favor del ruso porque aunque no hablo ni una palabra de ruso (a pesar del origen de mi nombre) tiene caracteres en el extranjero y requiere más espacio que el inglés y, por lo tanto, también prueba el espaciado.
No sé si eso es algo específico del idioma, o simplemente porque nuestro traductor ruso le gusta las cadenas detalladas.

Algunas preguntas para pensar ...

¿Cómo puede permitirse retrasar el envío de la versión en inglés de su aplicación para ahorrar un poco más en internacionalizar el costo?

¿Seguirás negociando si no consigues que el flujo de caja se envíe rápidamente a la versión en inglés?

¿Cómo va a tener la interfaz de usuario correcta, si no recibe comentarios rápidos de algunos clientes al respecto?

¿Con qué frecuencia reescribirá la UI antes de tener que internacionalizarla?

¿Los clientes de inglés desean poder personalizar cadenas en la interfaz de usuario, por ejemplo, no todo el mundo llama "nota de envío"?

Como gran parte del dolor de la internacionalización es asegurarse de no romper la versión en inglés, ¿es una mejor inversión la prueba automatizada de la interfaz de usuario?

Lo único que creo que siempre haré es: "No use cadenas compuestas que estén compiladas en tiempo de ejecución a partir de frases concatenadas" y, si lo hace, no disemine el código que crea una sola cadena sobre muchos métodos. .

Tener su interfaz de usuario automáticamente cambiar el tamaño (y el diseño) para hacer frente a la longitud de las etiquetas, etc le ahorrará mucho tiempo en los últimos años si puede hacerlo a bajo costo. Hay muchos juegos de control de terceros para formularios de Windows que le permiten etiquetar cuadros de texto, etc., sin tener que poner las etiquetas como controles separados.

Estoy empezando a internacionalizar una aplicación de WinForms, esperamos poder utilizar el "nombre" de cada control como la clave de búsqueda, sin tener que mover muchos archivos de recursos, etc. No siempre es tan difícil como crees al principio. ...