Discussions

News: End-to-end internationalization of Web applications

  1. Building an internationalized web application is not often a trivial task.

    Summary
    You need more than just tools and supplies to build a house. Hammer and nails are indispensable, but, before you start hammering together boards, you need to know the house's electrical needs, plumbing placement, and appropriate building codes. Likewise, when building an internationalized Web application, you need to know more than simply what tools the JDK offers to support your efforts. Reader, Locale, and ResourceBundle classes are your tools, but you still must confront other complexities that will drive how you use those tools as you nail together your application. Internationalization and localization are about more than rendering pages in locale-specific languages. They're about building applications to be globally aware from the browser all the way through to the database. In this article, you look at where to address character encoding when building internationalized Web applications, how localization affects data format, and additional internationalization tools provided by Apache Struts. You also learn how to overcome gaps in the standards and in the Struts framework as well as what pitfalls you might face during implementation.
    Read End-to-end internationalization of Web applications

    NOTE: Does anyone in TheServerSide Community have any tips and tricks for i18n?
  2. add Tiles to the mix...[ Go to top ]

    The article briefly mentions problems with 'accommodating languages rendered left-to-right and right-to-left' but offers no specific solution.

    I myself found Tiles in conjuntion with struts an eccelent way to help solve this problem - a simple config file for each target locale and you can start moving menu's, specifiying different sizes for them (essential when you find a translated eord is twice as big as the english equivilent!), etc on the fly.

    Vince.
  3. Tapestry and I18N[ Go to top ]

    Tapestry has some significant features w.r.t. I18N:


    Each page and component can have its own bundle of localized messages files (i.e., Home.properties, Home_fr.properties)

    Easy access to those properties, i.e.: <span jwcid="@Border" title="message:title"> gets the title message key and passes it to the Border component as the title parameter.

    Easy injection of localized content into templates, i.e. <span key="a-message"> ... sample text ... </span> will replace the sample text with the localized a-message message.

    Assets are localized automatically, so you can have Button.gif, Button_de.gif, Button_fr.gif and Tapestry will select the correct locale-specific one at runtime

    Pages and components can have localized templates (to address large scale changes, such as left-to-right issues)

    In addition, Mindbridge and crew have put a lot of support for handling charsets and locales in places; you can declare these things as meta data in your page specification and it all happens automatically. Detail's in the User's Guide.
  4. Tiles limitaion on i18n[ Go to top ]

    Tiles works fine with the set-of-jsp per locale approach, but doesn't work with the message bundle approach since Tiles caches JSP screen section/region on the application level. The set-of-JSP per locale is a good approach, but no anyone can carry the JSP file maintenance workload.
  5. Hello,
    xTier™ 2.0 ships with powerful "i18n" service in Standard Edition. To save on typing here are the links:
    xTier Overview
    I18n service example, APIs, articles

    Regards,
    Nikita.
    xTier – Service Oriented Middlware
  6. JSF[ Go to top ]

    JSF has a lot of really nifty i18n features. Things like dates get formatted properly depending on the locale automagically. Additionally the framework handles details such as determining the character encoding of Forms.
  7. Another article on the Javaworld[ Go to top ]

    Another article on the same subject is also on the Javaworld:

    http://www.javaworld.com/javaworld/jw-04-2004/jw-0419-multibytes.html
  8. The principle advocated by Wang Yu is quite right: Never assume any default settings on both the client side (browser) and server side. Here's another principle: What appears to be correct is not always right: check the string length at least. When you see two double-byte characters on the screen, is it really two characters, or jsut four ISO-8859-1 characters that happen to be the same byte sequence? Showing the string length will reveal the fact.

    Mike briefly mentioned the mechanism for selecting localized static content, i.e. ResourceBundle and Locale. ResourceBundle is great in that only one version of JSP (or other view components) is maintained, but the drawback is that the source becomes extremely difficult to read. IDE designers should be able to do something with it.
  9. For internationalization of a database-driven J2EE applications, it is often makes sense (or required) to go deeper than web and service layers, and incorporate i18n into database design too. This should be decided at requirements analysis phase and then designed with a great care because there are many wrong ways to do it (plus it's application-specific), and it is impossible to modify the data structure once the application is built on top of it and launched into production.

    Regards,
    Valeri
  10. Hi Valeri,

       Having faced this problem before, I couldn't find a solution I was satisfied with. Would you share with us any design ideas?

    Regards,

    Leonardo Bueno