Open Bug 426222 Opened 16 years ago Updated 10 years ago

Make params values localizable

Categories

(Bugzilla :: User Interface, enhancement)

3.1.4
enhancement
Not set
normal

Tracking

()

People

(Reporter: vitaly.fedrushkov, Unassigned)

References

Details

(Keywords: l12y)

Attachments

(1 file, 2 obsolete files)

Attached patch backport from Bugzilla-ru (obsolete) — Splinter Review
Database values can be made more localizable with more macros like 'get_status' and 'get_resolution'.
Attachment #312762 - Flags: review?
Attachment #312762 - Flags: review?(shimono)
Attachment #312762 - Flags: review?(LpSolit)
Attachment #312762 - Flags: review?
Attachment #312762 - Flags: review?(cedric.corazza)
This is a followup to l10n IRC meeting last tuesday.

Improvement ideas:

1 have single get_field(field, value) macro, to avoid ugly ELSEIFs here and there.
2 show results (readonly) when listing and editing field values.
Keywords: l12y
Attachment #312762 - Flags: review?(wurblzap)
I think you should do parameters in a separate bug, and keep this one focused on fields.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 312762 [details] [diff] [review]
backport from Bugzilla-ru

I can't comment about the code, but from a l10n point of view, this is very useful. Will this affect search and quicksearch? I mean : a search for bugs with "blocker" for instance as a criteria will work with the English version or with its translation?
Attachment #312762 - Flags: review?(cedric.corazza)
(In reply to comment #3)
> I can't comment about the code, but from a l10n point of view, this is very
> useful. Will this affect search and quicksearch? I mean : a search for bugs
> with "blocker" for instance as a criteria will work with the English version or
> with its translation?

Advanced search and boolean charts: yes
Quicksearchhack: no, because database still contains 'blocker' (unless you edit severity field values)
Assignee: ui → vitaly.fedrushkov
I've been thinking... I don't think it's a good long-term solution to localize
database-based values in templates. We do it for status and resolutions, too,
true, but it's awkward -- whenever we change one of those, relaxedly using our
nifty GUI, we afterwards need to scramble down into the cellar and fix the
templates accordingly.

Maybe we should localize template stuff in templates, and database stuff in the
database.
(In reply to comment #5)
> Maybe we should localize template stuff in templates, and database stuff in the
> database.

This discussion was held first when there was much controversy about introduction of custom fields.

Short answer: yes this patch is for Bugzilla 3 only.  It also demonstrates problems (I really dislike ELSIFs here).

Things will change when we come up with generic database level solution.
Status: NEW → ASSIGNED
Once i've thought about how we can localize these values reasonably, and i thought this is one approach. But i think it's not something like a desiable way.

1. The original value is stored in DB (with sorting id). So, i could not accept that the localized values are connected with the english one but not the id.

2. The 'string's are stored in DB and template files, both. It's hard to maintain when we add new values.

If it possible, i think we should make DB field to be able to contain multi-languaged values. like "Critival;ja=ヤバイバグ;fr=xxxx". Of cource, this makes the DB field to be long compaired with the current limit..
  What we can do is move all of these fields to being stored as integers in the bugs table (we already have a bug for this) and then we can add columns to the value tables, or we can add a "translation table" where we have the field_id, language_code, and value_id, and value.
I have already started writing about that:
http://wiki.mozilla.org/Bugzilla:L10n:Roadmap#Generic_database_level_field_translation

Snimono-san, do you mean sort order in another language may be different?  Entities like severity and version probably have single meaningful sequence in all languages.  Not sure about (say) product components.

Could you provide an example where sort order is effectively different in another language, besides obvious lexicographical order?
(And the database will already handle the lexicographical sorting issues for us, so those we don't need to worry about.)
Well, I can provide it myself, from usability standpoint:

http://landfill.bugzilla.org/bugzilla30l10n/enter_bug.cgi?product=Bugzilla%20Localization

Here, user should select a component which de facto means 'language'.  User of
localized interface will (most likely) select the same language.  This may
serve as valid reason to push 'this' component early to avoid scrolling.
(In reply to comment #10)
> (And the database will already handle the lexicographical sorting issues for
> us, so those we don't need to worry about.)

No it won't: currently templates iterate through database values (sort-order OR lexicographical) first, and substitute strings after, with order preserved.
Version: 3.1.3 → 3.1.4
(In reply to comment #11)
> Well, I can provide it myself, from usability standpoint: [snip]

  Okay. That's not important enough to justify that complexity, though, so no need to have different priority values.

(In reply to comment #12)
> No it won't: currently templates iterate through database values (sort-order OR
> lexicographical) first, and substitute strings after, with order preserved.

  Yes, but that's because we have things in the templates. Once we have things in the database, perhaps it will be different.
One problem I can see here is that the user using e.g. french templates would have no idea what to use for quicksearch as he would have to guess the english terms. That's not optimal.

Something else which is not optimal is: how far do we want to go into translating things? This could then involve product and component names, which sounds crazy to me.
(In reply to comment #14)
> One problem I can see here is that the user using e.g. french templates would
> have no idea what to use for quicksearch as he would have to guess the english
> terms. That's not optimal.

Workaround: maintain bilingual user-readable parts:

http://landfill.bugzilla.org/bugzilla30l10n/buglist.cgi?quicksearch=Russian

> Something else which is not optimal is: how far do we want to go into
> translating things? This could then involve product and component names, which
> sounds crazy to me

Advocacy (well, sort of):

When user does silly things and files a bug in b.m.o -- you may quickly point to his error and resolve as WORKSFORME.  But it MAY manifest a bug for pyrzak and that's why we have UE team.

When user files a bug against 'Bugzilla' Product and 'WebService' or 'bugzilla.org' component -- one probably does not need no dictionary at all.  But there are 'User Interface' and 'Dependency Views' and 'Whining' components.  Filing against these _will_ certainly work for you and me -- but it won't work for non English-speaking user.  That's why we have l10n team :-)
We're not discussing how far we're going to go, at this point. All we're talking about is taking the current global <select> fields and making those localizable in the DB. We don't need to discuss how far it's going to go until we see some need to go there.
(In reply to comment #16)
> We're not discussing how far we're going to go, at this point. All we're
> talking about is taking the current global <select> fields and making those
> localizable in the DB. We don't need to discuss how far it's going to go until
> we see some need to go there.

I disagree. This makes perfect sense to discuss this now. I don't want to review something while we don't know how far we want to go. At some point, I may disagree to add more functions, and one will argue that I didn't complain so far?! So I start asking now.

Rather than have all these get_foo() functions, maybe we should have a single get_field('foo', $value) function which takes the field name as the first argument and the field value as the second argument, and returns the translated string if present, else return the passed $value. This would avoid all these ELSIF. So I'm strongly in favour of the first item mentioned in comment 1.
(In reply to comment #17)
> string if present, else return the passed $value. This would avoid all these
> ELSIF. So I'm strongly in favour of the first item mentioned in comment 1.

  Sure, get_field makes sense.
Comment on attachment 312762 [details] [diff] [review]
backport from Bugzilla-ru

OK, let's go with get_field(). This will make the code easier to manage.
Attachment #312762 - Flags: review?(wurblzap)
Attachment #312762 - Flags: review?(shimono)
Attachment #312762 - Flags: review?(LpSolit)
Attachment #312762 - Flags: review-
Depends on: 512623
(In reply to comment #19)
> OK, let's go with get_field(). This will make the code easier to manage.

get_field() implemented by mkanat at bug 512623 as display_value()
Target Milestone: --- → Bugzilla 3.6
Comment on attachment 312762 [details] [diff] [review]
backport from Bugzilla-ru

new patch would address bug 512623 comment 5, covering 'bug_status' and 'resolution'

Other fields (to be replaced where referred explicitly) will have separate bugs
Attachment #312762 - Attachment is obsolete: true
Severity, OS and platform are addressed by bug 519142

This bug has boiled down to params only.
Summary: Make severity, platform, OS and params values localizable → Make params values localizable
Attached patch Patch, params only (obsolete) — Splinter Review
Patch v2, nothing besides admin/params, unrotted.

Localizers' comments are needed: are 'on' and 'off' context dependent and may require different translations for different parameters?
Attachment #404440 - Flags: review?(LpSolit)
Attachment #404440 - Flags: review?(wurblzap)
Attachment #404440 - Flags: review?(wurblzap)
Attachment #404440 - Flags: review?(LpSolit)
Attachment #404440 - Flags: review-
Comment on attachment 404440 [details] [diff] [review]
Patch, params only

>-                        <dt>CGI</dt>
>+                        <dt>" _ get_choice("CGI") _ "</dt>

I don't see the point to translate CGI, Env, DB, RADIUS, etc... And you can translate them in the templates directly, if you really want to. Same for On/Off.


>-            '          <option value="[% item FILTER html %]">[% item FILTER html %]<\/option>' +
>+            '          <option value="[% item FILTER html %]">[% get_choice(item) FILTER html %]<\/option>' +

Only data in <option></option> make sense to be translated this way.
Attached patch Patch v3Splinter Review
OK, all well-known acronyms are removed.

Context added, to allow for different 'on' and 'off' translations: there are fine differences between 'enabled', 'acceptable' and 'allowed'.

(In reply to comment #24)
>-            '          <option value="[% item FILTER html %]">[% item FILTER html %]<\/option>' +
>+            '          <option value="[% item FILTER html %]">[% get_choice(item) FILTER html %]<\/option>' +

> Only data in <option></option> make sense to be translated this way.

Not sure what should I change here...  Could you rephrase your concern?
Attachment #404440 - Attachment is obsolete: true
Attachment #412531 - Flags: review?(LpSolit)
(In reply to comment #25)
> > Only data in <option></option> make sense to be translated this way.
> 
> Not sure what should I change here...  Could you rephrase your concern?

I mean it doesn't make sense to call get_choice() for hardcoded values. Directly translate them in the templates if you want to.
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Comment on attachment 412531 [details] [diff] [review]
Patch v3

r- per my previous comment.
Attachment #412531 - Flags: review?(LpSolit) → review-
Target Milestone: Bugzilla 4.0 → Bugzilla 5.0
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 → ---
Assignee: vitaly.fedrushkov → ui
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: