Custom fields design doc

[Daniel Berlin]

On Saturday, May 24, 2003, at 04:36  AM, Bradley Baetz wrote:

> On Fri, May 23, 2003 at 08:44:23PM +0100, Gervase Markham wrote:
>> 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.
>
>> - 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.
>
> We still haven't come up with a way to handle admin specified things
> such as product names in this way.

Errr, isn't this type of thing a solved problem (IE haven't other 
internationalized projects been here before)?

In the DB, they are mostly only referred to by ID already (IE have 
separate namespaces)

Some (heavily, i would imagine) included perl file(s) that is/are in 
the template/<language> dir contains a hash table mapping the specific 
id's to strings.

Past that, what's so hard about making the current code use 
Data::Dumper (if you want readability) or IO::Storable (if you want 
speed of loading/storing) to rewrite the approriate file for the 
current language when someone edits a product name?  This makes it web 
editable.

It also seems simple to check if the current language file was modified 
since we last read it in and re-load the hash, and to do this check in 
get_product_name (or wherever).  This makes it hand editable.

>  Custom field descriptions fall into
> the same category, in that a localiaser cannot proivde them, since
> they're specified by the admin. A template which the admin modifies ahs
> the disadvantage that its not web editable.
How is the above not web editable?
Even if the file doesn't exist for the current language, we still know 
how many *things* we need names for, and what the keys are, and thus 
can make up "default" values like "unset localized product name 1", and 
write it out as the file for that language.


> We're probably going to have
> to end up wuth a {language,type,id,text} table at some point.
>
Only if you aren't willing to serialize perl structures in some form.  
If this is a requirement (not serializing perl structures, that is) you 
are pretty much left with the DB to do this.

> Bradley