Announcement Announcement Module
Collapse
No announcement yet.
Language switching on ORM level Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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.
    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

    Comment


    • #3
      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

      Comment


      • #4
        Not very sophisticated but usable idea is to set ThreadLocal exactly as you wished and then use its value in the respective getters.
        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

        Comment

        Working...
        X