tecnicas refactorizar refactorización refactorizacion refactor codigo java jsp internationalization struts

java - refactorización - ¿Cómo puedo refactorizar el marcado HTML de mis archivos de propiedades?



refactorizar js (4)

Quizás:

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

Recientemente heredé una aplicación web internacionalizada y de texto pesado Struts 1.1. Muchos de los archivos JSP se ven así:

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

y los archivos de propiedades se ven así:

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

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

Problemas:

  1. Violación DRY : tengo N referencias a mis URL de acción de Struts en lugar de 1, lo que hace que las URL de acción de refactorización sean propensas a errores.
  2. Preocupaciones mixtas : el marcado de mi aplicación ahora se encuentra en más que solo mis archivos JSP, lo que dificulta que un especialista en la web modifique el marcado (usando CSS, etc.).
  3. Marcado posterior a la traducción : cada vez que recibo texto recientemente traducido, debo decidir qué rodear con el marcado <a>...</a> . Fácil para inglés pero menos para idiomas desconocidos.

Consideré agregar marcadores de posición en el archivo de mensajes, como:

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

pero las palabras "dirección" e "información de contacto" de alguna manera tendrían que ser localizadas, envueltas con etiquetas, y pasadas a mi etiqueta de mensaje, y no veo una manera fácil de hacerlo.

¿Qué puedo hacer para mejorar esto?


Un enfoque que viene a la mente es que puede almacenar los parámetros de reemplazo traducidos, es decir, "dirección" e "información de contacto" en un archivo de propiedades separado, uno por 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.


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

En general, dará lugar a 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 UI.


La API de etiqueta de mensaje de mensaje solo permite 5 argumentos paramétricos

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

Para citar el manual :

Algunas de las características de este taglib también están disponibles en la Biblioteca de etiquetas estándar de JavaServer Pages (JSTL). El equipo de Struts alienta el uso de las etiquetas estándar sobre las etiquetas específicas de Struts cuando sea posible.

Probablemente puedas hacer esto con el 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>

La desventaja es que este no es un XML válido, y tirar de los valores a las variables implica más indirección, búsquedas y verbosidad. Esta no es una buena solución.

No conozco Struts, pero si se parece a JavaServer Faces (el 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 texto recién traducido, debo decidir qué rodear con el marcado <a>...</a> .

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 {0} caracteres deben incluirse 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 para renderizar:

<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 hacer que su diseñador de UI escupiera dientes.