¿Tiene sentido internacionalizar los registros?

¿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 .

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.

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:

_{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:

_{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.