Comment puis-je refactoriser le balisage HTML de mes fichiers de propriétés ?

Question

J'ai récemment hérité d'une application Web Struts 1.1 internationalisée et contenant beaucoup de texte.La plupart des fichiers JSP ressemblent à :

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

et les fichiers de propriétés ressemblent à :

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

avec les traductions appropriées dans N autres langues (messages_fr.properties, etc).

Problèmes:

1. Violation SÈCHE - J'ai N références à mes URL d'action Struts au lieu de 1, ce qui rend les URL d'action de refactorisation sujettes aux erreurs.
2. Des préoccupations mitigées - Le balisage de mon application ne se trouve désormais pas seulement dans mes fichiers JSP, ce qui rend difficile pour un spécialiste du Web de modifier le balisage (en utilisant CSS, etc.).
3. Balisage post-traduction - Chaque fois que je reçois un texte nouvellement traduit, je dois décider de ce que je dois entourer du texte. <a>...</a> balisage.Facile pour l’anglais mais moins pour les langues inconnues.

J'ai envisagé d'ajouter des espaces réservés dans le fichier de messages, comme :

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

mais alors les mots « adresse » et « informations de contact » devraient d'une manière ou d'une autre être localisés, enveloppés de balisage et transmis à ma balise de message - et je ne vois pas de moyen simple de le faire.

Que puis-je faire pour améliorer cela ?

Answer 1

Évitez de créer des liens dans de longs blocs de texte.Préférez le texte plus court qui peut agir comme un lien logiquement complet et indépendant.

En général, cela entraînera moins de problèmes.Parfois, vous devez compromettre la conception de votre interface utilisateur pour tenir compte de la localisation ;vous devez parfois compromettre votre processus de localisation pour s'adapter à l'interface utilisateur.

Chaque fois qu'un développeur manipule manuellement des chaînes post-traduction, cela constitue une source de bugs potentiellement coûteux.Couper/coller ou modifier des chaînes peut entraîner une corruption des caractères, des chaînes mal placées, etc.Un défaut de traduction nécessite la participation de parties extérieures pour être corrigé, ce qui implique des coûts et prend du temps.

En y réfléchissant, quelque chose comme ça pourrait être moins laid :

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

... mais je ne suis pas un concepteur d'interface utilisateur.

Answer 2

Une approche qui me vient à l'esprit est que vous pouvez stocker les paramètres de remplacement traduits, c'est-à-dire"adresse" et "informations de contact" dans un fichier de propriétés distinct, un par langue.Demandez ensuite à votre classe Action (ou probablement à une classe d'assistance) de rechercher les valeurs du ResourceBundle correct pour les paramètres régionaux actuels et de les transmettre à la balise de message.

Answer 3

Peut-être:

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

Answer 4

L'API de la balise de message du message n'autorise que 5 arguments paramétriques

Ah !Je blâme mon ignorance totale de l'API Struts.

Pour citer le manuel:

Certaines des fonctionnalités de ce Taglib sont également disponibles dans la bibliothèque de balises standard des pages Javaserver (JSTL).L'équipe Struts encourage l'utilisation des étiquettes standard sur les étiquettes spécifiques de Struts lorsque cela est possible.

Vous pourriez probablement faire cela avec le 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>

L'inconvénient est qu'il ne s'agit pas d'un XML valide et que l'extraction des valeurs vers des variables implique plus d'indirection, de recherches et de verbosité.Ce n'est pas une bonne solution.

Je ne connais pas Struts, mais si cela ressemble à JavaServer Faces (même architecte), alors il existe probablement un support pour la configuration d'un contrôle de remplacement.Je remplacerais le contrôle existant par un contrôle plus flexible ou j'en ajouterais un nouveau.

Chaque fois que je reçois un texte nouvellement traduit, je dois décider quoi entourer avec le <a>...</a> balisage.

Vous ne devriez en aucun cas faire cela et je considère cela comme un défaut dans votre processus de traduction (je suis un ancien ingénieur en localisation et un ancien développeur d'outils de localisation).Le {0} les caractères doivent être inclus dans les fichiers envoyés aux traducteurs.Les directives de localisation doivent expliquer le contexte de la chaîne et la signification de toutes les variables.

Vous pouvez valider par programme les groupes de propriétés au retour.Les expressions régulières spécifiques aux chaînes pourraient faire l'affaire.Il n’est pas hors de question que « l’adresse » et les « coordonnées » permutent l’ordre pendant la traduction.

La solution la plus simple consiste à repenser les messages à restituer :

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

J'accepte que cela ne soit peut-être pas une solution dans tous les cas et que votre concepteur d'interface utilisateur puisse cracher des dents.