Need hash map for translating bug statuses




User Interface
15 years ago
5 years ago


(Reporter: Oscar Manuel Gómez Senovilla, Assigned: myk)






15 years ago
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 the url, and after having translated all the stuff in the template directory,
I still get (at least) the bug statuses in english, I don't know how to manage
maps for this. The code that I think manages, in the file search/form.html.tmpl,
at about lin 500, is this:

          <th align="left"><a href="queryhelp.cgi#status">Est<u>a</u>do</a>:</th>
        <tr valign="top">
          [% PROCESS select sel = { name => 'bug_status',
                                    size => 7,
                                    accesskey => 'a' } %]

If I comment the lines of the PROCESS, the bug statuses aren't displayed, so
they do the work, but I don't know how to filter them for the strings
UNCONFIRMED, NEW, etc to be localized.

Reproducible: Always

Steps to Reproduce:
1. Visit
2. Look at the "Estado" (english "Status") title
3. Verify that the statuses are still in english

I'll make bug 214907 (intended for general ui issues) depend on this.


15 years ago
Blocks: 214907

Comment 1

15 years ago
Bugs #94534  - Customised resolutions.
and  #101179 - Customised statuses.
(both planed for 2.18) make this a bit harder. But one can do so very simply
without the need to change the PERL files:

1. Add them to "global/field-descs.none.tmpl"
2. Change [% name FILTER html %]
   into   [% field_desc.${name} || name FILTER html %]

Comment 2

15 years ago
How can I apply the "standard" mapping to the example. As I see, the syntax is

The bugs you mention, as I've been able to understand, aren't what I'm asking
for, because I don't wish to create or change existing statuses, resolutions,
etc, but just "change/localize" the description in the UI.


15 years ago
Version: unspecified → 2.17.4

Comment 3

15 years ago
OK, I finally got it. At the end of search/form.html.tmpl, I've changed the
BLOCK select:

[% BLOCK select %]
  <td align="left">
    <label for="[% %]" accesskey="[% sel.accesskey %]">
      <select name="[% %]" id="[% %]"
              multiple="multiple" size="[% sel.size %]">
      [% FOREACH name = ${} %]
        <option value="[% name FILTER html %]"
          [% " selected" IF lsearch(default.${}, name) != -1 %]>
          [% SWITCH %]
          [% CASE "bug_status" %]
              [% temp = bug_status_descs.$name %]
          [% CASE "resolution" %]
              [% temp = resolution_descs.$name %]
          [% CASE "bug_severity" %]
              [% temp = severity_descs.$name %]
          [% CASE "rep_platform" %]
              [% temp = platform_descs.$name %]
          [% CASE "op_sys" %]
              [% temp = op_sys_descs.$name %]
          [% CASE DEFAULT %]
              [% temp = field_descs.$name %]
          [% END %]
          [% IF temp == "" %]
            [% name FILTER html %]
          [% ELSE %]
            [% temp FILTER html %]
          [% END %]
        [% END %]</option>
[% END %]

And I have documented in bug 215148 (which is specific for the
field-descs.none.tmpl file) the fields for each category, allowing more
customizations, and probably avoiding a collision when translating gender and/or
number (i.e. plurals) dependant words non varying in english.

This works for me, but I think the bug can't be closed until this is implemented
in your bugzilla.

Comment 4

14 years ago
This is an enhancement, not a bug, I'd say, though possibly a significant one.

I think that this is more something to consider while implementing the
resolution for bug 94534 and bug 101179. In that respect, I'd probably either
DUP this bug to one of those, WONTFIX this bug, or wait for those other two bugs
to be resolved before looking at this.

Severity: normal → enhancement
Depends on: 94534, 101179
OS: Linux → All
Hardware: PC → All

Comment 5

14 years ago
I don't think this a dupe, because the others are about "changing" and/or
"adding" new statuses to the original english list, and this for "keeping" the
original english and say, give an "alternate" value for every status. However,
since I wasn't aware of the possibility of adding custom statuses, etc, I didn't
mention explicitly, but the initial bug's proposal was always that any status,
resolution, etc. that could be defined in english, should be localizable.

Comment 6

14 years ago
I think what's really blocking this bug is bug 215148 and related. I request to
remove that this bug depends on bug 94534 and bug 101179, because are things
that don't exist yet. If this bug is fixed before any of those, that would mean
that those bugs should provide a way for localization, not being necessary this
bug for that.
Depends on: 215148


14 years ago
No longer depends on: 94534, 101179, 215148

Comment 7

13 years ago
All your bugs are about bug status and resolution translations. For me, this is
a *single* bug. There is no need to open at least 3 bugs for the same purpose.
We won't implement partial patches, each one hacking a different file. We need a
*single* patch which fix the whole problem.

*** This bug has been marked as a duplicate of 215148 ***
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.