¿Cómo puedo refactorizar las marcas HTML de mis archivos de propiedades?

Question

He heredado recientemente una aplicación web de Struts 1.1 internacionalizada y de texto pesado. Muchos de los archivos JSP se parecen:

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

y los archivos de propiedades de aspecto:

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

con las traducciones correspondientes en otros idiomas (N messages_fr.properties, etc.).

Problemas: violación

1. SECO - Tengo N referencias a las URL de mi acción de Struts en lugar de 1, lo que hace propenso a errores URL de acción refactorización.
2. preocupaciones mixtos - marcado de mi solicitud es ahora en más sólo mis archivos JSP, por lo que es difícil para un especialista en web para ajustar el margen de beneficio (el uso de CSS, etc).
3. marcado post-traducción - Cada vez que recibo texto traducido recientemente, debo decidir qué rodean con el <a>...</a> marcado. Fácil para inglés pero menos para idiomas desconocidos.

He considerado la adición de marcadores de posición en el archivo de mensajes, como:

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

pero entonces las palabras "dirección" y "información de contacto" de alguna manera necesitan ser localizado, envuelto con marcado, y pasó a mi etiqueta de mensaje, y no veo una manera fácil de hacerlo.

¿Qué puedo hacer para mejorar esto?

Answer 1

Evite crear enlaces dentro de bloques largos de texto . Prefiere texto más corto que puede actuar como un complemento lógicamente completo y un enlace independiente.

Generalmente, provocará menos problemas. En ocasiones, debe comprometer el diseño de su UI para adaptarse a la localización; a veces debe comprometer su proceso de localización para acomodar la IU.

Cada vez que un desarrollador manipula manualmente las cadenas de post-traducción es una fuente de errores potencialmente costosos. Cortar/pegar o editar cadenas puede resultar en corrupción de caracteres, cadenas mal colocadas, etc. Un defecto de traducción necesita la participación de partes externas para arreglarlo, lo que implica costos y lleva tiempo.

Pensando en ello, algo como esto podría ser menos feo:

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

... pero no soy diseñador de interfaces.

Answer 2

Tal vez:

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

Answer 3

Un enfoque que viene a la mente es que se podría almacenar los parámetros de sustitución traducidas es decir, "dirección" y "Información de contacto" en el inmueble separados presentar, uno por cada localidad. Luego haga que su clase Action (o probablemente alguna clase auxiliar) busque los valores del ResourceBundle correcto para la configuración regional actual y páselos a la etiqueta del mensaje.

Answer 4

El mensaje API etiqueta del mensaje permite sólo 5 argumentos paramétricos

Ah! Culpo a mi completa ignorancia de la API de Struts.

citar el manual:

Algunas de las funciones de este taglib también están disponibles en las JavaServer Pages Standard Tag Library (JSTL). El equipo Struts recomienda el uso de las etiquetas estándar sobre las etiquetas específicas de Struts cuando sea posible.

Probablemente se podría hacer esto con el taglib http://java.sun.com/jsp/jstl/fmt.

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

La desventaja es que esto no es XML válido y tirando de los valores a las variables implica más de indirección, operaciones de búsqueda y la verbosidad. Esta no es una buena solución.

No sé Struts, pero si es algo así como JavaServer Faces (mismo arquitecto), entonces probablemente haya soporte para configurar un control de reemplazo. Yo reemplazaría el control existente por uno más flexible o agregaría uno nuevo.

Cada vez que recibo recién traducido texto, debo decidir qué rodean con el <a>...</a> marcado.

No hay forma de que deba hacer esto y veo esto como un error en su proceso de traducción (soy un ex ingeniero de localización y ex desarrollador de herramientas de localización). Los caracteres {0} se deben incluir en los archivos que se envían a los traductores. Las pautas de localización deberían explicar el contexto de la cadena y el significado de cualquier variable.

Puede validar mediante programación los paquetes de propiedades a la vuelta. Las expresiones regulares específicas de String pueden hacer el truco. No está fuera del ámbito de la posibilidad de que la "dirección" y la "información de contacto" intercambien orden durante la traducción.

La solución más simple es rediseñar los mensajes de render:

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

acepto que esto podría no ser una solución en todos los casos y puede tener los dientes de su diseñador de interfaces de escupir.