Localizers' Guide
This guide outlines how to make a localised copy of Bugzilla. However, you are strongly advised to make yourself known in the newsgroup (news://news.mozilla.org/mozilla.dev.apps.bugzilla) before you start.
Overview
The key technology for localising Bugzilla is UI templates. This separates the content from the presentation.
We recommend that you begin by localising the current stable release.
Doing the Localization
I am assuming you are creating a localization for a language code "xx". You need to create a directory template/xx/default under the Bugzilla root, and recursively copy the contents of template/en/default into it, leaving out files which need no translation. Localizations should not use the "custom" directory, which is for site-specific customisations only, and is guaranteed not to be overwritten by new Bugzillas or language packs.
Note that you can create a localization for a two-part RFC 1766 language tag xx-YY - e.g. "en-GB". If there is no matching "xx" localization in your template directory, users specifying "xx" will get the first matching "xx-YY" localization. If the user specifies "xx-YY" specifically, and there is no matching "xx-YY" in the template directory, it will not fall back to "xx". The user can choose if they want it to fall back by specifying both in their browser, in most browsers.
Once you've got a copy of the templates, start translating the English in them. It should be obvious what to translate and what not to translate. Template toolkit directives and variables can be found inside [% %] tags - don't translate these. You can, however, move them around within a sentence for localization purposes.
We strongly encourage you to use UTF-8 as character set encoding. New Bugzilla installations use UTF-8 as default.
Also, some times are formatted in the template using time2str - if this is true, you can rearrange the time format to suit your locale.
This may take a significant amount of time - there are over 200 templates. You may wish to share this work among multiple contributors.
Translating Hard-Coded Strings
There is a good trick for translating hard-coded strings for display, which is best demonstrated with a code fragment:
If the original code looks like this:
[% order FILTER html %]
You can replace it with something like this:
[% ordersdesc = {
"Reuse same sort as last time" => "zuletzt verwendeter Reihenfolge",
"Bug Number" => "Fehlernummer",
} %]
[% ordersdesc.$order FILTER html %]
You use a hash to map from the hard-coded English to the localised version, for display only.
Creating a Localization Pack
To create a localization pack, tar up the contents of template/xx/default and make it available. Remember to mark it with the version number of the Bugzilla it corresponds to.
If you would like it listed in the localizations list on the Bugzilla download page, then you need to set up a web page which at a minimum lists which versions of Bugzilla your templates are made for, who's maintaining them, and contains links to the actual language pack tarballs (or instructions for how to retrieve them from CVS if you prefer to maintain them that way). Our recommendation is to set up a project for it on Sourceforge. The German localization is a very good example, though by no means do you have to get that fancy :)
Using A Localization
To install a localization pack, untar it into your Bugzilla directory so it appears in template/xx/default/ . ('xx' would be replaced with the language code of the pack you're installing, of course)
If you have Bugzilla 3.0.x or earlier, you need to set the languages and defaultlanguage parameters appropriately, too. (The defaultlanguage parameter needs to be kept at en if the localization pack doesn't provide all template files, because Bugzilla can then fill the gaps from English templates on demand.)