Hi Werner,
On Wed, 13 Aug 2014 08:09:31 +0200 Werner <werner...@gmx.ch> wrote: > Hi, > > 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. http://propelorm.org/blog/2011/01/11/propel-gets-i18n-behavior-and-why-it-matters.html Also, these articles discuss the actual database design and present different standard options: http://www.codeproject.com/Articles/8084/Creating-multilingual-websites-Part#databasedesign http://www.apphp.com/tutorials/index.php?page=multilanguage-database-design-in-mysql 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 normal. 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 reading. Paul -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
