2010-03-24 7 views
20

Esto es de alguna manera subjetivo dependiendo del idioma de traducción de destino, pero tengan paciencia conmigo por un segundo.¿Es correcto "traducir los mensajes de error?

Recientemente he estado involucrado 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 donde se tradujo, sin embargo, el 30% se omitió intencionadamente. La decisión fue que no traduciremos mensajes de error dirigidos al desarrollador de la aplicación.

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

  1. están dirigidos hacia los diseñadores/programadores. Los programadores (e incluso los diseñadores :)) deberían tener un conocimiento básico de inglés de , al menos lo suficiente como para que puedan buscar en Google si no saben lo que significa. (Racista?)

  2. están dirigidos hacia el desarrollador y en un mundo perfecto no debe muestra al usuario final de la aplicación que se refieren a los funcionamiento interno de la aplicación web sí. es decir, "Debe establecer el nombre de la base de datos en su archivo de configuración de base de datos ".

  3. y quizás lo más importante , que hacen la vida del desarrollador más difícil cuando se trata de obtener más información /ayuda en relación con el error . Por ejemplo el error anterior produce 8 resultados en Google (en comillas), mientras que sus rendimientos griegos traducción exactamente 0.

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

Resumiendo: Cuando desarrolla paquetes de traducción de idiomas para sus aplicaciones ¿transmite 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.

+4

Mi experiencia personal: siendo francés, la mayoría de los mensajes de excepción provenientes de las herramientas de desarrollo Java o Java se traducen al francés, a menos que fuerce en_US. En casi cualquier aplicación localizada que tuve que usar, las traducciones fueron malas. No entiendo exactamente el proceso: los franceses con pocas habilidades en inglés pierden el tiempo localizando (mal) con la esperanza de ayudar a aquellos que tienen habilidades de inglés aún más pobres. De todos modos, casi siempre me veo obligado a adivinar el mensaje original en inglés antes de saltar a Google; de ​​lo contrario, no encuentro ninguna ayuda sensata. Entonces sí, el inglés es la lengua materna de las computadoras, convivir con eso. –

+0

* "mientras que su traducción griega produce exactamente 0" * - Obtengo principalmente algo de http://finderr.net (como un solo hit) cuando busco la versión alemana de un mensaje de error. ¿Este no es el caso del griego también? – Marek

Respuesta

18

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

Los mensajes de excepción, por otro lado, no se deben traducir. 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 mensaje de visualización para el usuario, este es un diseño incorrecto. Las excepciones pueden contener claves i18n.

+3

+1 para distinguir entre mensajes de error y de excepción. – Iraklis

10

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


TIP: en algunas aplicaciones, pulsando Ctrl + C hace una copia del mensaje sin ser editable, sería bueno para poner en práctica la misma función oculta .

2

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

4

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

  • mensajes de error alemanes suelen ser más difíciles de entender porque la lengua alemana 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ó, hace que sea 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 ...

+0

El segundo problema (mensajes localizados difíciles de encontrar) puede resolverse buscando equivalentes en inglés (no traducciones) - hay un catálogo que proporciona traducciones que coinciden para .NET: http://finderr.net/ – Marek

+0

Gracias por el enlace, podría ser útil para mí en el futuro. Sin embargo, la misma existencia de este sitio muestra que es mejor no traducir los mensajes de error si están destinados a desarrolladores. –

1

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

0

Generalmente, hay una gran cantidad de mensajes de error, y generalmente se muestran de forma esporádica. Por lo tanto, su traducción a veces parece demasiado esfuerzo.

2

No traducir 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 una verdadera dificultad:

  1. La mayoría de ellos no puedo encontrar en Google/MSDN, así que tengo que volver a traducirlos Inglés a mí mismo por el simple hecho de que googleing .
  2. 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.
  3. Algunas de ellas 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 requerirá simplemente más esfuerzo en ambos lados, y no le hará ganar mucho.

0

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 ser traducido. 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.

Cuestiones relacionadas