Open
Bug 426222
Opened 16 years ago
Updated 10 years ago
Make params values localizable
Categories
(Bugzilla :: User Interface, enhancement)
Tracking
()
NEW
People
(Reporter: vitaly.fedrushkov, Unassigned)
References
Details
(Keywords: l12y)
Attachments
(1 file, 2 obsolete files)
8.94 KB,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
Database values can be made more localizable with more macros like 'get_status' and 'get_resolution'.
Attachment #312762 -
Flags: review?
Reporter | ||
Updated•16 years ago
|
Attachment #312762 -
Flags: review?(shimono)
Attachment #312762 -
Flags: review?(LpSolit)
Attachment #312762 -
Flags: review?
Reporter | ||
Updated•16 years ago
|
Attachment #312762 -
Flags: review?(cedric.corazza)
Reporter | ||
Comment 1•16 years ago
|
||
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.
Reporter | ||
Updated•16 years ago
|
Attachment #312762 -
Flags: review?(wurblzap)
Comment 2•16 years ago
|
||
I think you should do parameters in a separate bug, and keep this one focused on fields.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•16 years ago
|
||
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)
Reporter | ||
Comment 4•16 years ago
|
||
(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)
Updated•16 years ago
|
Assignee: ui → vitaly.fedrushkov
Comment 5•16 years ago
|
||
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.
Reporter | ||
Comment 6•16 years ago
|
||
(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
Comment 7•16 years ago
|
||
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..
Comment 8•16 years ago
|
||
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.
Reporter | ||
Comment 9•16 years ago
|
||
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?
Comment 10•16 years ago
|
||
(And the database will already handle the lexicographical sorting issues for us, so those we don't need to worry about.)
Reporter | ||
Comment 11•16 years ago
|
||
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.
Reporter | ||
Comment 12•16 years ago
|
||
(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
Comment 13•16 years ago
|
||
(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.
Comment 14•16 years ago
|
||
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.
Reporter | ||
Comment 15•16 years ago
|
||
(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 :-)
Comment 16•16 years ago
|
||
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.
Comment 17•16 years ago
|
||
(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.
Comment 18•16 years ago
|
||
(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 19•16 years ago
|
||
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-
Reporter | ||
Comment 20•15 years ago
|
||
(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
Reporter | ||
Comment 21•15 years ago
|
||
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
Reporter | ||
Comment 22•15 years ago
|
||
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
Reporter | ||
Comment 23•15 years ago
|
||
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)
Reporter | ||
Updated•15 years ago
|
Attachment #404440 -
Flags: review?(wurblzap)
Updated•15 years ago
|
Attachment #404440 -
Flags: review?(wurblzap)
Attachment #404440 -
Flags: review?(LpSolit)
Attachment #404440 -
Flags: review-
Comment 24•15 years ago
|
||
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.
Reporter | ||
Comment 25•15 years ago
|
||
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)
Comment 26•15 years ago
|
||
(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.
Updated•14 years ago
|
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Comment 27•14 years ago
|
||
Comment on attachment 412531 [details] [diff] [review] Patch v3 r- per my previous comment.
Attachment #412531 -
Flags: review?(LpSolit) → review-
Updated•14 years ago
|
Target Milestone: Bugzilla 4.0 → Bugzilla 5.0
Comment 28•12 years ago
|
||
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 → ---
Updated•10 years ago
|
Assignee: vitaly.fedrushkov → ui
Status: ASSIGNED → NEW
You need to log in
before you can comment on or make changes to this bug.
Description
•