Results 1 to 4 of 4

Thread: Language switching on ORM level

  1. #1
    Join Date
    Mar 2009
    Location
    Switzerland
    Posts
    36

    Default Language switching on ORM level

    Hi,

    i've a requirement to solve which I never encountered (yet). So I'm thinking about a clean approach of solving this:

    My web app is mainly based on Spring MVC 3 and Hibernate provides a language switcher on the UI. So users can switch the language and Spring's I18N support renders different messages on the UI. However this only works for "static" messages.

    I already implemented I18N on database level using a dedicated I18N lookup table which is referenced by multiple hibernate-annotated classes. E.g. I could get a catalogue X object and ask - using different getters - its localized name (e.g. getName_en() or getName_de()). I avoided explicit language parameters for the getters to stick with the clean java bean convention.

    Now what I could think of is a filter in web.xml which sets per request a ThreadLocal variable which is dynamically used when accessing the getters and this dispatches to the correct language getter then (AOP ?).

    Now my question is:

    Is there anyone with experience in solving this ? I bet I'm not the first person on the world implementing this...
    2) Any "clean" proposals on how to design this ?

    I think this can be done in a clean way and it needs to be scalable. So hacks don't interest me to be honest. We are talking (in my case) on accessing the localized names on object trees with round about 50 to 200 bean instances (based on 4-5 different classes).

    Regards, Alex

  2. #2
    Join Date
    Aug 2006
    Location
    Now Germany, previously Ukraine
    Posts
    1,546

    Default

    And what would you do when next language will be added to your requirements? Go over all getters and add a new version for each?
    Not very attractive, to put it mild.
    Quote Originally Posted by rauar View Post
    Hi,

    i've a requirement to solve which I never encountered (yet). So I'm thinking about a clean approach of solving this:

    My web app is mainly based on Spring MVC 3 and Hibernate provides a language switcher on the UI. So users can switch the language and Spring's I18N support renders different messages on the UI. However this only works for "static" messages.

    I already implemented I18N on database level using a dedicated I18N lookup table which is referenced by multiple hibernate-annotated classes. E.g. I could get a catalogue X object and ask - using different getters - its localized name (e.g. getName_en() or getName_de()). I avoided explicit language parameters for the getters to stick with the clean java bean convention.

    Now what I could think of is a filter in web.xml which sets per request a ThreadLocal variable which is dynamically used when accessing the getters and this dispatches to the correct language getter then (AOP ?).

    Now my question is:

    Is there anyone with experience in solving this ? I bet I'm not the first person on the world implementing this...
    2) Any "clean" proposals on how to design this ?

    I think this can be done in a clean way and it needs to be scalable. So hacks don't interest me to be honest. We are talking (in my case) on accessing the localized names on object trees with round about 50 to 200 bean instances (based on 4-5 different classes).

    Regards, Alex

  3. #3
    Join Date
    Mar 2009
    Location
    Switzerland
    Posts
    36

    Default

    Well. As I wrote I'm open for any proposals. Something like doing this using an interceptor or something like that... didn't have the time to think more about this issue yet. Let's see if someone else comes up with a sophisticated idea...

    Regards, Alex

  4. #4
    Join Date
    Aug 2006
    Location
    Now Germany, previously Ukraine
    Posts
    1,546

    Default

    Not very sophisticated but usable idea is to set ThreadLocal exactly as you wished and then use its value in the respective getters.
    Quote Originally Posted by rauar View Post
    Well. As I wrote I'm open for any proposals. Something like doing this using an interceptor or something like that... didn't have the time to think more about this issue yet. Let's see if someone else comes up with a sophisticated idea...

    Regards, Alex

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •