Bugzilla:L10n:Roadmap

Here goes Bugzilla localizability roadmap scratchpad. See also Bugzilla:Roadmap.

Use Locale::Maketext

The idea was introduced by mkanat (bug 407752). If implemented, will greatly reduce localizers' workload. However, there are some implementation obstacles.

References

1. Web localization in Perl
2. Localization and Perl: gettext breaks, Maketext fixes a.k.a. TPJ13
3. Template Toolkit, look-and-feel and internationalization
4. i18n with Template Toolkit
5. Cpanel localization roadmap
6. How to support a new language in Act

Design considerations

There are several decisions to be made before one start hacking templates and code:

• Syntax for localizable texts in Perl and TT
• Lexicon format
• Directory structure
• Usage of auto lexicon entries and exceptions
• Backwards compatibility
• $terms.bug retirement

Perl syntax

xgettext.pl supports:

translate()
maketext()
gettext()
loc()
x()
_()
__()

In Bugzilla Perl code we will be using

_()

Template Toolkit syntax

Formats supported by xgettext.pl are:

[% |l(args) %]string[% END %]
[% 'string' | l(args) %]
[% 'string' FILTER l(args) %]
[% l('string',args) %]
[% loc('string',args) %]

In fact, l and loc, | and FILTER are synonyms.

First syntax has obvious advantages for large boilerplate texts which we do not want to chop in perverse ways. However, it is too verbose for short strings and unintuitive for parametric calls.

Lexicon format

Available formats also vary:

• simple .pm modules with explicit %Lexicon entries
• classic .po files, more convenient to localizers community because of mature tools
• database backend is in progress

IMHO we should stick to .po, see #Terms retirement below.

The directory structure

For .pm files there is no good place besides Bugzilla/L10N/LANG.pm

Bugzilla/L10N/LANG.po

Most obvious, used by many projects.

template/LANG/{default,custom}/*.po

Advantages: site and project level customizations possible. Drawbacks: need to iterate through multiple .po files to merge the lexicon; unneeded exposure to http server.

po/LANG.po or locale/LANG.po

Why not create a separate dir?

Terms retirement

In object-oriented spirit of Maketext, application should not care about how to say something, just what to say. So default English templates may safely refer to 'bugs', and leave the rest to l10n logic. Example:

template/en/default/bug/create/create.html.tmpl:

[%# no need to PROCESS "global/variables.none.tmpl" %]
[%# no need to PROCESS "global/field-descs.none.tmpl" %]
...
[% |l %]Bugzilla – Enter Bug[% END %]

customized en.po:

msgid "Bugzilla – Enter Bug"
msgstr "Bugzilla@mysite – Submit a Service Request"

To ease such customizations (and to provide backwards compatibility) en.po would be preprocessed from en.po.tmpl:

[% PROCESS "global/variables.none.tmpl" %]
...
msgid "Bugzilla – Enter Bug"
msgstr "$terms.Bugzilla – Enter $terms.Bug"

This way global/variables.none.tmpl would be used only during checksetup.pl, to compile .po files

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.

l10n unification

Packaging

Having uniform package layout, we will be able to package template sets for various distributions, like RPM or MSI.