412161 - Localize default English templates with maketext

Status: NEW

(Bugzilla :: User Interface, enhancement)

Description

[Vitaly Fedrushkov]

From bug 407752 comments.

From l10n standpoint, templates are full of wrong samples.  Quote from .../confirm-delete.html.tmpl:
-----
    Sorry, there
    [% IF comp.bug_count > 1 %] 
      are [% comp.bug_count %] [%+ terms.bugs %] 
    [% ELSE %]
      is [% comp.bug_count %] [%+ terms.bug %] 
    [% END %]
    outstanding for this component.
-----

Quote from Bugzilla-ru:
variables.none.tmpl:
-----
[% MACRO numeral(n, name1, name2, name5) BLOCK %]
  [% n1 = n % 10 %]
  [% n10 = n % 100 - n1 %]
  [% IF n10 == 10 || n1 == 0 || n1 > 4 %]
    [% name5 %]
  [% ELSIF n1 == 1 %]
    [% name1 %]
  [% ELSE %]
    [% name2 %]
  [% END %]
[% END %]
-----

confirm-delete.html.tmpl (translated back to english word-by-word):
----- 
     For a component 
    [% numeral(comp.bug_count,
       "registered(singular) ${comp.bug_count} ${terms.bug}",
       "registered(plural) ${comp.bug_count} ${terms.bug_gen}",
       "registered(plural) ${comp.bug_count} ${terms.bugs_gen}")
    FILTER html %].  
-----

Numeric inflection in Russian has three variants ("one", "few" and "many").  Other languages' mileage _will_ vary :-)

Perhaps we need to ask every localizer first:

1. Are such macros applicable to your language?
2. How many parameters are needed to handle variants?
2. Does this reduce complexity?
3. What other macros (beyond numeric inflection) are applicable?

Comment 1

[A. Shimono [:himorin]]

Japanese don't have plural forms. So, we can accept any form, i think.

1. Yes
2. Only one
3. No, the same as previous.
4.
I think we can choose any suitable form, if we use current one.. All are written in Perl TT, so you can modify or add any new condition, and delete no-needs.

Comment 2

[Max Kanat-Alexander]

This bug is more of a reminder for developers than a request to do something specific, at this point.

Of course if we convert to gettext, yes, English-specific logic will need to be removed from each template converted.

Comment 3

[Vitaly Fedrushkov]

(In reply to comment #2)
> This bug is more of a reminder for developers than a request to do something
> specific, at this point.

> Of course if we convert to gettext, yes, English-specific logic will need to be
> removed from each template converted.

If someone r+ 'MACRO numeral(n, ...)' concept, I will gladly make a patch (sort of backport from Bugzilla-ru).

Comment 4

[Vitaly Fedrushkov]

Attachment: patch v1

Proof of concept: messages.html.tmpl and user-error.html.tmpl are skipped.

Comments from localizers and mkanat are especially welcome.

Comment 5

[Max Kanat-Alexander]

Comment on attachment 298020 [details] [diff] [review]
patch v1

It's not necessary to do this until after we move to gettext, so I'm not going to review this patch at this time.

It would be better to just do these sorts of things a template at a time, while we're moving to gettext (if we do).

Comment 6

[Vitaly Fedrushkov]

OK now this bug is now redefined as part of bug 407752 effort.

Comment 7

[Vitaly Fedrushkov]

Attachment: maketext template markup helper

Another approach to attachment 292503 [details] task:

Instead of parsing template and searching for human readable strings -- one may use existing localization pack, compare it to template/en/default, and mark differences with '{{ }}'.

Usage: maketextize.pl template/{LANG}/default/{file}.tmpl template/en/default/{file}.tmpl

Optimal split regexp is not exactly /\W/: to guess one should test some combinations and diffstat results...

Comment 8

[Vitaly Fedrushkov]

Attachment: maketext template markup helper v2

A closer shaving version of the same.

Comment 9

[Vitaly Fedrushkov]

Attachment: Sample of templates converted to maketext

The proof is in the pudding: to get an idea on how [un]readable templates would become under Maketext, I have converted several of them.

There may be some lessons to learn already, until we start converting all of them.

Comment 10

[Vitaly Fedrushkov]

Follow up:

http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/2fc1f49af30ed5c7

Comment 11

[Vitaly Fedrushkov]

Attachment: Sample templates converted to maketext v2

After some discussion and much controversy here's less ugly syntax.  IMHO it is much clearer about what is filtered and how.  Alas no updated 008filter.t yet.

Scalar operators are more readable and reduce need for BLOCKs only to filter something.

$ diffstat.exe 412161-tmpl.diff
 account/cancel-token.txt.tmpl      |   74 ++++++++++++++-----------
 account/create.html.tmpl           |   26 +++++---
 account/created.html.tmpl          |   10 +--
 account/profile-activity.html.tmpl |   33 +++++------
 index.html.tmpl                    |  107 +++++++++++++++++++------------------
 list/list.html.tmpl                |   15 ++---
 sidebar.xul.tmpl                   |   44 +++++++--------
 welcome-admin.html.tmpl            |   76 +++++++++++++-------------
 8 files changed, 205 insertions(+), 180 deletions(-)

Comment 12

[Vitaly Fedrushkov]

Attachment: Sample templates converted to maketext v3

Here goes another version, using function syntax in place of 'FILTER html'.  I hope this is more readable than previous postfix syntax (from bug 481976) 

$ diffstat -p 4 -f 4 412161-tmpl.v3.diff
 Template.pm                        |   25    25     0     0 ++++++++++
 account/cancel-token.txt.tmpl      |   74    43    31     0 ++++++++++++++++++--------------
 account/create.html.tmpl           |   26    15    11     0 ++++++-----
 account/created.html.tmpl          |   11     4     7     0 +---
 account/profile-activity.html.tmpl |   35    17    18     0 +++++++--------
 index.html.tmpl                    |   85    46    39     0 ++++++++++++++++++++-----------------
 list/list.html.tmpl                |   10     2     8     0 ----
 sidebar.xul.tmpl                   |   46    23    23     0 ++++++++++----------
 welcome-admin.html.tmpl            |   76    40    36     0 +++++++++++++++++----------------
 9 files changed, 215 insertions(+), 173 deletions(-)

Comment 13

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.