Java Jsp Internationalization Struts

Refactoring HTML Markup Out of Property Files: A Guide for Struts 1.1 Applications

When working with internationalized web applications, particularly those built with Struts 1.1, you may encounter challenges in separating HTML markup from your property files. This can lead to various complications, such as violations of the DRY (Don’t Repeat Yourself) principle, mixed concerns regarding markup management, and difficulties in handling translations. In this post, we will explore these issues in detail and provide a structured approach to refactoring your HTML markup in a way that enhances maintainability and localization.

Understanding the Problem

Issues with Current Markup Structure

In the current structure of a Struts-based application, you might have JSP files that look something like this:

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

And property files that contain long text entries with embedded HTML:

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

This scenario gives rise to several significant issues:

  1. DRY Violation: You have multiple references to your action URLs (like /address.do), which introduces the risk of errors when those URLs change.
  2. Mixed Concerns: The markup is scattered across JSP and properties files, complicating the task of updating the visual aspect of the application.
  3. Post-Translation Markup Issues: When new translations are introduced, deciding where to place HTML links becomes labor-intensive, especially for languages that are less familiar.

Proposed Solution

Accepting the Limitations

  • Avoid Mixing Markup with Content: One best practice is to limit the usage of links within large blocks of text. Short, self-contained phrases work better for both localization and user interface consistency.

  • Design Compromises: Sometimes, you’ll need to balance between UI design and localization processes. The goal is to minimize the number of times a developer interacts with post-translation strings.

Refactoring Examples

Instead of having complex links intermixed in your property files, consider a simpler approach. For example:

Current Approach:

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

Refactored Approach:

You could rewrite the text in your property files and create an easier-to-manage structure:

alert=Please update your address and contact information.

And then, structure your JSP file like this:

<p>
    <bean:message key="alert" />
    <br />
    <a href="/address.do">update address</a>
    <br />
    <a href="/contact.do">update contact information</a>
</p>

Benefits of the Refactored Approach

  • Improved Localization: By separating the actions from the messages, it simplifies the translation process. You can focus purely on the text without worrying about HTML.
  • Easier Maintenance: This structure reduces the risk of bugs associated with copy-pasting or manually editing strings.
  • Cleaner Markup: Your markup remains clean and straightforward, making it much easier for web specialists to work with.

Conclusion

Refactoring HTML markup from property files in your Struts 1.1 application can help resolve several core issues, including DRY violations and mixed concerns. By improving the way you handle translations and separating HTML elements from text content, you make your application more robust, maintainable, and user-friendly.

Remember to always consider the implications of UI design on the localization process, as well as the reverse. A little planning can go a long way toward ensuring your application remains scalable and easy to maintain.