topics i18n docs djangoproject language-agnostic unicode localization internationalization

language-agnostic - https docs djangoproject com en 2.1 topics i18n



Internacionalización en tus proyectos (11)

Además de todos los consejos anteriores, recuerde que i18n no se trata solo de cambiar palabras por su equivalente en otros idiomas, especialmente para alfabetos en idiomas no latinos (coreano, árabe) escritos de derecha a izquierda, por lo que toda la interfaz de usuario tendrá que conformarse, como

  • Artículo 1
  • ítem 2
  • artículo 3

tendría que ser

texto árabe 1 -

texto árabe 2 -

texto árabe 3 -

(La lista de viñetas invertida no parece funcionar: P)

que puede ser una pesadilla de UI si su sistema tiene que aplicar cambios dinámicamente una vez que el usuario cambia el idioma que se está utilizando.

Otra cosa muy difícil es probar diferentes idiomas, no solo por la corrección de la palabra, pero dado que los lenguajes como el coreano generalmente tienen un tipo de letra más grande para sus personajes, esto puede llevar a errores específicos del idioma (como el texto "GUARDAR" en un botón el botón en sí para algún idioma).

¿Cómo implementó la internacionalización (i18n) en proyectos reales en los que ha trabajado?

Me interesé en hacer que el software fuera intercultural después de leer la famosa publicación de Joel, el desarrollador de software mínimo absoluto de Absolute Absolutely, Positively Must About Unicode y Character Sets (¡Sin excusas!) . Sin embargo, aún no he podido aprovechar esto en un proyecto real, además de asegurarme de usar cadenas Unicode siempre que sea posible. Pero hacer que todas tus cadenas sean Unicode y asegurarte de que comprendes con qué codificación está todo en lo que trabajas es solo la punta del iceberg i18n.

Todo lo que he trabajado hasta la fecha ha sido para uso de un grupo controlado de personas que hablan inglés, o simplemente no era algo en lo que teníamos que trabajar antes de impulsar el proyecto en vivo. Así que estoy buscando consejos o historias de guerra sobre cómo hacer que el software esté más localizado en proyectos del mundo real.

Algunas cosas divertidas:

  1. Tener una aplicación PHP y MySQL que funciona bien con alemán y francés, pero ahora necesita ser compatible con ruso y chino. Creo que paso esto a .net, ya que el soporte Unicode de PHP es, en mi opinión, no muy bueno. Claro, hacer malabarismos con utf8_de / encode o mbstring-functions es divertido. Casi tan divertido como visitar a Freddy Krüger de noche ...

  2. Al darse cuenta de que algunos idiomas son MUCHO más verbosos que otros. El alemán es MUCHO más prolijo que el inglés, y ver cómo la versión alemana destruye la interfaz de usuario porque se asignó muy poco espacio no fue divertido. Algunos productos ganaron algo de fama por sus formas creativas de evitarlo, con "Schw.Tr.d.Le.En.W." de Oblivion. siendo memorable :-)

  3. Jugando con formatos de fecha, ¡woohoo! Sí, realmente HAY personas en el mundo que usan formatos de fecha donde el día va en el medio. Mucho divertido tratando de descubrir lo que se supone que significa el 07/02/2008, solo porque algunos usuarios podrían creer que podría ser el 2 de julio ... Pero, de nuevo, ustedes en el estanque pueden creer lo mismo sobre los usuarios que ponen el mes en el medio :-P, especialmente porque en inglés, el 2 de julio suena mucho mejor que el 2 de julio, algo que no necesariamente se aplica a otros idiomas (es decir, en alemán, nunca dirías Juli 2, pero siempre Zweiter Juli). Uso 2008-02-07 siempre que sea posible. Está claro que significa 7 de febrero y se ordena correctamente, pero dd / mm vs. mm / dd puede ser un problema realmente difícil.

  4. Lo divertido de Anoter, formatos de números ! 10.000,50 vs 10,000.50 vs. 10 000,50 vs. 10''000,50 ... Esta es mi peor pesadilla en este momento, tener que soportar un ambiente multicultural pero no tener manera de saber con certeza qué formato de número tiene el usuario utilizará.

  5. Formal o informal. En algunos idiomas, hay dos maneras de dirigirse a las personas, de una manera formal y de una manera más informal. En inglés, solo dices "Tú", pero en alemán tienes que decidir entre el "Sie" formal y el "Du" informal, el mismo para el Tu / Vous francés. Por lo general, es una apuesta segura elegir la forma formal, pero esto se pasa por alto fácilmente.

  6. Calendarios En Europa, el primer día de la semana es el lunes, mientras que en los Estados Unidos es el domingo. Los widgets de calendario son agradables. Mostrar un calendario con el domingo a la izquierda y el sábado a la derecha con un usuario europeo no es tan bueno, los confunde.

Creo que todos los que trabajan en internacionalización deberían estar familiarizados con el Repositorio de Datos Locales Comunes, que ahora es un subproyecto de Unicode:

Repositorio de datos de configuración regional común

Esas personas están trabajando duro para establecer un recurso estándar para todo tipo de cuestiones i18n: moneda, nombres geográficos, toneladas de cosas. Cualquier proyecto que mantenga sus propios datos locales centrales dado que este proyecto existe es bastante loco, en mi humilde opinión.

Estaba escuchando un Podcast de Scott Hanselman esta mañana, donde habla sobre la internacionalización, especialmente las cosas realmente difíciles, como el turco (con sus cuatro i) y el tailandés. Además, Jeff Atwood tenía una post :

Ha pasado un tiempo, así que esto no es completo.

Juegos de caracteres

Unicode es genial, pero no puedes salirte con la tuya ignorando otros juegos de caracteres. El juego de caracteres predeterminado en Windows XP (inglés) es Cp1252. En la web, no sabe qué le enviará un navegador (aunque es de esperar que su contenedor se encargue de la mayor parte de esto). Y no se sorprenda si hay errores en la implementación que está utilizando. Los juegos de caracteres pueden tener interacciones interesantes con nombres de archivos cuando se mueven entre máquinas.

Traducción de cadenas

Los traductores son, en términos generales, no codificadores. Si envía un archivo fuente a un traductor, lo romperán. Las cadenas se deben extraer a los archivos de recursos (por ejemplo, archivos de propiedades en Java o DLL de recursos en Visual C ++). Los traductores deben recibir archivos difíciles de romper y herramientas que no les permitan romperlos.

Los traductores no saben de dónde provienen las cadenas en un producto. Es difícil traducir una cadena sin contexto. Si no proporciona una guía, la calidad de la traducción sufrirá.

Mientras que en el tema del contexto, puede ver la misma cadena "foo" aparecer varias veces y pensar que sería más eficiente tener todas las instancias en la IU apuntando al mismo recurso. Esta es una mala idea. Las palabras pueden ser muy sensibles al contexto en algunos idiomas.

Traducir cadenas cuesta dinero. Si lanza una nueva versión de un producto, tiene sentido recuperar las versiones anteriores. Tenga herramientas para recuperar cadenas de sus viejos archivos de recursos.

La concatenación de cadenas y la manipulación manual de cadenas se deben minimizar. Use las funciones de formato cuando corresponda.

Los traductores deben poder modificar las teclas rápidas. Ctrl + P está impreso en inglés; los alemanes usan Ctrl + D.

Si tiene un proceso de traducción que requiere que alguien corte y pegue cadenas manualmente en cualquier momento, está solicitando problemas.

Fechas, horarios, calendarios, moneda, formatos de números, zonas horarias

Estos pueden variar de un país a otro. Una coma puede usarse para indicar lugares decimales. Los tiempos pueden estar en notación de 24 horas. No todos usan el calendario gregoriano. Usted debe ser inequívoco, también. Si tiene cuidado de mostrar fechas como MM / DD / AAAA para los EE. UU. Y DD / MM / AAAA para el Reino Unido en su sitio web, las fechas son ambiguas a menos que el usuario sepa que lo ha hecho.

Especialmente moneda

Las funciones Locales proporcionadas en las bibliotecas de clase le darán el símbolo de moneda local, pero no puede pegar solo una libra (libra esterlina) o un símbolo de euro delante de un valor que da un precio en dólares.

Interfaces de usuario

El diseño debe ser dinámico. No solo es probable que las cadenas tengan el doble de longitud en la traducción, puede ser necesario invertir la UI completa (hebreo, árabe) para que los controles se ejecuten de derecha a izquierda. Y eso es antes de llegar a Asia.

Prueba previa a la traducción

  • Use el análisis estático de su código para localizar problemas. Como mínimo, aproveche las herramientas integradas en su IDE. (Los usuarios de Eclipse pueden ir a Ventana> Preferencias> Java> Compilador> Errores / Advertencias y verificar cadenas no externalizadas).
  • Prueba de humo simulando la traducción. No es difícil analizar un archivo de recursos y reemplazar cadenas con una versión pseudo traducida que dobla la longitud e inserta caracteres funky. No es necesario que hable un idioma para usar un sistema operativo extranjero. Los sistemas modernos deberían permitirle iniciar sesión como un usuario extranjero con cadenas traducidas y configuración local extranjera. Si está familiarizado con su sistema operativo, puede averiguar qué hace qué sin conocer una sola palabra del idioma.
  • Los mapas de teclado y las referencias de los juegos de caracteres son muy útiles.
  • La virtualización sería muy útil aquí.

Problemas no técnicos

A veces hay que ser sensible a las diferencias culturales (puede causar ofensa o incomprensión). Un error que a menudo se ve es el uso de banderas como una señal visual que elige el idioma o la geografía de un sitio web. A menos que desee que su software declare lados en la política global, esta es una mala idea. Si fueras francés y te ofrecieras la opción de inglés con la bandera de San Jorge (la bandera de Inglaterra es una cruz roja en un campo blanco), esto podría generar confusión para muchos hablantes de inglés. Supón que problemas similares surgirán con idiomas y países extranjeros. . Los iconos deben ser revisados ​​por relevancia cultural. ¿Qué significa un pulgar hacia arriba o una marca verde? El lenguaje debe ser relativamente neutral: dirigirse a los usuarios de una manera particular puede ser aceptable en una región, pero considerado grosero en otra.

Recursos

Los programadores de C ++ y Java pueden encontrar útil el sitio web de la UCI: http://www.icu-project.org/

Otro desafío será aceptar los comentarios de tus usuarios. En muchos casos, esto se ve facilitado por el procesamiento de entrada proporcionado por el sistema operativo, como IME en Windows, que funciona de forma transparente con widgets de texto comunes, pero esta función no estará disponible para todas las necesidades posibles.

Sugiero usar algo como 99translations.com para mantener sus traducciones. De lo contrario, no podrá saber qué traducciones están actualizadas en todos los idiomas.

Trabajé en un proyecto para mi empleador anterior que usaba .NET, y había un formato .resx incorporado que utilizamos. Básicamente teníamos un archivo que tenía todas las traducciones en el archivo .resx, y luego múltiples archivos con diferentes traducciones. La consecuencia de esto es que debe ser muy diligente para garantizar que todas las cadenas visibles en la aplicación se almacenen en .resx, y cada vez que se modifique debe actualizar todos los idiomas que admite.

Si te vuelves perezoso y no notificas a las personas a cargo de las traducciones, o si insertas cadenas sin pasar por tu sistema de localización, será una pesadilla intentarlo y solucionarlo más tarde. Del mismo modo, si la localización es una idea de último momento, será muy difícil establecerla. En pocas palabras, si no tiene todas las cadenas visibles almacenadas externamente en un lugar estándar, será muy difícil encontrar todo lo que necesita ser localizado.

Otra nota, muy estrictamente evitar la concatenación de cadenas visibles directamente, como

String message = "The " + item + " is on sale!";

En cambio, debes usar algo como

String message = String.Format("The {0} is on sale!", item);

La razón de esto es que diferentes idiomas a menudo ordenan las palabras de manera diferente, y concatenando cadenas directamente necesitarán una nueva compilación para arreglar, pero si usaste algún tipo de mecanismo de reemplazo de cadenas como el anterior, puedes modificar tu archivo .resx (o cualquier localización) archivos que usa) para el idioma específico que necesita reordenar las palabras.

Una cosa que nadie ha mencionado aún es la de una parte cautelosa como "La unidad se producirá en 5 días" o "El lunes algo sucede". donde 5 y lunes cambiarán dependiendo del estado. No es una buena idea dividirlos en dos y concatenarlos. Con solo una parte variable y buena documentación, puede salirse con la suya, con dos partes diferentes habrá algún lenguaje que prefiera cambiar el orden de las mismas.

Una de las cosas más divertidas para descubrir: la letra cursiva y el texto en negrita makrup no funcionan con caracteres CJK (chino / japonés / coreano). Simplemente se vuelven ilegibles. (OK, tampoco pude leerlos antes, pero especialmente negrita solo crea manchas de tinta)