3 Replies Latest reply on Nov 18, 2013 10:23 PM by jschellSomeoneStoleMyAlias

    Dynamic ResourceBundle without the physical file.

    Florin Marcus

      Hi guys,


      We have a product that runs in a web environment which should allow customers to translate the bundle entries at runtime and the changes to be picked up without re-deployment.  We successfully achieve the goal of translating the resources through using ListResourceBundle implementation, but the problem is we can't offer the customers the ability to add a new language (new Locale).  Currently we need the physical resource bundle java, in order for the users to start translating text at runtime.


      Does anybody know any solution that will allow us to register new Bundles dynamically?






        • 1. Re: Dynamic ResourceBundle without the physical file.

          Storing translations in a database is a quite common approach.

          You could extend ListResourceBundle to fetch translations from database on the fly...




          • 2. Re: Dynamic ResourceBundle without the physical file.
            Florin Marcus

            Thank you for your answer,  as I was mentioning on my initial post, we are already using ListResourceBundle implementations.

            The problem is that we have one ListResourceBundle file for each language, eg:

            1. CustomBundle.java

            2. CustomBundle_DE.java

            3. CustomBundle_FR.java

            So, when we need to add a new language, Spanish for example, we would need to create one more physical file.

            My question: is it any way to handle all 3 languages from a single java file only?



            • 3. Re: Dynamic ResourceBundle without the physical file.

              Rather buried in the docs but the following method


              public static final ResourceBundle getBundle(String baseName)


              Documents the parameter as follows


              baseName - the base name of the resource bundle, a fully qualified class name


              You then nee a class that resolves any calls to the database.  I suspect however that you are actually going to end up using the explicit classloader version of the class since it might attempt to add the language extension to the class name (just guessing) and if that is the case then a custom class loader could be used to return (maybe) a single class with some construction semantics or a proxy.


              At any rate the final class would resolve to a database call.