Closed Bug 215149 Opened 21 years ago Closed 20 years ago

Replace bug statuses/solutions with tags in bugs/edit.html.tmpl

Categories

(Bugzilla :: User Interface, defect)

Product:
Bugzilla
Component:
User Interface
Version:
2.17.4
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 215148

People

(Reporter: omgs, Assigned: myk)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030625 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030625 In 2.17.4, when showing/editing a bug, the formal statuses/resolutions (and it may be applicable other fields) values, appear repeatedly as normal text in the file bugs/edit.html.tmpl. This forces to re-translate every ocurrence manually, when this can be avoided by replacing it with the only-once-translated-and-centralized description (actually bug 215148). Reproducible: Always Steps to Reproduce: I have replaced the solutions system. If the line is Mark bug as <b>CLOSED</b><br> now it's Mark bug as <b>[% bug_status_l10n.CLOSED %]</b><br> and the translation is done only once in field-descs.none.tmpl, and is valid for any localization. This must be extended to every ocurrence of bug_statuses, and any other field I may not be aware right now.
I can fix this myself (that is, I can do the work for the next release), but it would be better if somebody gave me the headlines just for the names of the variables themselves. "bug_status_l10n" might be better, as stated in bug 215148.
Depends on: 215148
Version: unspecified → 2.17.4
Blocks: 214907
This issue will be fixed when statuses and resolutions become customisable (whenever that is.) So the question is: do we want to fix it before that as well? I can see that it might save a little time, but we then start to open up a big can of worms - people may then claim other common words or phrases should get this treatment. (We did "bug" and friends because that's by far the most common request.) My vote is for not making this change. The English templates have English in them - that's the way it goes. Gerv
Well, this is for spanish. Of course, I have the english ones, too. You can take a look at http://landfill.bugzilla.org/bugzilla-2.17.4-es/, where they're uploaded, and switch languages (en, es) in your browser to see the results.
I don't quite understand what you are saying. Maybe I'm missing something. As I understand it, this bug is about replacing "UNCONFIRMED" with [% statuses.UNCONFIRMED %]. The only way that helps translators is that they have to type WIZBANG (the translation of UNCONFIRMED in my invented language) less times; instead, they edit the text around [% statuses.UNCONFIRMED %], bearing in mind that it'll be replaced with WIZBANG. It's merely a matter of convenience - this bug does not, itself, prevent full localisation of Bugzilla. Is that right? Gerv
Well, bug status, resolutions and other descriptions are necessary in some templates in order to be localized. It might mean some extra load for the server, or even extra work for developers. In english templates, you might not want to act that way, but I find something like this necessary at least in most of the templates for being localized, because there's no plain text like in this case, so I was basically asking if there was something wrong with the schema itself or coding style (variable names, code optimization, etc) about what I did, which works perfectly for me. If you're worried for the extra job, I can do it. In fact, I haven't done yet because I need your agreement. Since (hopefully) the spanish (and maybe others) localization will finally be ported, and because surely in most cases I'll have to keep using the values in global/field-descs.none.tmpl in the mentioned way, I think somebody should take a look and correct whatever may be necessary. If not for english templates, at least for spanish ones.
> This issue will be fixed when statuses and resolutions become customisable > (whenever that is.) So the question is: do we want to fix it before that as > well? I'm to a certain extent willing to wait until bug 94534 and bug 101179 are fixed, but in how far this solved the problem, I don't see. I'd like to provide a solution which works right a way, untaring both bugzilla and bugzilla-xx (xx=some language pack) and starting. Further it is rather unclear how it incorporate these translations into the database. [% bug_status_desc.${status} || status %] seems to be one possible solution. > It's merely a matter of convenience - this bug does not, itself, > prevent full localisation of Bugzilla. Is that right? That's right, but why not having some conviniance (also called consistancy).
OK, I've thought about this more. It does make sense - both for localisers, and people who want to rename particular statuses. So a status_descs and a resolution_descs hash, which are no-op mappings in English, seems like a good way to go. Thanks for being patient while I figured this out :-) Gerv
Well, somebody will have to decide the correct syntax for variables and even function calls (maybe Tobias code in comment 6 is the right thing). Whenever this or any other name, style, etc is approved, I could follow those rules and do the necessary work for english templates.
oscar: I'm not quite sure what you mean by "the correct syntax for variables and even function calls". We need two hashes called status_descs and resolution_descs, probably in a file called global/states.none.html, and (given that we don't have custom fields), the reference can just be [% status_descs.$status %]. Gerv
This bug depends on bug 215148. I think it's explained there. Also, there are some bugs depending on 215148, because they have code that access to these descriptions, and I've had to write the code myself in all cases, and this code can have a bad coding style. That's what I'd like to be reviewed before going too far. The first example in this bug is a sample of bad coding style, because I first used "bug_status_l10n".
215148 is surely the bug to be fixed first? (That's actually the bug I was discussing the fix for in comment 7 and comment 9). Gerv
You're right. Bug 215148 has become a placeholder for general fields or descs to be localized along the whole app, and that must use a hash to be translated because they don't use plain text. This bug has become a particular case of those, the bug statuses and resolutions, because at first I didn't foresee more fields to be included. And bugs/edit.html.tmpl was the first place I saw that, but later realized that there could be other files and issues related to status descs, but I didn't notice this when I filed the bug. Actually, I have called the descriptios for statuses of bugs "bug_status_descs", and have put them in global/field-descs.none.tmpl. The resolutions are called "resolutions_descs". If you think that the name "bug_status_descs" is not good and/or think it's better to be managed in another file, say it so. In fact, you have already suggested "status_descs" instead, and in the file "global/states.none.html" (¿.tmpl?), and "resolution_descs" in the same file. OK, if you confirm these names as definitive, I can this bug could be closed, but there are others still pending in bug 215148, which should be treated in place. Apart, there's the coding style to make use of these is a "null" hash (I mean the particular case of english, where left side of the hash is equal to the right side), so a formula is needed to handle these "null maps" to work. Maybe a good example is the "code" below, which shows the modifications to the last lines in bugs/edit.html.tmpl, in the select BLOCK, to handle all these. [% BLOCK select %] <td> <label for="[% selname %]" accesskey="[% accesskey %]"> <select name="[% selname %]" id="[% selname %]"> [% FOREACH x = bug.choices.${selname} %] <option value="[% x FILTER html %]" [% " selected" IF x == bug.${selname} %]> [% SWITCH selname %] [% CASE "rep_platform" %] [% IF platform_descs.$x == "" %] [% x %] [% ELSE %] [% platform_descs.$x %] [% END %] [% CASE "op_sys" %] [% IF op_sys_descs.$x == "" %] [% x %] [% ELSE %] [% op_sys_descs.$x %] [% END %] [% CASE "bug_severity" %] [% IF severity_descs.$x == "" %] [% x %] [% ELSE %] [% severity_descs.$x %] [% END %] [% CASE %] [% x %] [% END %] </option> [% END %] </select> </label> </td> <td>&nbsp;</td> [% END %]
Hmm. Your example demonstrates a problem - this doesn't scale, does it? Well spotted. What we actually want is a "descs" hash, with keys equal to the field names. So: [% descs.$selname.$x %] would produce the right description. [% descs = { bug_status => { "UNCONFIRMED" => "UNCONFIRMED", "NEW" => "NEW", ... }, resolution => { "FIXED" => "FIXED", ... Does that sound like a better solution? The file would be global/descs.none.tmpl. bug_status is better than status, because it's the field name (currently). Gerv
I don't see how this bug is different from bug 215148. Marking as a dupe. *** This bug has been marked as a duplicate of 215148 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
No longer depends on: 215148
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.