Creating a new XML based i18n system


Web tier: servlets, JSP, Web frameworks: Creating a new XML based i18n system

  1. Creating a new XML based i18n system (4 messages)

    For a new, rather large, JSF based system we're planning to use internationalisation. Java, and particular JSF ofcourse has support for i18n in the form of resource bundles and support code.

    The problem is that one of the developpers in our team doesn't like the standard approach. He rather wants to develop a custom, XML based system. Some things he has against the standard aproach is:

    - Resource bundles are ugly. Especially numbered placeholder like {1} are not very clear and ugly.
    - There is a seperate bundle for each language. He rather has all languages together in one large file.
    - There is no support for a 'long' and 'short' version of each key.

    The proposal is to use a resource bundle in XML which looks like:


    <text key = "some_key">
       <locale type="some_locale">
            <short>short (abriviated) text</short>
           <long>Longer version of the same text</long>

    Special is that keys may contain taglibs tags and EL. E.g.
    <short> Hallo <outputText value="#{}" /> </short>

    By setting up a managed bean, the custom i18n system can be used everywhere by simply using EL. E.g.

    <h:outputText value="#{i18n.std.some_key}" escape="false"/>

    The above EL accesses the i18n bean, which looks in the page "std.xml" for the key "some_key".

    Part of my own doubts is the fact that it's not the standard and doesn't add that much (but it does add the extra burden of code maintenance). Also, there are a lot of tools out there that support standard resource bundles and offer features like sorting of keys, comparing with other resource bundles to indicate missing keys, etc. Finally, translation services often only accept resource bundles in a standard format. Handing over our own format could be problematic.

    What do you think about this proposed system? Is it better than the existing Java one? Are there any other disadvantages I haven't thought of yet?
  2. Nobody has any oponion about this?
  3. Translaters prefer one language per file.

    The {0} is a problem though. But I'd rather enhance the bundle system with to support {userName} than write my own.
  4. +1
    In the project I'm currently working on, some genious built a custion XML bases i18n library for Swing apps. It's really ugly and non standard. Talk about reinventing not just the wheel but the hole CAR, for the love of God Almighty.
    I guess it all depends on the scope of your i18n approach. Perhaps a property resource bundle is cheaper and faster than the propietary approach your developer suggested, although a little more cumbersome to mantain. But ¡hey!, it's already there, ready to use, AND you don't have to develop and test and debug and... endless etceteras. It all comes down to cost/benefit.

    Cheers and happy coding,
  5. Look at XLIFF[ Go to top ]

    Have a look at what the OASIS group have been doing with XLIFF with respect to translation metadata. This is a defined XML schema for translations. You may not want to drive off it directly but certainly should consider transformations to and from it.