Custom fields design doc

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>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.

It seems to me that a distinction can be drawn between relatively
static localized text, such as the static content of an HTML document,
and relatively variable localized text, such as field display names or
the labels of a selection field, either of which an administrator might
update frequently.  The former clearly belongs in a template file, but it's
not so obvious to me that the latter does as well.

>The first thing is invariant because it makes Bugzilla hackers lives as 
>easy as possible.

Modifying template files in-place programmatically, with all of the
necessary locking mechanisms, doesn't seem particularly easy.

>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.

But custom field information is metadata particular to a specific
Bugzilla installation.  Obviously it's desirable to be able to unpack
(say) a French localization tarball onto an existing installation and
have Bugzilla immediately start presenting pages in French, but of what
use would it be to include in that tarball localization information
for custom fields from some other installation that don't exist in the
target installation?


-- 
Sean McAfee -- etzwane at schwag.org