¿Se desarrolla teniendo en cuenta la localización?

Trabajo para una gran compañía de Fortune 500 y siempre empezamos con la localización en mente. Nuestros proyectos generalmente son solo para los EE. UU., Pero muchas veces a lo largo de los años, escribiremos una aplicación para un cliente y luego alguien más la verá y dirá "hey, eso sería un ajuste increíble para el país X". Entonces lo siguiente que sabes es que estás pasando por el código que agrega la localización. Realmente no toma más tiempo construir la aplicación desde el principio, así que simplemente lo hacemos. Además, el beneficio adicional es que cuando un cliente nos visita y solicita que su aplicación esté (seleccione su idioma), les entregamos un archivo y le decimos que lo traduzca (seleccione su idioma) y hemos terminado. .

Creo que eso fue importante hace 10 años. La tecnología reciente solucionó el problema .

Vivo en un país donde hay 3 idiomas nacionales , y solo uno de ellos es una minoría.

Para entender problemas que pueden ocurrir debido a eso, es como tener la parte oeste de EE. UU. hablando Un idioma (muy) diferente al de la parte este. Piense que en el centro del país, la población está unida, por lo que debe usar ambos idiomas en todas partes.

Tener 4 idiomas en aplicaciones de escritorio y sitios web era y sigue siendo muy común (3 idiomas nacionales + inglés). A veces es una obligación.

Conocí la localización porque mi entorno me ha condicionado. Así que sí, hace unos años, estaba preocupado por eso.

Ahora no me importa mucho la localización porque las últimas herramientas IDE te permiten convertir cualquier aplicación estática en una completamente localizada de manera muy fácil.

Herramientas que uso con Visual Studio .NET:

• CodeRush , un complemento de Visual Studio que te permite mover textos codificados en archivos de recursos.
• Easy Localizer , extraiga las etiquetas en un archivo Excel en el que agregue todo el lenguaje adicional, luego vuelva a combinar en sus archivos de recursos.

La mayoría de mis clientes solo requieren un idioma y, de hecho, especifican ese idioma. Por lo tanto, no pasamos tiempo localizando la aplicación. Sin embargo, eso no significa que podamos ignorar completamente otros idiomas. Así que nos atenemos a lo básico:

• Usa Unicode en todas partes. Es 2k10, no hay excusa para no hacerlo.
• Diseñe para cierta elasticidad en el diseño. Incluso con todo el inglés, las diferentes fuentes tienen huellas de pantalla muy diferentes en el mismo tamaño de punto.
• Mantenga las funciones de la aplicación / el modelado de datos fuera de la capa de vista

Personalmente, cuando un idioma de localización potencial es fundamentalmente diferente de aquel en el que se diseñó la aplicación, hay mucho más en juego que la simple selección de texto. Si bien el reemplazo de texto ayuda y permitirá a una empresa obtener una implementación "rápida y sucia" en una nueva ubicación comparativamente antes, no resuelve las diferencias fundamentales en la forma en que piensan los usuarios en el otro idioma.

He estudiado japonés, y aunque solo puedo considerarme un principiante de rango en ese idioma, sé lo suficiente como que hay algunos conceptos para los que no hay una traducción directa. Hay diferentes ideas de lo que hace que algo sea utilizable. Si bien los grandes conceptos principales pueden ser similares, los detalles realmente marcan la diferencia con los usuarios.

Para responder realmente a las necesidades de una cultura muy diferente, necesita una cara completamente nueva para su aplicación. Es por eso que la separación Modelo / Vista / Controlador se vuelve aún más importante. Siempre que la aplicación funcione de la misma manera, la parte de la vista se puede reemplazar completamente. Cuando eso sucede, alguien está planeando pagar algo de dinero real para abordar el problema de manera adecuada.

Lo hemos hecho como es necesario: las cosas orientadas al cliente ahora se han hecho pensando en i18n, ya que hemos ampliado nuestros mercados, y algunas cosas internas ahora son compatibles con i18n, por lo que los empleados que usan eso no necesitan habla ingles.

Por lo tanto, lo hicimos cuando fue necesario, como inicio.

Parece que las personas están tomando los esfuerzos de l10n bastante a la ligera. Especialmente cuando se usa el inglés como idioma original, es fácil ignorar el hecho de que otros idiomas normalmente requieren incluso un 30-40% más de espacio para texto. Esto requiere que los traductores utilicen abreviaturas que no son tan fáciles de entender, lo que por supuesto es malo para la experiencia del usuario.

Por lo general, agrego la internacionalización más adelante cuando la necesito, incluso si sé desde el principio que la necesitaré. Con los idiomas que estoy usando, no es muy difícil hacerlo en una fase separada, y puedo mantener un aspecto incómodo fuera de las primeras fases constructivas.

Escribo aplicaciones de Android, y la localización es bastante sencilla usando archivos de cadenas de estilo java. Casi ningún esfuerzo para la internacionalización completa en todos los idiomas de Android.

Respuesta: Sí. Aunque en el entorno en el que trabajo (Python / Zope / Plone) es muy fácil localizar cadenas después, por lo que no lo hago desde el principio.

Pero almaceno texto en objetos Unicode, etc.

Entonces, sí. Me aseguro de que mis aplicaciones sean razonablemente fáciles de localizar e incluso si no están localizadas funcionarán en un entorno internacional. No hacerlo es un error, ya que el esfuerzo necesario es pequeño y el beneficio excelente.