170903 - Remove hard-coded titles and things

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Gervase Markham [:gerv]]

There are a lot of odds and ends to tidy up for full l10n. Here are just a few
of them. All these patches should be simple, and rubber-stamp reviews.

Gerv

Comment 1

[Gervase Markham [:gerv]]

Attachment: Patch A v.1

Here's the first patch. This:
- Eliminates hard-coded titles in enter_bug.cgi and describecomponents.cgi
- Removes a dependency on the English "remember values as bookmarkable
template"
- Changes the internal representation of bug creation to a non-English string,
  and adds a translation table for the field names in query.cgi.

Gerv

Comment 2

[Bradley Baetz (:bbaetz)]

Comment on attachment 100793 [details] [diff] [review]
Patch A v.1


>Index: template/en/default/global/choose-product.html.tmpl
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/choose-product.html.tmpl,v
>retrieving revision 1.6
>diff -u -r1.6 choose-product.html.tmpl
>--- template/en/default/global/choose-product.html.tmpl	6 May 2002 19:17:11 -0000	1.6
>+++ template/en/default/global/choose-product.html.tmpl	26 Sep 2002 07:37:29 -0000
>@@ -24,6 +24,14 @@
>   # are their descriptions.
>   #%]
> 
>+[% IF target == "enter_bug.cgi" %]
>+  [% title = "Enter Bug" %]
>+  [% h2 = "First, you must pick a product on which to enter a bug." %]
>+[% ELSIF target == "describecomponents.cgi" %]
>+  [% title = "Bugzilla Component Descriptions" %]
>+  [% h2 = "Please specify the product whose components you want described." %]
>+[% END %]
>+
> [% DEFAULT title = "Choose a Product" %]
> [% PROCESS global/header.html.tmpl %]
> 

I don't like this. Why not go via another template, which simple does

[% PROCESS "global/choose-product.html.tmpl"
   title = "foo"
   h2 = "bar"
%]

?

Comment 3

[Gervase Markham [:gerv]]

bbaetz: I could, but it seemed like overkill for adjusting two values. If you
want me to change it to do that, I will.

Gerv

Comment 4

[Bradley Baetz (:bbaetz)]

gerv: Then leave it in, I ugess, and we'll change it later when we need to.

Comment 5

[Gervase Markham [:gerv]]

Is than an r=?

Gerv

Comment 6

[Bradley Baetz (:bbaetz)]

Comment on attachment 100793 [details] [diff] [review]
Patch A v.1

You've broken stored [Bug created] queries, haven't you?

Comment 7

[Gervase Markham [:gerv]]

Probably, yes. Bad design in the first place, really. Does it matter? :-)

Actually, we could continue to use [bug creation] as the internal string, now
that we have the mapping array. 

Gerv

Comment 8

[Gervase Markham [:gerv]]

Attachment: Patch A v.2

Try this instead. We can continue to use [Bug creation] as the internal string.
It's nasty, but it means queries don't break. This patch also adds the other
fields to the mapping array, for good measure. Better "URL" than
"bug_file_loc".

Gerv

Comment 9

[Bradley Baetz (:bbaetz)]

Comment on attachment 100928 [details] [diff] [review]
Patch A v.2

r=bbaetz x2

Comment 10

[Gervase Markham [:gerv]]

Attachment: Patch A v.3

This is patch A v.3 - it's exactly the same except that it moves the field name
translations out into a global file. We're replicating this stuff in many CGIs,
and it's time to stop and centralise, for maintainability and translation
purposes.

Gerv

Comment 11

[Bradley Baetz (:bbaetz)]

Comment on attachment 101239 [details] [diff] [review]
Patch A v.3

ok

r=bbaetz x2

Comment 12

[Gervase Markham [:gerv]]

Patch A checked in.

Checking in enter_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v  <--  enter_bug.cgi
new revision: 1.74; previous revision: 1.73
done
Checking in describecomponents.cgi;
/cvsroot/mozilla/webtools/bugzilla/describecomponents.cgi,v  <-- 
describecomponents.cgi
new revision: 1.17; previous revision: 1.16
done
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.207; previous revision: 1.206
done
Checking in template/en/default/global/choose-product.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/choose-product.html.tmpl,v
 <--  choose-product.html.tmpl
new revision: 1.7; previous revision: 1.6
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/field-descs.html.tmpl,v
done
Checking in template/en/default/global/field-descs.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/field-descs.html.tmpl,v
 <--  field-descs.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/search/form.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v
<--  form.html.tmpl
new revision: 1.12; previous revision: 1.11
done

Gerv

Comment 13

[Gervase Markham [:gerv]]

Attachment: Patch B v.1

Some more l10n fixups. After this patch, I think we've covered all the major
points. There are a few little cleanups still to do.

Gerv

Comment 14

[Bradley Baetz (:bbaetz)]

Comment on attachment 101382 [details] [diff] [review]
Patch B v.1


>-     || (!$::FORM{'id'} && $::FORM{'product'} ne $::dontchange))
>+     || (!$::FORM{'id'} && $::FORM{'product'} ne $::FORM{'dontchange'}))

No, this isn't wanted/needed/etc

>+[% dontchange = "--do_not_change--" %]
>+<input type="hidden" name="dontchange" value="[% dontchange %]">
>+

You can easily have the value being --do_not_change--, while the displayed text
is something different.

Comment 15

[Gervase Markham [:gerv]]

bbaetz:

> You can easily have the value being --do_not_change--, while the displayed text
> is something different.

We have a number of fields whose default value is a string which means "do not
change" - e.g. QA Contact. 

<input id="qa_contact" name="qa_contact" value="[% dontchange FILTER html %]">

When you submit the form, you get "...&qa_contact=--do_not_change--&...". This
string needs to be translatable - so you need to know what the original value
was which represents "do not change". Hence the hidden form field, and its use
throughout process_bug.cgi.

If you can tell me how to have an input field which submits a different value to
the one which it contains, then that would work also. But I don't think that's
possible.

Gerv

Comment 16

[Bradley Baetz (:bbaetz)]

Oh, I see. Hmmmmm. I dunno, this just feels icky. Let me think about this a bit.

Comment 17

[Bradley Baetz (:bbaetz)]

well, you could use a checkbox, or something.

But I can't see a better way.

myk, dave: ideas?

Comment 18

[Bradley Baetz (:bbaetz)]

Comment on attachment 101382 [details] [diff] [review]
Patch B v.1

I still claim that this is ugly, but given the lack of another option...

make the dontchange value FILTER html just to be safe, and r=bbaetz x2

Comment 19

[Gervase Markham [:gerv]]

Patch B checked in.

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.154; previous revision: 1.153
done
Checking in userprefs.cgi;
/cvsroot/mozilla/webtools/bugzilla/userprefs.cgi,v  <--  userprefs.cgi
new revision: 1.46; previous revision: 1.45
done
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.211; previous revision: 1.210
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.199; previous revision: 1.198
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/header.html.tmpl,v
done
Checking in template/en/default/bug/process/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/header.html.tmpl,v
 <--  header.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/account/prefs/prefs.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v
 <--  prefs.html.tmpl
new revision: 1.8; previous revision: 1.7
done
Checking in template/en/default/list/edit-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v
 <--  edit-multiple.html.tmpl
new revision: 1.8; previous revision: 1.7
done

Gerv

Comment 20

[Bradley Baetz (:bbaetz)]

Can this bu gbe marked as FIXED yet?

Comment 21

[Gervase Markham [:gerv]]

Yeah, I suppose so. There are a few more bits and pieces, but I'll use new bugs
for them.

Gerv