Como posso refatorar a marcação HTML dos meus arquivos de propriedades?

Question

Recentemente, herdei um aplicativo da web Struts 1.1 internacionalizado e com muito texto.Muitos dos arquivos JSP se parecem com:

<p>
    <bean:message key="alert" />
</p>

e os arquivos de propriedades se parecem com:

messages.properties
alert=Please update your <a href="/address.do">address</a> and <a href="/contact.do">contact information</a>.

com as traduções apropriadas em N outros idiomas (messages_fr.properties, etc).

Problemas:

1. Violação SECA - Tenho N referências aos meus URLs de ação do Struts em vez de 1, o que torna a refatoração de URLs de ação propensa a erros.
2. Preocupações mistas - A marcação do meu aplicativo agora está em mais do que apenas meus arquivos JSP, tornando difícil para um especialista da web ajustar a marcação (usando CSS, etc.).
3. Marcação pós-tradução - Sempre que recebo um texto recém-traduzido, devo decidir o que colocar entre os <a>...</a> marcação.Fácil para o inglês, mas nem tanto para idiomas desconhecidos.

Considerei adicionar espaços reservados no arquivo de mensagens, como:

alert=Please update your {0} and {1}.

mas então as palavras "endereço" e "informações de contato" precisariam de alguma forma ser localizadas, agrupadas com marcação e passadas para minha tag de mensagem - e não consigo ver uma maneira fácil de fazer isso.

O que posso fazer para melhorar isso?

Answer 1

Evite criar links dentro de longos blocos de texto.Prefira o texto mais curto que possa atuar como um link logicamente completo e independente.

Geralmente, isso levará a menos problemas.Às vezes, você precisa comprometer o design da IU para acomodar a localização;às vezes você precisa comprometer seu processo de localização para acomodar a IU.

Sempre que um desenvolvedor manipula manualmente strings pós-tradução é uma fonte de bugs potencialmente caros.Cortar/colar ou editar strings pode resultar em corrupção de caracteres, strings mal colocadas, etc.Um defeito de tradução precisa da participação de terceiros para ser corrigido, o que envolve custos e leva tempo.

Pensando bem, algo assim pode ser menos feio:

<p>Please update your address and contact information.
<br />
<a href="/address.do">update address</a>
<br />
<a href="/contact.do">update contact information</a></p>

... mas não sou designer de UI.

Answer 2

Uma abordagem que vem à mente é que você pode armazenar os parâmetros de substituição traduzidos, ou seja,"endereço" e "informações de contato" em um arquivo de propriedades separado, um por localidade.Em seguida, faça com que sua classe Action (ou provavelmente alguma classe auxiliar) procure os valores do ResourceBundle correto para o código do idioma atual e passe-os para a tag de mensagem.

Answer 3

Talvez:

#
alert=Please update your {0}address{1} and {2}contact information{3}.

Answer 4

A API de tag de mensagem da mensagem permite apenas 5 argumentos paramétricos

Ah!Eu culpo minha total ignorância da API do Struts.

Para citar o manual:

Alguns dos recursos deste taglib também estão disponíveis na Biblioteca de tags padrão de páginas JavaServer (JSTL).A equipe do Struts incentiva o uso das tags padrão sobre as tags específicas do Struts, quando possível.

Você provavelmente poderia fazer isso com o http://java.sun.com/jsp/jstl/fmt taglib.

<fmt:bundle basename="messages">
    <fmt:message key="alert">
        <fmt:param value='<a href="/">' />
        <fmt:param value="</a>" />
        <fmt:param value='<a href="/">' />
        <fmt:param value="</a>" />
    </fmt:message>
</fmt:bundle>

A desvantagem é que este não é um XML válido e transferir os valores para variáveis ​​envolve mais indireção, pesquisas e verbosidade.Esta não é uma boa solução.

Não conheço o Struts, mas se for algo parecido com JavaServer Faces (mesmo arquiteto), provavelmente há suporte para configurar um controle de substituição.Eu substituiria o controle existente por um mais flexível ou adicionaria um novo.

Sempre que recebo texto recém-translatado, devo decidir o que cercar com o <a>...</a> marcação.

Não há como você fazer isso e vejo isso como uma falha no seu processo de tradução (sou ex-engenheiro de localização e ex-desenvolvedor de ferramentas de localização).O {0} caracteres devem ser incluídos nos arquivos que são enviados aos tradutores.As diretrizes de localização devem explicar o contexto da string e o significado de quaisquer variáveis.

Você pode validar programaticamente os pacotes de propriedades no retorno.Regex específicos de string podem resolver o problema.Não está fora da possibilidade que "endereço" e "informações de contato" troquem de ordem durante a tradução.

A solução mais simples é redesenhar as mensagens a serem renderizadas:

<a href="/address.do">Please update your address.</a>
<a href="/contact.do">Please update your contact information.</a>

Aceito que isso pode não ser uma solução em todos os casos e pode deixar seu designer de UI cuspindo.