2 Replies Latest reply on Sep 4, 2009 5:40 PM by 843810

    Table per locale - i18n application development approach

      I learn that I shall use table per locale approach for a multi-language application development. And I am in a situation that no all entries will have multi-language versions. I can image some possible issues on data retrieval and update. Can anyone share experience in this regard?

      Thanks very much in advance.
        • 1. Re: Table per locale - i18n application development approach
          I would share my experice here.

          For the internationalization of our product, we do not have a table per locale, rather we have a row per locale in the appropriate table. We have localeCode, messageCode and messageDescription columns in that table and the application picks up the right row depending on user locale.

          By default we have English data in the database. For inserting french data we run a database script which inserts same rows as English rows appended by some french characters. This is for internal testing purpose only.
          In addition, we also run another translation script for creating locale specific resource bundle files and tiles files.
          So, labels will come from tiles files and data/messages would come from resource bundle and database. These scripts will not be delivered to the customer. They have their own translators and its their job to provide translations at all necessary places.

          After running this script we have experienced that the server takes more time to startup.

          • 2. Re: Table per locale - i18n application development approach
            Thanks for sharing, Rahul.

            I am not sure that duplicated row per locale is a good approach at least for my application usage. In my application, retrieving date is for one locale, but not all. For your approach, you need to have one fetching query statement for each locale date. And you have a row of data, the locale, in a table only is valid for one row of data, what locale the data is. That might not be a good schema design practice. But, the read and write operations are quicker than the join table approach.

            I think the challenge part is various presentations (read as multi-languages) of the same entry. Otherwise, it is not difficult at all, [like this small utility multi-language web application for bookmark, directory, and reminder|http://homepage.kgbinternet.com].

            Edited by: vwuvancouver on Sep 4, 2009 10:39 AM