Re: [libreoffice-users] Re: Currently Using Spreadsheet for Personal Project - Thinking About Database

Hi Werner,


On Wed, 13 Aug 2014 08:09:31 +0200
Werner <wernerfbd@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+unsubscribe@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