Open Bug 412161 Opened 17 years ago Updated 12 years ago

Localize default English templates with maketext

Categories

(Bugzilla :: User Interface, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: vitaly.fedrushkov, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: intl, l12y)

Attachments

(2 files, 4 obsolete files)

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?
Keywords: l12y
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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).
Keywords: intl
Attached patch patch v1 (obsolete) (deleted) — Splinter Review
Proof of concept: messages.html.tmpl and user-error.html.tmpl are skipped. Comments from localizers and mkanat are especially welcome.
Attachment #298020 - Flags: review?(mkanat)
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).
Attachment #298020 - Flags: review?(mkanat)
OK now this bug is now redefined as part of bug 407752 effort.
Depends on: 469732
Summary: Remove English-specific logic from default templates → Localize default English templates with maketext
Attachment #298020 - Attachment is obsolete: true
Attached file maketext template markup helper (obsolete) (deleted) —
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...
Attached file maketext template markup helper v2 (deleted) —
A closer shaving version of the same.
Attachment #354083 - Attachment is obsolete: true
Attached patch Sample of templates converted to maketext (obsolete) (deleted) — Splinter Review
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.
Attached patch Sample templates converted to maketext v2 (obsolete) (deleted) — Splinter Review
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(-)
Attachment #356254 - Attachment is obsolete: true
Depends on: 476305
Depends on: 481796
No longer depends on: 476305
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(-)
Attachment #359941 - Attachment is obsolete: true
Depends on: 476305
No longer depends on: 481796
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.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: