Custom fields design doc

[Gervase Markham]

Sean McAfee wrote:
>>By this time, my desire to avoid requiring the admin to twiddle templates is
>>well-known.  Hmmm.  OK, how about storing display names in a table like
>>this:
> 
> [snip]
> 
> OK, I had a better idea.

The problem with your old idea, should you be interested, is that it 
assumes a Bugzilla will only be used in one language at once.

>  Leave the display_name in custom_fields as
> I originally proposed.  The name in the table represents the field's
> display name in a default locale, which can be a new Bugzilla parameter.
> Those who want to provide alternate names for different locales can
> override the default on a per-locale basis in an appropriate template.
> This way, those who don't need to support multiple locales don't need to
> edit templates, and those who do can do so using the mechanism you
> suggested.
> 
> How's that?

The invariants for our current localisation strategy are:

- There should be a single localisation mechanism.
- A localiser should be able to create a tarball which, when unzipped,
   places files which totally enable a Bugzilla for their language.
- An admin should be able to unzip said tarball, add the code for the
   language to a param, and all of Bugzilla starts working in that
   language, as well as the ones it currently works in.
- Bugzilla can be used at the same time by different people in different
   languages.

The first thing is invariant because it makes Bugzilla hackers lives as 
easy as possible. These next two things are invariants because they make 
localisers and admins lives as easy as possible. The last thing is an 
invariant because it pleases users.

This means that any solution which stores strings which need to be 
localised in the database just won't fly, because they can't be updated 
by a tarball.

There's no harm in you writing a shell script or even a web-based UI for 
your site to help people manage custom field labels in an easier way 
(even by directly editing templates; we could split them up to 
facilitate this), but breaking the above invariants breaks our entire 
strategy. Bugzilla is designed to be administered (and changing UI text 
counts as that) by those who are technically knowledgeable. Call it a 
limitation if you like. Writing tools to help the less knowledgeable is 
fine; breaking thing isn't.

I hate to be dogmatic about this, but I've spent the last year working 
on a lot of tedious bugs which move all strings out of every other 
possible location and into templates. 2.16 was somewhat localisable, 
2.18 will be a lot more so. I don't want to agree to something which is 
a backwards step.

Gerv