localization - multi - ¿Es "correcto" traducir los mensajes de error?

rails translation interpolation (8)

Esto es de alguna manera subjetivo dependiendo del idioma de traducción de destino, pero ten paciencia conmigo por un segundo.

Recientemente participé en un proyecto de traducción. El objetivo era traducir las cadenas de un marco MVC al idioma griego.

El 70% de las cadenas de idioma del marco se tradujo, sin embargo, el 30% se omitió intencionadamente. La decisión fue que no traduciremos los mensajes de error dirigidos al desarrollador de la aplicación .

El razonamiento detrás de esto (en resumen) fue:

están dirigidas a diseñadores / programadores. Los programadores (e incluso los diseñadores :)) deberían tener un conocimiento básico de inglés, al menos lo suficiente como para poder buscar en Google si no saben lo que significa. (¿racista?)
están dirigidas hacia el desarrollador y en un mundo perfecto no deberían mostrarse al usuario final de la aplicación, ya que se refieren al funcionamiento interno de la aplicación web. es decir, "debe establecer el nombre de la base de datos en el archivo de configuración de la base de datos".
y quizás lo más importante , hacen la vida del desarrollador más difícil cuando trata de obtener más información / ayuda con respecto al error. Por ejemplo, el error anterior arroja 8 resultados en Google (entre comillas), mientras que su traducción griega arroja exactamente 0.

Sé que esto depende de la popularidad del idioma de traducción objetivo y de la aplicación en sí. Por ejemplo, supongo que hay una gran cantidad de documentación con respecto a los mensajes de error de SAP alemán (lo sé, lo sé, SAP es alemán, pero entiendes), a diferencia de la documentación griega de mensajes de error con respecto a la aplicación aleatoria X que tiene alrededor de 500 instalaciones en todo el mundo.

Entonces, para resumir: cuando desarrolla paquetes de traducción de idiomas para sus aplicaciones, ¿usted traduce los mensajes de error? ¿Solo lo hace para idiomas predominantes como inglés / español / alemán / francés? ¿O los dejas intactos? No estoy buscando la respuesta "correcta" o "correcta", estoy buscando una respuesta de "mejores prácticas" o si este problema se define en cualquier norma / política "oficial" con la que haya tenido experiencia.

¿Qué hay de imprimirlos en ambos idiomas? El usuario / administrador local sabe lo que está sucediendo y puede buscarlo y comunicarse con los desarrolladores.

Generalmente hay muchos mensajes de error, y generalmente se muestran solo esporádicamente. Por lo tanto, su traducción a veces parece demasiado esfuerzo.

No traduzca mensajes de excepción; Podría convertirse en una pesadilla de traducción.

Estoy trabajando mucho con la automatización de Microsoft Office. Los mensajes de excepción que fueron traducidos al hebreo me dan un tiempo realmente difícil:

La mayoría de ellos no los puedo encontrar en Google / MSDN, así que tengo que traducirlos al inglés por el simple hecho de buscarlo en Google.
Algunos de ellos se refieren a objetos por sus nombres de clase traducidos. Las clases de objetos que estoy manipulando (como programador) siempre se nombran en inglés. Esto solo hace que los mensajes sean menos comprensibles.
Algunos de ellos son cadenas formateadas, donde el mensaje mismo se traduce pero los argumentos que construyen el mensaje no lo son; esto hace que el mensaje sea aún menos comprensible y, a veces, significa que el mensaje no se mostrará correctamente en un MsgBox predeterminado (los idiomas de derecha a izquierda pueden ser una pesadilla).

Según mi experiencia, un desarrollador necesita sus mensajes de excepción en inglés, por lo que traducirlos simplemente requerirá más esfuerzo por ambas partes y no le hará ganar mucho.

Si la aplicación es para usuarios comunes de negocios o consumidores y los mensajes de error se muestran a ellos para que puedan entender o tomar alguna acción basada en eso, entonces creo que se debe traducir. Si los mensajes de error son solo para el registro y la solución de problemas, entonces la traducción debería ser innecesaria.

Solo puedo ofrecer mi propia opinión, pero para mí, como desarrollador alemán, siempre es molesto obtener mensajes de error traducidos, especialmente para software ampliamente distribuido como el software MS. Eso es por dos razones:

Los mensajes de error alemanes suelen ser más difíciles de entender porque el idioma alemán hace que todo suene más complicado. Además, a menudo no hay buenas traducciones para palabras relacionadas con TI. Los desarrolladores alemanes tienen que usar palabras en inglés en su lugar o reemplazarlas con engorrosas traducciones literales. Lo mismo ocurre con los sitios web de MSDN, por cierto.
Además, como ya lo mencionó, es mucho más difícil encontrar soluciones a esos errores con google en los sitios web en inglés. La comunidad de desarrolladores alemana es mucho más pequeña que la comunidad inglesa ...

Traducido o no, asegúrese de usar siempre una identificación única y permita que el usuario la copie.

SUGERENCIA : en algunas aplicaciones, si presiona Ctrl + C para hacer una copia del mensaje sin ser editable, sería bueno implementar la misma función oculta .

Un buen marco que incluya mensajes de error integrados debería tener una opción para i18n. Esto es importante por completo para el usuario.

Los mensajes de excepción, por otro lado, no deben traducirse. Usted ya señaló una razón importante: buscar. Y sí, son para desarrolladores, no para usuarios finales.

Si un mensaje de excepción también se utiliza como un mensaje de visualización para el usuario, este es un diseño incorrecto. Las excepciones pueden contener claves i18n.

Depende de la aplicación. Una aplicación altamente técnica que será utilizada por personas que entienden inglés y el idioma de destino, puede estar bien con los mensajes de error en inglés.

Si se trata de un mensaje que verá el usuario final, debe traducirse. Piense si estaba usando una aplicación que fue escrita por un desarrollador japonés y vio un mensaje de error en japonés. Probablemente no sea tan útil para usted; no tendrá idea de lo que dice, si puede o no hacer algo al respecto.