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

Hi Mark,

On Tue, 12 Aug 2014 22:37:18 +0100
Mark Bourne <> wrote:


Also, then you can localize your status names if you ever want to
make your program support other languages.

Something else I haven't had to worry about, but if I did I'd have
done the localisation in the application - the enum values (as I use
them anyway) are not generally displayed as-is to the user anyway,
they're just convenient names to use in the database. Using localised
status names in the database table surely hinders localising the
application - if you wanted to connect both English and French
front-end applications to the same back-end database, wouldn't they
both get the same status names to display, rather than the names
appropriate for the application language? Or would the status table
in that case contain strings in one language (or perhaps even generic
keywords) for which the application would look up translations in
it's own localisation table?

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.

(Sorry, I know you probably know that, just including it all for
anybody reading that isn't as familiar with this stuff.)

Now, I've never actually dealt with localization myself, so I'm
guessing a little, and not sure what might be considered best
practice out in the wild. But obviously you wouldn't want to add a new
field to each table for each language, although you might if you were
only dealing with a small, restricted set of languages. But generally
you want that sort of stuff stored as data, not as structure, because
it's easier to add rows than it is to add fields. So I'm guessing one
solution would be to add a language code field to the lookup table, and
make a composite primary key of that and the ID. Then you can enter one
row for each status for each language.

But generally I think composite keys are considered bad. Although maybe
not, but I don't like them, at least. So another approach is to link on
something other than the primary key. One thing we often did with
lookup tables was have a short code and a description for each, so for
purposes of the application you would use the code, but you could
display the description to the user. And use whichever one fit better
for printing. So you could use the short code as the foreign key from
whatever table references the status table, instead of the ID. Then the
status table could still have a single primary key field of the ID, and
just a unique constraint on the short code and language fields. Again,
one entry for each short code and language pair, with the translated
description. The disadvantage of this is not having the primary key of
the lookup table as the foreign key of the referencing table.

For me once you have a database, there are other questions, like what
are you storing in the database (user entries as opposed to programmer
entered things like statuses)? Do those need to be translated?
If they do, then you've got a whole different set of problems, but
assuming they don't, then you only have to translate the scaffolding

I'd want to keep the translation of database stuff in the database. At
least then it's easier to update if you ever do need to make changes.
Just add a status, and add all the translations for it. Otherwise, if
it's an enum, and then the translations are in the frontend, you need
to not only update the database structure to add an enum, you also need
to update all the frontends to have the new translation (even if that
doesn't actually require a recompile).


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.