¿Tiene sentido internacionalizar los registros?


8

¿Cuáles son los casos de uso válidos para internacionalizar registros? Especialmente, ¿hay algún uso que tenga sentido para una aplicación web?

Estoy trabajando para convertir la API de registro utilizada por una aplicación web de log4ja slf4j, y noté que la interfaz utilizada para abstraer sobre la log4jimplementación admite la internacionalización; También me di cuenta de que tanto log4jy slf4jsoporte de internacionalización, lo que significa que debe ser útil a alguien.

Ahora, la internacionalización podría ser útil al programar una aplicación de escritorio, en la que los registros podrían ser vistos por el usuario final, pero esta fachada de registro solo se usa en el lado del servidor para varias aplicaciones web, por desarrolladores que deben usar el inglés en general .



8
Iniciar sesión en un idioma que no sea inglés hace que sea más difícil encontrar ayuda en línea, ya que reduce la cantidad de resultados coincidentes en Google.
Tulains Córdova

44
Paso horas de mi día usando varias reglas de filtrado en los registros. Obviamente, internacionalizar las entradas hace que sea mucho más difícil
Gort the Robot el

Me pregunto si algunas personas votan negativamente cuando en realidad quieren decir "no, hacer esto está mal" ... Eso no es para lo que sirve el voto negativo: /
Andres F.

@AndresF. Si su comentario fuera adjunto a una respuesta, en realidad no estaría de acuerdo con usted. Si bien esta pregunta es de hecho responsable, también está en el lado de las cosas basado en la opinión. Un voto negativo no es tan malo.
jpaugh

Respuestas:


6

Las respuestas dadas aquí están demasiado vinculadas al punto de vista del desarrollador. Sin embargo, el software está hecho para ser usado (y leído) por humanos (usuarios) cuya mayoría de ellos no tienen idea sobre depuración, patrones de registro, estándares, etc.

Digamos que tenemos un producto que registra su actividad en diferentes niveles. Se requiere que el producto tenga un tablero o panel de control donde los usuarios puedan monitorear la actividad. En consecuencia, los rastreos de registros deben ser legibles por los usuarios en lugar de los desarrolladores o técnicos .

Además, los usuarios pueden ser de diferentes ubicaciones. Lo que significa que los formatos de fecha de registro, los símbolos numéricos y de moneda, etc., deben ir de acuerdo con la ubicación del usuario.

En tal situación, ¿por qué los registros no deben localizarse?

Si bien es cierto que los registros deben ser legibles por máquina, nada nos impide implementar un proceso de registro paralelo un poco más fácil de usar.

Estoy de acuerdo con que el inglés sea el idioma estándar para los registros. Pero todo este tipo de "estándares" son estándares de facto . Entonces, en este punto, tenemos que ser flexibles.

Dicho esto, si encuentra una buena razón para usar la función de localización slog4j, continúe. Fue hecho por una buena razón.

Una de estas razones podría ser que las aplicaciones actuales se ejecutan en un contexto mundial, y no todos hablan / leen / escriben su idioma (o inglés). Tal vez, ni siquiera el servicio de asistencia de su producto lo hace.


Usted hace un buen punto. Usar un marco de registro para enviar mensajes (internacionalizados) al usuario final tiene sentido; ¿Por qué reinventar el registro cuando ya está allí?
jpaugh

1
Supongo que es cuestión de personalizaciones. Necesitamos / queremos una función adicional. Pero a menudo "reinventamos la rueda" :-)
Laiv

2
Tengo una rueda, que hice yo mismo. ¡Es la mejor rueda de todas! Es más brillante, más redondo que cualquier otro. Pero, no cabe en ningún automóvil existente. Necesito hacer un auto que se ajuste a mi rueda ... ;-)
jpaugh

11

Cuando los desarrolladores hablan de "registros", con mayor frecuencia se refieren a archivos de texto sin formato que contienen información que no tiene sentido fuera del contexto del código específico que los registró y que no tiene otro propósito que el de solucionar ese código cuando algo sale mal.

Cuando los desarrolladores hablan de "internacionalización", a menudo se refieren a "cuando el usuario es un hablante del idioma X, use la cadena traducida al idioma X en lugar de la cadena predeterminada".

Dadas esas definiciones específicas, los registros internacionalizados son casi siempre una mala idea , porque:

  1. Por lo general, el conjunto de idiomas que todos sus desarrolladores pueden hablar con fluidez es mucho más pequeño que el conjunto de idiomas en el que cualquiera de sus usuarios podrían ser hablantes nativos. Por lo tanto, si internacionaliza los registros, es más probable que sus desarrolladores lo hagan. No ser capaz de entenderlos.

  2. Por lo general, la mayoría de sus usuarios no son mantenedores activos del software que están utilizando. Por lo tanto, sus clientes que no hablan inglés no podrían entender los registros, incluso si se internacionalizaran, porque la mayoría de los mensajes de registro serán sobre piezas específicas de código y diversos detalles de implementación que simplemente no entienden y no deberían Alguna vez has sabido

  3. La internacionalización de un mensaje derrota por completo la capacidad de realizar búsquedas de texto para ese mensaje, ya sea que los desarrolladores busquen su código o los usuarios busquen soluciones en Internet.

  4. La internacionalización introduce la posibilidad de errores de traducción o ambigüedades sutiles, que son completamente inaceptables en el contexto de la solución de problemas de software. Es el mismo problema que registrar marcas de tiempo sin una zona horaria explícita; constantemente tienes que perder el tiempo descubriendo lo que realmente significa.


Por supuesto, si relajamos esas definiciones y suposiciones con las que comencé, entonces hay algunos casos de uso válidos.

En general, los "registros internacionalizados" son potencialmente útiles cuando hay un subconjunto de mensajes de registro fácilmente identificable que son significativos para el usuario promedio, y cuando "internacionalización" significa un registro separado en el idioma del usuario junto con el registro de idioma predeterminado para los desarrolladores.

En la práctica, si algo que podría llamar un "registro internacionalizado" es realmente útil, entonces probablemente será una característica de la aplicación de todos modos.

Algunos tipos de videojuegos hacen esto, particularmente los que se comportan como juegos de mesa:

ingrese la descripción de la imagen aquí

Fuente: Blood Bowl, captura de pantalla tomada de https://www.youtube.com/watch?v=UyQB4kDMZzE

Si los "registros" se consideran extremadamente útiles o una característica crítica, es más probable que terminen en una base de datos adecuada en lugar de simples archivos de texto. El software de seguimiento de ventas es un ejemplo típico de esto:

ingrese la descripción de la imagen aquí

Fuente: http://www.everlogic.com/i-want-to/see-screenshots/

Independientemente de si llamaría o no a estos "registros", el texto que ve en estas imágenes es claramente algo que nos gustaría internacionalizar si mantenemos estos problemas.


Vienes desde mi perspectiva. Pero, reutilizar la API de registro existente para enviar mensajes de estado al usuario tiene mucho sentido, ahora que lo pienso. Es más fácil agregar internacionalización al registro que crear un registrador ad-hoc personalizado para la interfaz de usuario.
jpaugh

Imagine que tiene un error que solo ocurre en una versión localizada en japonés. Y sus desarrolladores han agregado un registro que facilitaría la localización y reparación del error. Excepto que tu registro está en japonés, y ninguno de tus desarrolladores puede entenderlo :-(
gnasher729

No hay problema, dime el código de error y los datos de entrada que causaron el error. :-)
Laiv
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.