internationalization - internationalisation - Código "internacionalización"
django internationalization (8)
Trabajé en diferentes proyectos en diferentes países y observé que a veces el código se internacionalizaba, como
Establecer LargeurEtHauteur () (para SetWidthAndHeight, fr )
Dim _ListaDeObiecte como List (Of Object) (para _ObjectList, ro )
vacío interno Sohranenie User ov () (para SaveUsers, ru )
etc.
Sucede que en países con alfabeto latino esta mezcla es más pronunciada, porque no hay necesidad de transliteración.
Más que eso, a menudo la "jerga" de programación está inspirada en el lenguaje de especificaciones del proyecto. Hay casos en que los términos en "lenguaje de proyecto" tienen un significado que no es "traducible" en inglés.
También hay proyectos en los que solo funciona, digamos un equipo francés, utiliza palabras en francés (por ejemplo, Personne, Vehicule, Projet, etc.).
En esos casos, personalmente añado en las especificaciones un "Diccionario" que explica todos los nombres de objetos comerciales y solo estos objetos se usan en otro idioma (francés).
Decir:
Collectif - ensemble des Personnes ;
Todas las acciones (Obtener, Configurar, Actualizar, Modificar, Cargar, etc.) están en inglés.
Ahora que los nombres "fuertes" podrían usarse en el código: Agregar Personne a Collectif .
- ¿Cuál es su enfoque de "internacionalización"?
PD.
Me divirtió que VisualStudio compila y ejecuta proyectos en .NET con botones llamados à la "btnAdd É l è ve" o "кпкСтоп" ...
Creo que llamaría a una base de código como "abismal" en lugar de "internacionalizada", pero la regla general que siempre he escuchado es que si alguna vez crees que alguien que no sea uno que hable tu idioma alguna vez toque el código, hazlo en ingles
En general, el código que hace referencia a los conceptos de lenguaje debe estar en el mismo idioma materno que el lenguaje de programación (es decir, inglés - para, mientras, cadena son todas las palabras en inglés).
Está bien (pero no genial) tener variables y conceptos de dominio en un idioma local, pero definitivamente no desea traducir Lista, Objeto, Decimal, etc. en términos que causen que los programadores trabajen más para reconciliar dos idiomas. Aún así, presionaría fuertemente para restringir conceptos de dominio muy comunes como Colección, Membresía, Persona, Usuario y posiblemente conceptos de dominio menos comunes como Factura, Recibo a Inglés donde esto sea posible.
Sería como codificar la mitad de tus clases en VB y la mitad en C #: tu cerebro tiene que hacer un cambio cognitivo. Si bien esto es bueno para las aplicaciones híbridas (JavaScript en la web y C # en el backend) porque le ayuda a mantener lo que se está ejecutando donde está claro, no es bueno para una programación general.
Además, usar inglés para todo hace que las palabras de dominio y de idioma trabajen juntas mejor.
Siempre hay excepciones Hay ciertos casos en los que usaría una palabra nativa de todos modos, donde la palabra describe mejor el dominio. Por ejemplo, en nuestra base de códigos (en inglés), teníamos referencias a términos mexicanos en español para ciertos conceptos que solo eran relevantes para las personas que ejecutaban nuestro software en México. Por lo general, los términos japoneses se deletreaban fonéticamente / Romaji, sin embargo, era difícil para los no japoneses poder pronunciar los pictogramas ;-).
Incluso si todos los miembros del equipo son buenos hablantes de inglés (lo que no es un hecho), es posible que no necesariamente conozcan el equivalente en inglés de toda la terminología de negocios.
Creo que es una decisión específica del proyecto qué permitir, pero en general toleraré y en algunos casos fomentaré los términos comerciales (por ejemplo, nombres de entidades) en el idioma local, pero no términos técnicos (es decir, no Largeur / Hauteur en lugar de Ancho / Altura) .
Por ejemplo, en el mundo financiero de Francia, todos saben lo que significan OPCVM y FCP: si intentas traducir al inglés, podrías terminar teniendo más malentendidos que con idiomas mezclados.
Mi enfoque personal, que es compartido por muchos pero no todos en la comunidad de programación, es que el código fuente debe estar en inglés y, de ser posible, todas las herramientas de desarrollo también deberían estar en inglés.
La razón más importante para esto es poder compartir sus problemas y soluciones con el mundo (como lo estamos haciendo ahora en , nada menos) sin tener que traducir nombres de clase, mensajes de error, rutas y otros artefactos cada vez.
También ayuda a la coherencia, porque la mayoría de las bibliotecas están escritas en inglés y tener nombres de elementos que mezclan dos idiomas no ayuda realmente a nadie, además de ser un foco constante de conflictos internos cuando un verbo como Agregar no siempre se trasladó.
El código inglés también facilita la incorporación de personas extranjeras a un proyecto sin preocuparse por la comprensión y los malentendidos ( especialmente entre idiomas estrechamente relacionados, como el español y el portugués, que tienen muchos falsos cognados).
Un buen enlace sobre este tema: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html
(En caso de que alguien se pregunte, soy sudamericano y el inglés no es mi idioma principal)
Si escribe un código que pueda usar internacionalmente algún día, escríbalo en inglés. En caso de duda, escríbalo en inglés, incluso comentarios si puedes (aunque supongo que puedes agregar algunos comentarios en el idioma de tu lugar de trabajo).
No es específico para la codificación desafortunadamente. El inglés no es mi lengua materna, pero he podido leer una serie de documentos técnicos y participar en conferencias internacionales con personas de todo el mundo. Estas colaboraciones simplemente no funcionarían si todos publicaran en sus respectivos idiomas nativos.
Puede ser triste si tiene ganas de defender su idioma a toda costa, pero tiene que ser realista al respecto. Supongo que el inglés tiene la ventaja de ser relativamente simple para alcanzar un nivel básico: no hay géneros para los nombres, no hay conjugaciones, no hay casos.
Tengo el mismo problema con el noruego actual. Supongo que depende de su posición en el proyecto, el tiempo disponible y el papel del software.
En mi caso, he decidido mantener todos los términos en un protocolo y biblioteca con los que estoy trabajando en noruego, ya que puedo esperar razonablemente que generaciones de trabajadores administrativos se hayan acostumbrado a ellos, y dado que la biblioteca depende del protocolo. En una envoltura de biblioteca para un proyecto internacional, he traducido literalmente el nombre de cada método y he añadido una documentación en inglés del método.
Los comentarios y la documentación sobre el código están en inglés.
Si diseñara un software desde cero, trataría de encontrar términos en inglés para todos los nombres de métodos e incluso términos comerciales (si es razonable. Apenas puedo pensar en un ejemplo donde no se encuentre ningún término), para mantenerlo "portátil".
Creo que una buena guía de diseño es escribir código con el uso de nombres en inglés y solo con comentarios en inglés (por supuesto si tu equipo es capaz de hacerlo, pero en el caso del equipo internacional, el inglés parece ser natural, ya que es el más popular idioma, especialmente en el mundo de TI).
Una buena explicación de tal guidline es que las palabras clave en la mayoría de los lenguajes de programación están tomadas del inglés, por lo que escribir su código con nombres en inglés le da un aspecto más consistente y gracias a esto termina con un código que es más fácil de leer.
Otra razón es que la mayoría de los compiladores solo pueden manejar caracteres ascii como nombres de clases, métodos, etc. por lo que probablemente terminará con algunos nombres extraños cuando decida usar algún lenguaje con alfabeto que contenga caracteres no ascii .
La tercera razón que me vino a la mente es compartir tu código en el sitio como SO. Hoy abrí una publicación con un código donde las clases tenían nombres en español. Fue difícil para mí adivinar cuál era el propósito de esta clase (incluso si a veces no es necesario, es bueno cuando lees el código y entiendes todas las palabras usadas :)).
En resumen, creo que la internacionalización del código no es una buena idea. Puede imaginarse que las palabras clave en los lenguajes de programación (p. Ej., Clase, intento, mientras) también podrían estar localizadas y probablemente también pueda imaginar cuán difícil puede ser la vida en ese momento ...
Para mantener las cosas consistentes, convertiría el código en el mismo lenguaje (humano) que el lenguaje (de programación). Es decir, si el lenguaje de programación usa palabras clave en inglés (como for , switch , public , etc.), entonces mantenga el resto del código en inglés. Si está utilizando un compilador que reconoce (digamos) las traducciones en swahili de palabras clave, guarde el resto del código en swahili.
Muchas API tienen esquemas de nomenclatura estandarizados que se siguen independientemente del idioma (humano), y la documentación adjunta se traduce según sea necesario (en lugar del código fuente).
No importa qué idioma (humano) elija, elija uno y quédese con él. Prefiero tratar de navegar a través del código fuente en alemán que el código que era una mezcla de alemán e inglés.