¿Se deberían localizar los mensajes de excepción dirigidos al desarrollador?

Question

Me refiero a los mensajes de excepción que muestran que el desarrollador está utilizando incorrectamente una API. Por ejemplo, pasar incorrectamente un método nulo a. Entonces, el tipo de excepción que obtendrá el desarrollador la primera vez que ejecute su código incorrecto. El tipo de mensaje de excepción que nunca se debe mostrar al usuario de un sistema.

Esto está relacionado con la teoría de que dado que el lenguaje de programación está en inglés, el programador ya tiene una comprensión del inglés. O al menos lo suficiente como para descifrar un mensaje de excepción.

http://www.codinghorror.com/blog/archives/001248.html (por favor, no hay discusión de esta teoría aquí)

Y sí sé que el marco .NET sigue el enfoque de "localizar todo".

Answer 1

Su pregunta se puede reformular como "¿deberían todos los desarrolladores recibir el mismo mensaje de error para que puedan buscarlo en Google?" ;)

Y la respuesta a eso es sí.

traducción significa que

• el mensaje ya no es el mismo que el que escribió la API previsto. Puede llevar el mismo significado, o podría haber perdido algo en la traducción. Podría estar mal traducido, y en algunos casos podría ser completamente ilegible.
• Quien lo lea no puede simplemente escribir el error en Google y ver qué hicieron los demás que obtuvieron este error. Porque todos los demás obtuvieron el mismo error en un idioma diferente.

Acerca del enfoque "localizar todo" de .NET, es horrible. Me he tropezado incontables veces, especialmente porque si no puede encontrar el recurso localizado, lo hace y no le da la versión en inglés. Le da un error de "No se pudo encontrar el recurso" en su lugar, descartando efectivamente la información de error real.

Answer 2

Todo depende de quién va a mantener el código. Si los desarrolladores siempre serán ingleses, entonces tiene sentido mantenerlo todo en inglés.

Además, no estoy seguro si .NET Framework arroja sus mensajes de error de forma localizada. Siempre pensé que esos mensajes de error siempre están en inglés, por lo que tendría sentido mantener tus mensajes de error internos en inglés también.

Answer 3

No, no creo que deban serlo (o al menos no lo hacemos, y somos bastante grandes :-). Hay suficiente esfuerzo involucrado en localizar todo lo que los usuarios ven sin tener que preocuparse por los desarrolladores también.

No hay idiomas principales que admitan palabras clave de idiomas extranjeros y bibliotecas estándar por lo que un comando rudimentario del idioma inglés ya es un requisito previo para los desarrolladores.

Por supuesto, si los desarrolladores desarrollan sus propias bibliotecas (o idioma), tienen la libertad de localizar o elegir un idioma que no sea el inglés.

Answer 4

En nuestra firma, permitimos la traducción de mensajes de excepciones/errores para nuestro compilador/IDE y proporcionamos el marco para traducir estas excepciones/mensajes de error, pero no hacemos la traducción nosotros mismos. Luego, le corresponde al cliente traducir si así lo desea.Hay varios países donde el inglés no es tan popular y donde se promueve el idioma propio. Por lo tanto, tiene sentido permitir los mensajes de error traducidos.

Answer 5

Si traduce sus mensajes de excepción, entonces también debe traducir todos los textos donde se producen mensajes de excepción. Eso incluye cualquier base de conocimiento o sistema de seguimiento de fallas que tenga, porque los usuarios y programadores querrán buscar el mensaje de excepción que ven en la pantalla.