Faz sentido internacionalizar logs?


8

Qual é o caso de uso válido para a internacionalização de logs? Especialmente, existem usos que fazem sentido para um aplicativo da web.

Estou trabalhando na conversão da API de log usada por um aplicativo Web de log4jpara slf4je notei que a interface usada para abstrair a log4jimplementação oferece suporte à internacionalização; Notei também que tanto log4je slf4jinternacionalização apoio, o que significa que deve ser útil para alguém.

Agora, a internacionalização pode ser útil ao programar um aplicativo de desktop, no qual os logs podem ser visualizados pelo usuário final, mas essa fachada de log é usada apenas no servidor para vários aplicativos da Web, por desenvolvedores que precisam usar o inglês em geral .



8
Os registros em um idioma diferente do inglês dificultam a busca de ajuda on-line, pois reduz a quantidade de resultados correspondentes no Google.
Tulains Córdova

4
Passo horas do meu dia usando várias regras de filtragem nos logs. Obviamente, internacionalizar as entradas torna isso muito mais difícil
Gort the Robot

Gostaria de saber se algumas pessoas downvote quando eles realmente significam "não, fazer isso é errado" ... Não é isso que downvoting é a seguinte: /
Andres F.

@AndresF. Se o seu comentário foi anexado a uma resposta, eu discordo totalmente de você. Embora essa pergunta seja realmente responsável, ela também está do lado da opinião. Um voto negativo não é tão ruim.
jpaugh

Respostas:


6

As respostas fornecidas aqui são muito vinculadas ao ponto de vista do desenvolvedor. No entanto, o software é feito para ser usado (e lido) por humanos (usuários), cuja maioria deles não tem idéia sobre depuração, padrões de log, padrões, etc.

Digamos que temos um produto que registra sua atividade em diferentes níveis. É necessário que o produto tenha um painel ou painel de controle em que os usuários possam monitorar a atividade. Consequentemente, é necessário que os rastreamentos de log sejam legíveis pelos usuários, em vez de desenvolvedores ou técnicos .

Além disso, os usuários podem ser de diferentes locais. O que significa que os registros de formatos de data, símbolos numéricos, monetários, etc. devem ir de acordo com a localização do usuário.

Em tal situação, por que os logs não devem ser localizados?

Embora seja verdade que os logs devem ser legíveis por máquina, nada nos impede de implementar um processo de log paralelo um pouco mais fácil de usar.

Concordo que o inglês seja o idioma padrão dos logs. Mas todos esses tipos de "padrões" são De Facto Standard . Então, neste ponto, temos que ser flexíveis.

Dito isto, se você encontrar um bom motivo para usar o recurso de localização slog4j, vá em frente. Foi feito por uma boa razão.

Um desses motivos pode ser o fato de os aplicativos de hoje serem executados em um contexto mundial, e nem todo mundo fala / lê / escreve seu idioma (ou inglês). Talvez nem o serviço de assistência do seu produto funcione.


Você fez um bom ponto. Usar uma estrutura de log para enviar mensagens (internacionalizadas) ao usuário final faz sentido; por que reinventar o log quando ele já está lá?
jpaugh

1
Eu acho que é questão de personalizações. Precisamos / queremos um recurso extra. Mas, muitas vezes, "reinventar a roda" :-)
LAIV

2
Eu tenho uma roda, que me fiz. É a melhor roda de todos os tempos! É mais brilhante, mais redondo do que qualquer outro. Mas, ele não se encaixa em nenhum carro existente. Eu preciso fazer um carro para caber minha roda ... ;-)
jpaugh

11

Quando os desenvolvedores falam sobre "logs", costumam se referir a arquivos de texto sem formatação que contêm informações que não fazem sentido fora do contexto do código específico que os registrou e não têm outra finalidade, além de solucionar esse código quando algo der errado.

Quando os desenvolvedores falam sobre "internacionalização", geralmente significam "quando o usuário fala o idioma X, usa a string traduzida para o idioma X em vez da string padrão".

Dadas essas definições específicas, os logs internacionalizados são quase sempre uma má ideia , porque:

  1. Normalmente, o conjunto de idiomas em que todos os seus desenvolvedores podem falar fluentemente é muito menor do que o conjunto de idiomas em que qualquer usuário pode ser nativo. Portanto, se você internacionalizar logs, é mais provável que seus desenvolvedores não ser capaz de entendê-los.

  2. Geralmente, a maioria dos usuários não é mantenedora ativa do software que está usando. Portanto, seus clientes que não falam inglês não conseguiriam entender os logs, mesmo se fossem internacionalizados, porque a maioria das mensagens será sobre trechos de código específicos e vários detalhes de implementação que eles simplesmente não entendem e não devem já sabe sobre.

  3. A internacionalização de uma mensagem anula completamente a capacidade de fazer pesquisas de texto para essa mensagem, sejam desenvolvedores pesquisando seu código ou usuários pesquisando soluções na Internet.

  4. A internacionalização introduz a possibilidade de erros de tradução ou ambiguidades sutis, que são completamente inaceitáveis ​​no contexto da solução de problemas de software. É o mesmo problema que registrar registros de data e hora sem um fuso horário explícito; você constantemente perde tempo descobrindo o que realmente significa.


Obviamente, se relaxamos as definições e suposições com as quais eu comecei, existem alguns casos de uso válidos.

Em geral, "logs internacionalizados" são potencialmente úteis quando há um subconjunto de mensagens de log facilmente identificáveis ​​que são significativas para o usuário médio e quando "internacionalização" significa um log separado no idioma do usuário ao lado do log de idioma padrão para os desenvolvedores.

Na prática, se algo que você poderia chamar de "log internacionalizado" for realmente útil, provavelmente será um recurso do aplicativo de qualquer maneira.

Alguns tipos de videogame fazem isso, principalmente aqueles que se comportam como jogos de tabuleiro:

insira a descrição da imagem aqui

Fonte: Blood Bowl, captura de tela tirada de https://www.youtube.com/watch?v=UyQB4kDMZzE

Se os "logs" forem considerados extremamente úteis ou um recurso crítico, é mais provável que eles acabem em um banco de dados adequado, em vez de meros arquivos de texto. O software de rastreamento de vendas é um exemplo típico disso:

insira a descrição da imagem aqui

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

Quer você chame ou não esses "logs", o texto que você vê nessas imagens é claramente algo que gostaríamos de internacionalizar se mantivéssemos esses problemas.


Você está vindo da minha perspectiva. Mas, reutilizar a API de log existente para enviar mensagens de status ao usuário faz muito sentido, agora que penso nisso. É mais fácil adicionar internacionalização ao log do que criar um criador de logs ad-hoc personalizado para a interface do usuário.
jpaugh

Imagine que você tem um bug que ocorre apenas em uma versão localizada em japonês. E seus desenvolvedores adicionaram logs que facilitariam a localização e a correção do bug. Exceto que o seu log está em japonês e nenhum de seus desenvolvedores pode entendê-lo :-(
gnasher729

Não tem problema, diga-me o código do erro e os dados de entrada que causaram o erro. :-) #
03416 Laiv
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.