Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi Werner,

On Wed, 13 Aug 2014 08:09:31 +0200
Werner <> wrote:


On 8/13/2014 1:18, Paul wrote:
Hi Mark,


Normally, localization is done by having a plain text file with all
the application strings in it, and this file is simply copied and
each string translated for each different language. Then at run
time the application knows which locale it is in, and looks in the
appropriate file for all the translated application strings. But
they can just as easily be stored in the database, though.

I18N (Internationalizing) for user interface labels is relatively
easily done in most languages, one way is to use gettext which is
supported by a lot of programming languages.

Doing I18N for database tables is another story, a few years ago I 
looked around for support of I18N support for database tables and at
the time I didn't find any, have you found one?  The storing of the
I18N data is relatively easy, but how to access that from the
application depending on user login in and how to fall back to a base
language in case a value is not translated is not that easy (at least
in my view:)).

I don't know of any frameworks for I18N in databases, although I'm not
sure of the level of support in things like Django, CakePHP and other
web frameworks. From what my brief research has shown, most of them do
have some level of support.

Possibly the best support I saw was in Propel, a PHP ORM.

Also, these articles discuss the actual database design and present
different standard options:

Storing the data with a good structure makes the queries only a little
harder, usually one extra join, although that doesn't take into account
fallback language.

The Propel behaviour seems quite sensible to me. If you aren't going to
use an ORM, I would suggest at least making a wrapper in your code to
manipulate queries and add the extra join, so for the rest of the
code you don't have to worry about that detail, and just do queries as

If you need a default language, I would probably keep the default
language values in the original table, and just store translations in a
translation table. Then you can have the wrapper detect if the current
locale is the default language, and do nothing in those cases. If the
locale is different, then get both the field from the original table
and the translation, and have the wrapper pick up if the translation is
blank, then substitute the default value, and write to whatever
logging system you are using noting the incomplete translation.

Just my thoughts. Googling brought up quite a few other links, mostly
to StackOverflow, and the discussions gave more options and further


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.