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:

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

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.

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.

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

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.

Three's a quorum. :-) Gerv

Incidently, what are the others people have asked for?

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

I asked to replace Search with Query.

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. :(

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

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.

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

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

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

(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.

(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.

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

(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.

(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.

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

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

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.

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

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 on attachment 198568 [details] [diff] [review] Customise field names throughout Bitrotten sadly, it no longer applies to the trunk cleanly.

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.

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

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

> 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

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

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

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

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

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 !

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

(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.

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

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

See also bug 407752

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.