Bugzilla:L10n:Roadmap: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Design considerations: Terms retirement concept added)
(Maketext moved to separate page)
 
Line 1: Line 1:
Here goes Bugzilla localizability roadmap scratchpad.  See also [[Bugzilla:Roadmap]].
Here goes Bugzilla localizability roadmap scratchpad.  See also [[Bugzilla:Roadmap]].
== Use Locale::Maketext ==
== [[Bugzilla:L10n:Maketext|Use Locale::Maketext]] ==
The idea was introduced by mkanat ({{Bug|407752}}).  If implemented, will greatly reduce localizers' workload.  However, there are some implementation obstacles.
The idea was introduced by mkanat ({{Bug|407752}}).  If implemented, will greatly reduce localizers' workload.  However, there are some implementation obstacles.
=== References ===
# [http://search.cpan.org/src/DRTECH/Locale-Maketext-Lexicon-0.73/docs/webl10n.html Web localization in Perl]
# [http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod Localization and Perl: gettext breaks, Maketext fixes] a.k.a. ''TPJ13''
# [http://www.perlmonks.org/?node_id=466225 Template Toolkit, look-and-feel and internationalization]
# [http://mail.template-toolkit.org/pipermail/templates/2008-July/010291.html i18n with Template Toolkit]
# [http://www.cpanel.net/conference/08/files/Localization.pdf '''Cpanel''' localization roadmap]
# [http://act.mongueurs.net/doc/Manual/Developer/Translation.html 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 ====
'''[http://search.cpan.org/~drtech/Locale-Maketext-Lexicon-0.73/lib/Locale/Maketext/Extract/Plugin/Perl.pm#VALID_FORMATS xgettext.pl]''' supports:
translate()
maketext()
gettext()
loc()
x()
_()
__()
In Bugzilla Perl code [https://bugzilla.mozilla.org/show_bug.cgi?id=407752#c5 we will be using]
_()
==== Template Toolkit syntax ====
Formats supported by '''xgettext.pl''' are:
<nowiki>[% |l(args) %]string[% END %]</nowiki>
<nowiki>[% 'string' | l(args) %]</nowiki>
<nowiki>[% 'string' FILTER l(args) %]</nowiki>
<nowiki>[% l('string',args) %]</nowiki>
<nowiki>[% loc('string',args) %]</nowiki>
In fact, <tt>l</tt> and <tt>loc</tt>, <tt>|</tt> and <tt>FILTER</tt> 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 <tt>%Lexicon</tt> entries
* classic '''.po''' files, more convenient to localizers community because of [http://translate.sourceforge.net/wiki/toolkit/index mature tools]
* [http://search.cpan.org/dist/Locale-Maketext-Lexicon-DBI/lib/Locale/Maketext/Lexicon/DBI.pm 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 <tt>Bugzilla/L10N/<i>LANG</i>.pm</tt>
; <tt>Bugzilla/L10N/<i>LANG</i>.po</tt> : Most obvious, used by many projects.
; <tt>template/<i>LANG</i>/{default,custom}/*.po</tt> : Advantages: site and project level customizations possible. Drawbacks: need to iterate through multiple '''.po''' files to merge the lexicon; unneeded exposure to http server.
; <tt>po/<i>LANG</i>.po</tt> or <tt>locale/<i>LANG</i>.po</tt>: 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:
<tt>template/en/default/bug/create/create.html.tmpl</tt>:
[%# no need to PROCESS "global/variables.none.tmpl" %]
[%# no need to PROCESS "global/field-descs.none.tmpl" %]
...
[% |l %]Bugzilla – Enter Bug[% END %]
customized <tt>en.po</tt>:
msgid "Bugzilla – Enter Bug"
msgstr "Bugzilla@mysite – Submit a Service Request"
To ease such customizations (and to provide backwards compatibility) <tt>en.po</tt> would be preprocessed from <tt>en.po.tmpl</tt>:
[% PROCESS "global/variables.none.tmpl" %]
...
msgid "Bugzilla – Enter Bug"
msgstr "$terms.Bugzilla – Enter $terms.Bug"
This way <tt>global/variables.none.tmpl</tt> would be used only during '''checksetup.pl''', to compile '''.po''' files


== Localizable database data ==
== Localizable database data ==

Latest revision as of 13:27, 26 November 2008

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.

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

Coding and layout standards

Packaging

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

Retrieved from "https://wiki.allizom.org/index.php?title=Bugzilla:L10n:Roadmap&oldid=118175"