215058 - Need hash map for translating bug statuses

Status: RESOLVED DUPLICATE of bug 215148

(Bugzilla :: User Interface, enhancement)

Description

[Oscar Manuel Gómez Senovilla]

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:

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

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 http://bugzilla-cvs.omgs.homelinux.org/query.cgi
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.

Comment 1

[Tobias Burnus]

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

[Oscar Manuel Gómez Senovilla]

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

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.

Comment 3

[Oscar Manuel Gómez Senovilla]

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="[% sel.name %]" accesskey="[% sel.accesskey %]">
      <select name="[% sel.name %]" id="[% sel.name %]"
              multiple="multiple" size="[% sel.size %]">
      [% FOREACH name = ${sel.name} %]
        <option value="[% name FILTER html %]"
          [% " selected" IF lsearch(default.${sel.name}, name) != -1 %]>
          [% SWITCH sel.name %]
          [% 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>
      </select>
    </label>
  </td>
[% 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

[Max Kanat-Alexander]

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.

-M

Comment 5

[Oscar Manuel Gómez Senovilla]

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

[Oscar Manuel Gómez Senovilla]

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.

Comment 7

[Frédéric Buclin]

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 ***