Bugzilla:L10n:Roadmap: Difference between revisions

Maketext moved to separate page
(→‎References: more sources added)
(Maketext moved to separate page)
 
(4 intermediate revisions by the same user not shown)
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 [Templates] 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]''' already support these:
translate()
maketext()
gettext()
loc()
x()
_()
__()
Perhaps we should pick one coherent syntax.
==== 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
==== 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> : Why not create a separate dir?


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

edits