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


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:)).


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.