¿Se desarrolla con la localización en mente?

Cuando trabaja en un proyecto de software o un sitio web, ¿desarrolla con la localización en mente?

Con esto quiero decir, por ejemplo

• Externalizar todas las cadenas, incluidos los mensajes de error.
• No usar imágenes que contengan texto.
• Diseñando tu interfaz de usuario con la expansión de texto en mente.
• Usando pseudo-traducción para probar su UI al principio del proceso.
• etc.

En los proyectos en los que trabaja, ¿están en la categoría 'agradable de tener' y dejan que el equipo de localización se preocupe por el resto, o tiene la preparación de localización incorporada en su proceso de desarrollo? Me interesa saber cómo ven los desarrolladores la localización en general.

Trabajo para una gran compañía Fortune 500 y siempre comenzamos 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á "oye, eso sería perfecto para el país X". Luego, lo siguiente que sabes es que estás revisando el código agregando localización. Realmente no lleva más tiempo construir la aplicación con ella desde el principio, así que solo lo hacemos. Además, el beneficio adicional es que cuando un cliente acude a nosotros y solicita que su aplicación esté en (elija su idioma), le entregamos un archivo y le pedimos que lo traduzca (elija su idioma) y listo. .

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

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

Para entender los problemas que pueden ocurrir debido a eso, es como tener la parte oeste de los Estados Unidos hablando un idioma (muy) diferente al de la parte este. Piense que en el centro del país, la población está un tanto fusionada, 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ía la localización porque mi entorno me había condicionado. Así que sí, hace unos años, me preocupaba.

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

Herramientas que uso con Visual Studio .NET:

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

La mayoría de mis clientes requieren solo 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 por completo otros idiomas. Así que nos quedamos con lo básico:

• Use Unicode en todas partes. Son 2k10, no hay excusa para no hacerlo.
• Diseño 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 aplicación / modelado de datos fuera de la capa de vista

Personalmente, cuando un idioma de localización potencial es fundamentalmente diferente del 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á que una compañía obtenga 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 en ese idioma, sé lo suficiente 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, son los detalles los que realmente marcan la diferencia con los usuarios.

Para abordar verdaderamente 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. Mientras la aplicación funcione de la misma manera, la parte de la vista se puede reemplazar por completo. Cuando eso sucede, alguien está planeando pagar algo de dinero real para abordar el problema adecuadamente.

Lo hemos hecho según sea necesario: las cosas orientadas al cliente ahora se hacen teniendo en cuenta i18n, ya que hemos expandido nuestros mercados, y algunas cosas internas ahora tienen capacidad para i18n, por lo que los empleados que usan eso no necesitan hablar inglés.

Entonces, lo hicimos según sea necesario, como una startup.

Parece que la gente está tomando los esfuerzos de l10n con bastante ligereza. 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% de más espacio para el texto. Esto requiere que los traductores usen abreviaturas que no sean tan fáciles de entender, lo que por supuesto es malo para la experiencia del usuario.

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

Escribo aplicaciones de Android, y la localización es bastante sencilla utilizando archivos de cadena de estilo java. Casi cero 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, así que lo omito si no es un requisito 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 es excelente.