218746 - (bz-field_descs) Field names defined in field-descs template should be used everywhere

Status: NEW

(Bugzilla :: User Interface, enhancement)

Description

[Andreas Höfler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a; MultiZilla v1.5.0.2Beta) Gecko/20030830
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a; MultiZilla v1.5.0.2Beta) Gecko/20030830

The global terms "Product" and "Component" should be changeable centralized.
Should be easy to do as this is already done with "Bug", "Bugzilla" and so on.

Can they also go into 'variables.none.tmpl', because these two are also used on
many un-templatized pages?

Reproducible: Always

Steps to Reproduce:

Comment 1

[Marc Schumann [:Wurblzap]]

Attachment: Patch to templatize the terms "Product" and "Component"

Patch against tip.

Works the same proven way as the templatization of the term "Bug".

Comment 2

[Joel Peshkin]

Comment on attachment 154448 [details] [diff] [review]
Patch to templatize the terms "Product" and "Component"

[% Terms.This %] [% Terms.breaks %] [% Terms.accesskeys %]  (sorry)

This would break accesskeys.  I am also a bit concerned that things would get
awful unwieldy if we have a huge proliferation of the terms mechanism rather
than requiring template hacking for this sort of thing.

This requires a solution for the accesskeys breakage.  I'd be interested in
some opinions on the other issue.

Comment 3

[Marc Schumann [:Wurblzap]]

Attachment: Patch, allowing for access keys

The access keys are underlined once again. (They never stopped working.)

I think it's worth the [% terms.effort %]. Maybe it's just me. I use project
and subproject instead of product and component, and I'd go some lengths to
seeing that to achieve this I only need to put a site-specific
variables.none.tmpl into template/custom/global.

Comment 4

[Gervase Markham [:gerv]]

We've had this discussion several times in the past, as different people want to
customise the particular word which is different in their organisation. By far
the most common request was "bug", which everyone seems to have a different term
for, but after we did that, then lots of people asked for other things - except
now everyone wants something different.

If we granted everyone's request, the templates would get terribly unwieldy and
hard to edit, as you tried to disentangle code from text-masquerading-as-code,
and tried to make the grammar work for all possible combinations of substitution
(we already have a taste of the problem with [% terms.bug %], [% terms.abug %],
[% terms.Bug %] and [% terms.ABug %]).

Myk is the module owner for UI, but my view agrees with Joel - "sorry, but no" :-|

Gerv

Comment 5

[Christian Reis]

Yeah, this is a slippery slope, isn't it? You might want to rename Version to
Release next. Then comes Target Milestone that we want to mutate into Target
Release. There are *many* hardcoded terms in Bugzilla, and they're all pretty
domain-specific; you'd find a hard time finding a subset that nobody wanted to
rename in a certain situation. I've actually found myself wanting this and then
realizing I'm being silly; you can't hope prepackaged software conforms to every
specificity of your organization without some customization.

Comment 6

[Gervase Markham [:gerv]]

Three's a quorum. :-)

Gerv

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Incidently, what are the others people have asked for?

Comment 8

[Gervase Markham [:gerv]]

Hmm... perhaps some suggestions didn't get as far as a bug. I can only find bug
124274 right now. But I'm sure there have been several, because I remember
deploying these arguments before :-)

Gerv

Comment 9

[timeless]

I asked to replace Search with Query.

Comment 10

[Shane H. W. Travis]

We too use 'Project' instead of 'Product', as well as 'Originator' instead 
of 'Reporter'. 

I'm just trying to upgrade 2.16 to 2.18 locally, and thinking how nice it's 
going to be now that I don't have to search for 'bug' any more in all the 
templates and replace it with 'log item', and was wishing I could do it for 
more things than just that.

Too bad this one has already been shot down. :(

Comment 11

[Dave Miller [:justdave]]

You know what?  We already have Product and Component available as variables
within the template system.  There is no precedent to break by allowing this.

template/en/default/global/field-descs.none.tmpl

We should update field-descs to allow for variations *if needed*, and use the
values defined in field-descs for everything everywhere.

Not only would this solve the problem this bug asked us to deal with, but it
would also fulfill the reason we created field-descs to begin with, albeit in a
little broader sense.

Comment 12

[Dave Miller [:justdave]]

Comment on attachment 154455 [details] [diff] [review]
Patch, allowing for access keys

per my comments when I reopened this, 'terms' isn't the place to do this.

Comment 13

[Dave Miller [:justdave]]

access keys would be the issue, as stated in other comments.  Perhaps the access
key should be defined in the field-descs template as well.

Comment 14

[Gervase Markham [:gerv]]

Defining access keys in field-defs means that they have to be globally unique,
because field-defs cannot know which combination of fields are used on a
particular page. While, ideally, they would be globally unique, you may want to
e.g. use "C" for comment everywhere except for the one page where it clashes
with "Comment", where you would use "m" instead.

Gerv

Comment 15

[Max Kanat-Alexander]

Why is this major? Seems like an enhancement to me.

Comment 16

[Max Kanat-Alexander]

*** Bug 233673 has been marked as a duplicate of this bug. ***

Comment 17

[A. Karl Kornel]

(In reply to comment #3)
> Created an attachment (id=154455) [edit]

What about the fielddefs table in the database?  If that's not updated at some
point, then the changes will take place everywhere except for when text to
display is pulled from the fielddefs table.  For example, the fielddefs table is
used to provide the field names in bugmail.

Comment 18

[A. Karl Kornel]

(In reply to comment #12)
> (From update of attachment 154455 [details] [diff] [review] [edit])
> per my comments when I reopened this, 'terms' isn't the place to do this.

There are certain places in the templates where these terms, like 'product', are
used in sentences, so you will have to handle combinations like "a product",
"products", etc. that could probably not be handled properly by only changing
the fielddefs.  For example, if you change it to "item" then you'd have to have
"an item" instead of "a item".

So there may be more than just changing fielddefs.  Why not start small, with
the terms "product", "component", and "classification", and see where it goes
from there?  See bug 297616.

Comment 19

[Gervase Markham [:gerv]]

When we parameterised the word "bug" (which is by far and away the word that
most people want to change), we also said that we would not do any more words,
because after a while the templates start to get unreadable. If a few people
have specific requirements over and above that, they can do a search-and-replace
for themselves.

I'm all for using the names from fielddefs in places where they are labels -
e.g. the query page, but I think it's a bad idea to go through parameterising
all our freeform text in this way, for the above reasons.

Gerv

Comment 20

[A. Karl Kornel]

(In reply to comment #14)
> Defining access keys in field-defs means that they have to be globally unique,
> because field-defs cannot know which combination of fields are used on a
> particular page. While, ideally, they would be globally unique, you may want
> to e.g. use "C" for comment everywhere except for the one page where it 
> clashes with "Comment", where you would use "m" instead.

It may be preferable to keep it globally unique, simply because it would be
confusing to have to remember that the product field is accesskey 'p' on all
pages bug one, where it's accesskey 'o'.  Accesskeys are only used in a number
of places.

Right now accesskeys are being used in seven different templates: bug/edit.html,
bug/create/create.html, bug/summarize-time.html, global/userselect.html,
reports/create-chart.html, reports/series-common.html, and search/form.html.

* bug/create/create.html, bug/edit.html, and search/form.html all seem to use
the same accesskeys, with the exception of one field in search/form.html
(search/form uses the word "Whiteboard" instead of "Status Whiteboard"), so they
would use the same set of accesskey terms (again, with an additional one for
"Whiteboard").  Checksetup could be modified to build the set of accesskeys
needed in each of the three templates, union the sets, assign values to each
accesskey based on what's in the templates, and make sure that there are no
duplicates.

* bug/summarize-time.html does not seem to include any fields that appear in the
aforementioned templates, so there should be no conflict.

* global/userselect.html does not have any accesskeys of its own; the accesskey
is passed into the template by the template that includes global/userselect. 
The only times that userselect is called with an accesskey passed as a parameter
is in bug/edit.html and bug/create/create.html, so this is not a problem.

* reports/create-chart.html has an accesskey that only appears in the front page
of chart.cgi (where you create a chart, as opposed to creating a data set.

* reports/series-common.html only uses accesskey in a BLOCK that is called from
other locations.

Comment 21

[A. Karl Kornel]

(In reply to comment #19)
> I'm all for using the names from fielddefs in places where they are labels -
> e.g. the query page, but I think it's a bad idea to go through parameterising
> all our freeform text in this way, for the above reasons.

I see no problem with that, so long as it is made clear to the person changing
the field definitions that said changes will not affect freeform text.

Comment 22

[Marc Schumann [:Wurblzap]]

It doesn't seem like I'll be doing this any time soon.

Comment 23

[Max Kanat-Alexander]

*** Bug 306028 has been marked as a duplicate of this bug. ***

Comment 24

[Dave Townsend [:mossop]]

Attachment: Customise field names throughout

This is a patch that I'm using on my own bugzilla. It replaces the labels for
the 4 customisable fields in most places and includes definitions for global
access keys for them.

Comment 25

[Max Kanat-Alexander]

*** Bug 237777 has been marked as a duplicate of this bug. ***

Comment 26

[Bruce Wilson]

I have a vested interest in making some of these modifications a reality.  I'm just getting my feet wet in this (gotta dig up and read the pages on proper ways to submit a patch and such), but I thought I should at least ping the bug and collect some of the collective wisdom, and see if there are any new points on the subject before I start hacking away.

From discussion in #mozwebtools today, mkanat suggested:

>We should rename "field_descs" to "fields," and it 
>should be a hash with "name", "hotkey", and "desc".  
>And we could have "short_name" too, for buglist.cgi.
>We could even create it by some modification of Bugzilla->fields.

There followed a discussion about how this affects internationalization.  timely suggested this would lead to needing foo.properNoun, foo.properNounAtSentenceStart, foo.nameAtSentenceStart, etc. so the words can be used at the start or middle of a sentence.  It sounded like plural forms might also be called for.

Max added:  "For now, though, we're not worried about all these things, since we don't address them now."

The consensus appeared to be that i18n may be a long term goal, but not one that must be solved in order to improve this situation, so long as we don't make i18n harder in the process.

Also from comment #21:

> (In reply to comment #19)
> > I'm all for using the names from fielddefs in places where they are labels -
> > e.g. the query page, but I think it's a bad idea to go through parameterising
> > all our freeform text in this way, for the above reasons.
> 
> I see no problem with that, so long as it is made clear to the person changing
> the field definitions that said changes will not affect freeform text.

Just interpreting the definition of "freeform text" may be an eye-of-the-beholder issue.  To me, it means substitutions should not be made within sentences.  Any comments on this approach?

wurblzap's patch of 2005-10-05 (https://bugzilla.mozilla.org/attachment.cgi?id=198568) seems to follow this path.  I'd hate to revisit road already covered, so I'll try to apply the patch and learn enough about field_descs vs. fields to make a rational change like Max suggested.

Anybody has any tips or snippets, please feel free to email me directly.

Comment 27

[Vlad Dascalu]

Comment on attachment 198568 [details] [diff] [review]
Customise field names throughout

Bitrotten sadly, it no longer applies to the trunk cleanly.

Comment 28

[Bill Barry]

From an i18n view, wouldn't it be better to have every piece of freeform text in some sort of stringtable, so all of them could be changed from one location. I suppose it would need to be in a template, done in a manner not unlike the way messages are done; called from templates by a [% PROCESS %] directive. At this point we could add a <span class="uniquename"> around each bit of text (they would need to be uniquely named in the string table anyways, note I said class because the same string could show up miltiple places). 

Then where freeform text is used, we would change it like this:

<td>
the [% terms.products %]/[% terms.components %] to which [%+ typeLabelLowerPlural %] must (inclusions) or must not (exclusions) belong in order for users to be able to set flags of this type for them
<table ... >

to

<td>
[% strings.product_components_flag_explanations %]
<table>

I think this would actually go a long way to simplify existing templates, improve i18n abilities and improve template readability.

Comment 29

[Max Kanat-Alexander]

(In reply to comment #28)
A better solution is to make Template Toolkit support gettext.

Comment 30

[Frédéric Buclin]

*** Bug 297616 has been marked as a duplicate of this bug. ***

Comment 31

[Gervase Markham [:gerv]]

> From an i18n view, wouldn't it be better to have every piece of freeform text
> in some sort of stringtable, 

Well, no.

This was discussed back when we originally did the templatisation. There are several arguments against (difficulty of parameterisation, extra level of indirection, performance) and the decision was not to do it.

Gerv

Comment 32

[Frédéric Buclin]

*** Bug 350122 has been marked as a duplicate of this bug. ***

Comment 33

[victory <[e-mail]>]

Mozilla-gumi used enunciation translations for some terms
 (this means those are NOT so good,
  especially product, qa contact, targetmilestone),
 so i did make these changes for Japanese templates for 2.22 anyway :-P

Comment 34

[Frédéric Buclin]

We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.

Comment 35

[Marc Schumann [:Wurblzap]]

Bug 297616 has picked up where this bug here was stopped with comment 4.

Comment 36

[Arcel]

To quote justdave (https://bugzilla.mozilla.org/show_bug.cgi?id=237777#c1)

The field-descs template should be the ONLY place we have human-readable names.
 The human readable column both in the fielddefs table and the DefineColumns
table in buglist.cgi both need to go away.

(end quote)

I would also suggest to merge field-descs.none.tmpl and variables.none.tmpl in 1 file.

And if we would use this in the template pages, this would make translation a lot easier !

Comment 37

[Arcel]

And we have also table.html.tmpl abbrev .  Maybe this should be merged too.

Comment 38

[Max Kanat-Alexander]

(In reply to comment #36)
  For custom fields, there have to be default descriptions stored in the database. They can be overridden.

> I would also suggest to merge field-descs.none.tmpl and variables.none.tmpl in
> 1 file.

  That can't be done, for technical reasons. There are places that we have to use variables.none.tmpl but the code can't handle field-descs.

  But yes, we definitely agree that we should be using field-descs--that's why this bug was filed.

Comment 39

[Dave Townsend [:mossop]]

Attachment: Updated to HEAD

This is the previous patch un-bitrotted with a few extra files covered.

There are still a couple of places that this patch doesn't touch, notably the guided bug entry and a few other places where the terms are used in free-form text and so I didn't think it appropriate to update there.

Comment 40

[Dave Townsend [:mossop]]

Comment on attachment 263117 [details] [diff] [review]
Updated to HEAD

This path now doesnt quite apply cleanly to teh stable branch, though it is pretty easy to fix. Also it seems it doesn't pass some tests I'd never heard of before:

<Mossop> And what do those errors mean?
<LpSolit> XSS
<LpSolit> in this case, the risk is pretty low as you would have to write buggy strings in templates themselves :)
<LpSolit> you could add these variables to filterexceptions.pl
<LpSolit> else you would have to add FILTER html everywhere

I really have neither the time or energy to fix it up and keep unbitrotting the thing.

Comment 41

[Max Kanat-Alexander]

Remember that Custom Field descriptions come from the database, and thus from the user, and those would have to be escaped.

Comment 42

[Vitaly Fedrushkov]

See also bug 407752

Comment 44

[posita]

To address the slippery slope issue, a two-level hierarchy is a very powerful generic concept (see bug #350122 and bug #760841 for examples of alternatives to "Products" having "Components"). Other terms beyond those two would not be so critical if bug #287335 and bug #760832 had solutions (i.e., let administrators either accept the defaults or design their own terms/fields and be done with it). That seems more tractable than opening up the world to all possible term reconfigurations.

Of course, I haven't necessarily thought through all reasonable cases, so take the above with a grain of salt.