Directions In Architectural Redesign
gerv at mozilla.org
Sat Jan 24 09:08:38 UTC 2004
> As best as I can tell, the only real solution is to put this information
> into the database and let the administration system edit it. A separate
> table for names against language is one solution. Alternatively, we
> might try packing the name field.
I'm sure we've had this discussion before, either on this list or in a
bug. But I'm summarise my points again :-)
One of the very good things about our current localisation architecture
is that installing new localisations is very simple. You drop a set of
templates into template/<lang>/, add the <lang> value to the param list,
and you are off to the races. Whatever solution we come up with needs to
preserve this. We can't put translations in the database.
However, I can see your point that, in the usual case of a single
language, the admin does not want to edit templates when he adds or
removed customised whatevers (hereafter known as "thingys").
How about this:
When you define a new thingy, you give it a name. This is a string, e.g.
WORKSFORME. The thingy can be translated in templates via an override:
[% thingy_descriptions.thingy || thingy %]
The default Bugzilla thingys are well-known, and translations for them
(and perhaps a few common alternatives) will ship in translation packs.
If you add a new thingy, and are only using one language, you just make
the name of the thingy the name that you want displayed.
However, if you add a new thingy, _and_ are using multiple languages,
you need to translate that thingy and add it to the description list;
otherwise, when using any language for which you haven't done a
translation, you'll get the bare name displayed.
More information about the developers