Discussions

News: cintoo Messages 1.0 released - internalization library

Bookmark and Share Get thread feed

  1. cintoo Messages 1.0 released - internalization library (8 messages)

    cintoo Messages is a free framework to make internationalization easier for Java applications. It adds several features compared to default Java internationalization and support locales for threads and different bundles for different packages. This allows the usage of different bundles for different parts of the application like plugins, the installer or logging. Key features:
    • a lot less code than standard internationalization in Java
    • easier to use for developers
    • supports bundle refactorings
    • bundles associated with Java packages
    • hierarchies of bundles, e.g. one bundle for com.corp and one for com.corp.accounting
    • Low intrusive code, e.g. $(this, "FILE_NOT_FOUND", fileName)
    • Locales per thread or global
    • Apache license
    Reply to this

    Threaded Messages (8)

  2. Cool, but...[ Go to top ]

    It may be usefull, but I think every time you need to translate something in your business code, you're missing something: It the presentation framework that should translate your message. In Strusts (sorry, I am old school), the tags translate your messages, exceptions, etc. I have developped a personnal Swing framework that do the same for heavy client. Instead of: } catch(FileNotFoundException ex) { show($(this, "FILE_NOT_FOUND", ex.getMessage())); } I just let the exception going, and somewhere I got in a bundle: java.io.FileNotFoundException=The file :null can't be found It's not deep inside my business code that I have to know which language the user use. It's the presentation tier job. Adrien
    Reply to this Reply to original

  3. Almost...[ Go to top ]

    It may be usefull, but I think every time you need to translate something in your business code, you're missing something: It the presentation framework that should translate your message. In Strusts (sorry, I am old school), the tags translate your messages, exceptions, etc. I have developped a personnal Swing framework that do the same for heavy client.

    Instead of:

    } catch(FileNotFoundException ex) {
    show($(this, "FILE_NOT_FOUND", ex.getMessage()));
    }

    I just let the exception going, and somewhere I got in a bundle:

    java.io.FileNotFoundException=The file :null can't be found

    It's not deep inside my business code that I have to know which language the user use. It's the presentation tier job.

    Adrien
    It's naive to think the UI is the only place i18n stuff is appropriate. Yes, perhaps in simple apps that only have one way to interact with them, the UI framework (whatever it is) is initially the most appropriate place to put the translations because it's the most convenient and will help you get to market quickly. But what if your app grows and you later want to print logger messages in different languages too? What if your customers want interactive consoles (no web UI or rich-client UI)? And what if you need to support i18n of configuration files, so the actual property names and/or tags are language/locale-specific too? I guess you could make the claim that configuration files, consoles, and logs are just different views / presentations of data (and thus the respective presentation tiers should be doing the translations). However, when multiple views are offered simultaneously - when your app has a web UI, a rich client interface, and an interactive console all at the same time - are you going to keep translations (some the same or partially overlapping) in three different formats and three different locations just so your presentation tiers can be the responsible translators? No, of course not. Any common messages should of course be pushed to a lower-level framework to do the translations, and any unique messages - even though they COULD be kept separate in their individual frameworks - SHOULD seriously be treated the same as common data and be pushed to the lower level. This will enable better reuse of message translations across different aspects of the app in the future - not just UIs. -joe
    Reply to this Reply to original

  4. Still...[ Go to top ]

    I backup the previous post... i18n is only about interacting with the user so should take place in the presentation layer. And as you said web, console, logs or whatever are just different views. However having different ways of managing i18n accross those different views would just be an architectural mistake, no reason to have a different technology/library to manage i18n and then have different localisation formats. Actually I guess Message can be used to achieve that, the given example is just as trivial as it should be :) Anyway, what I am really looking forward is not for an open source i18n librarie but for an open source l10n management tool. I really feel that this is something that is missing today in the open source world. I mean I could have thousands of nifty features in my i18n framework it would be of little use if the only option I have is to send translators Excel files (translators do not like properties or xml files). Claude
    Reply to this Reply to original

  5. Re: Cool, but...[ Go to top ]

    It's not deep inside my business code that I have to know which language the user use. It's the presentation tier job.

    Adrien
    cintoo Messages was written with Swing/SWT development in mind. So yes, there is a lot of i18n going on in the presentation tier (Swing,SWT,Web) but then there are other places like the installer, the logging, perhaps some plugins which deliver their own bundles you don't want to handle in your app etc. But you can use cintoo Messages and add a Swing layer on top (which should also define the key types as customer.title, city.label ....). And obviously Messages doesn't do anything you couldn't write for yourself, and probably have several times. Still and open source externally developed i18n framework saves your company money.
    Reply to this Reply to original

  6. Dollar function[ Go to top ]

    No comment on the framework itself, but I'm saddened to see the Javascript "dollar function" idiom creeping into Java land...
    Reply to this Reply to original

  7. Re: Dollar function[ Go to top ]

    I still think $ helps readability alot. But you can write _() (like GNU gettext) or format() or Messages.format() if you like.
    Reply to this Reply to original

  8. typo: cintoo Messages 1.0 released- INTERNATIONALIZATION library[ Go to top ]

    :-)
    Reply to this Reply to original

  9. Re: typo: cintoo Messages 1.0 released- INTERNATIONALIZATION lib[ Go to top ]

    Yes, it's not about internalizing things :-)
    Reply to this Reply to original