l10n + custom fields

MattyT matty at chariot.net.au
Thu Oct 17 05:29:05 UTC 2002

On Thu, 2002-10-17 at 10:19, Bradley Baetz wrote:

> What about stuff like product/component descriptions? Or keyword/flag 
> descriptions? Then again, for an installation which only supports one 
> language (whatever that language may be), they can just write the 
> description in that language. That may be the best solutionm.

I've been thinking about this somewhat, and I initially had the same
reservations as you about the two approaches.

However, the more I think about it, the more I'm convinced that putting
the translations into the database is the way to go.

This would involve a subsidiary table for name and description of
keywords, groups, etc.  A "default" name and description could probably
still sit on the main table for the case nothing matches.

The performance issue I don't believe is major, on the proviso that our
target databases support compound primary keys (I don't know if they do,
I hope so), which would be on value-ID/language.  In this situation you
need to do an extra join, but it's a simple index lookup.  If you want
to support locales within languages, then that's a bit more complicated,
I think it would either need to be a subselect using LIMIT (to select
the most appropriate record), or alternatively two joins, one against
the language (although this could return multiple records too I
suppose), and one against the language/locale.

I have a hard time believing this is an area we have performance
problems anyway, and we already have a caching solution (versioncache)
to negate the effects of slow queries.  If we stick with versioncache
there would need to be a different one for each language, but that's
pretty easily done.  If we don't, and this is a performance hit,
whatever future caching solution we use should be able to deal with it.

And as for the extra complexity it would add to queries, this should not
be a problem if we add functionality to the eventual back end API to
transparently generate the appropriate SQL and return the correct

         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital

More information about the developers mailing list