Directions In Architectural Redesign

[Gervase Markham]

MattyT wrote:
> 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.

Gerv