Bugzilla is a web application written in Perl and Template Toolkit (http://template-toolkit.org/). Existing l10n architecture assumes creation and maintenance of translated template set. However, templates aren’t very good in separation of logic and natural language. So each translation maintainer has to merge many changes not involving texts (see discussion at http://markmail.org/message/r3mgtn3mecsoeeij). Now we have not so much successful and well-maintained localizations.

Right solution would be moving to Maketext (https://wiki.mozilla.org/Bugzilla:L10n:Maketext#References). Maketext is already immune to some problems leading to L20n invention. In particular, Perl is not a compiled language and supports dynamic code well. If implemented, Maketext support would allow for well-known message catalog formats, tools and workflow — and hopefully increase Buzgilla localizability.

Goals are (a) reduce localizers’ maintenance workload and (b) eventually get more translations with tools like Launchpad Rosetta or Transifex or Narro or Pootle…

However, move to Maketext is not easy, current implementation sometimes make template syntax ugly beyond repair: https://bugzilla.mozilla.org/attachment.cgi?id=356254&action=diff#bugzilla-tip/template/en/default/account/profile-activity.html.tmpl_sec3

Future challenges include: (a) customizable terms, which involves static message catalogs preprocessing, (b) localizable database values, populating l10n lexicon from message catalog files *and* database at the same time.

Are you driving l10n for Bugzilla? Would love to learn more about that.

WRT l20n, it’s definitely not dead. So, please do add your comments to L20n:Issues.

Thanks!

Seth

Being a Web application, Bugzilla is rather verbose, compared to desktop apps. OTOH high customizability is required: basically users want to rename most objects (Bug, product, component, platform, etc) according to their reality. Not so hard to achieve in English, but leads to complications in many languages, due to various long distance dependencies.

I will try to expand https://wiki.mozilla.org/L20n:Issues.

I’m excited that this effort works towards trying to solve these issues for real languages. But my questions remain mostly unanswered 1) At what cost? 2) Are we solving problems that we ourselves created e.g. &brandShortName;.

Some problems aren’t worth solving when weighed against the costs and some can be solved by changing some current practises. Its within that context that we should be evaluating any interventions.

PS: How about getting some interns to see if Silme can be used as a backend to Virtaal and Pootle?

I am stumped in terms of how to present this to a localiser and that concerns me greatly. If we are unable to present this to a localiser then that has a serious negative impact on localisation of a product that uses l20n.

I don’t think we can use the excuse that simple strings are unaffected. This framework is designed for strings that are not simple, simple strings just aren’t part of that equation. Using that argument I could say “Why bother, Polish is only affected in 5% of the case so its not worth the effort”. I’m not saying that though What I am saying is that complexity cannot be judged by how easy the other stuff is or isn’t it needs to be judged on this intervention alone.

So I did the sums:
+ Firefox 3.1b3 – 5401 strings
+ &brand – 107 strings (I use these are examples of declention counts, they’re probably higher)
+ (s) – 11 strings (plurals although in many cases not and I’m sure I’ve missed a few that should be plural)

Assuming 1 minute per string then we have Firefox in 3.75 days

Only 2% of the strings are l20n strings in my calculations. They take 2 hours to localise. In the current state of l20n I would calculate that they will take much longer with this added complexity. Lets say 5 minutes per string so it now takes 10 hours to localise. We’ve added 1 whole day of complexity to the localiser, not to mention added complexity for review, for QA and for bug fixing.

Again my question is this, is this complexity worth it and/or can we hide this complexity.

I would argue that l20n MUST think about how to present this data visually impacts localisers, the framworks usefullness and wider adoption in tools. I hope I’ve made a good argument about why this can’t ignore presentation.

I’m happy to try figure it out with you.

I find it very valuable because it presents L20n concept from another angle.

In cases such as bug 473706, Entity will receive given number of variables that may influence it, but it will be up to the localizer how he will use them. In result I don’t expect any complexity increase. I would even expect decrease do to ability to customize the logic.

I’m not sure if we can and/or want to separate layers… I’m afraid that this would raise complexity while the gain from readability would not be as high as expected due to small size of each file.

As for language logic, that shouldn’t really be in the lol files either, but in external files to be shared by editing applications. The “symptoms” of that show in the lol file, but the actual language logic like which noun classes a language would have should be in external files.

I need to comment in bug 473706 again, too.

Furthermore en-US still has some complexity. It will be nice that the reference implementation is simple enough for localizers to understand what they should translate and what is not necessary to be translated.

Current l20n divides the application into three layers:
Application / L20n library / lol file
while lol file will contain three more layers:
- language logic
- word dictionary
- strings for the application
Logic (e.g. plural rule) establishs the contents of the dictionary and one word in the dictionary is comsumed in many strings.
It would be great if each layer in lol file is clearly separated though I don’t know how to do that.