Here goes Bugzilla localizability roadmap scratchpad. See also Bugzilla:Roadmap.
The idea was introduced by mkanat (bug 407752). If implemented, will greatly reduce localizers' workload. However, there are some implementation obstacles.
Localizable database data
From localizer's view, Bugzilla consists of fixed user interface (implemented using templates) and some database values. Database fields fall into four categories:
- No need for translation whatsoever
- non-text fields
- never displayed to user
- Directly associated to a language
- Comments and descriptions are written on certain language. If someone translates one, this makes another comment. This is a common scenario in vendor escalation of native language support cases.
- Translatable fields
- Fields which should be displayed on user's language. In 3.0, Status and Resolution translations are supported.
- Dependent fields
- Not directly translatable, some fields may still take different values depending of language. For example, default assignee is expected to read initial description. QA may communicate with reporter to confirm resolution. Both fields may need to take different values if reporter uses localized interface to file a bug.
More translatable fields
bug 406222 applies the same TT tools to translate Severity, Platform, OS, and values of setup parameters.
However, this leads us nowhere: if localizers move to gettext, site customization would require extra skills, beyond Template Toolkit.
Generic database level field translation
A better approach would be:
Content should be localized same way it was created. That is, UI features to be translates in templates, and database fields -- in other database fields.
This requires some careful design however. Adding LANG value as unique key component to some tables may hurt 3NF. Adding new detail tables (key, LANG, text) will require a lot of compatibility views. Default language fallback may severely hurt performance if implemented in straightforward fashion on a query level.
Coding and layout standards
Having uniform package layout, we will be able to package template sets for various distributions, like RPM or MSI.