User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like Gecko) Safari/412 Build Identifier: My installation of Bugzilla isn't going to be geared towards tracking bugs in products, so the terms "product" and "category" don't really work, which means I've had to create custom templates (or modify the default template) for every file that publicly mentions the terms "product" or "category". It occurs to me that it might be a good idea of these words were converted into template "terms", like the word "bug". Is such a thing advisable? Reproducible: Always Steps to Reproduce: Again, this is coming from my copy of Bugzilla 2.18.1, but I'm pretty sure it applies to tip. I'm also perfectly happy to take care of this. If approved, are there any other words I should templatize?

+1; QA Contact, quips, etc also..

Obviously I need to add more information on this. First of all, I was thinking of the following fields whose names should be converted into template terms: * Product * Category * URL * Status Whiteboard * Hardware * OS The url, hardware, and os fields are not involved in any special processing that I know of, although hardware and OS list changes are run through checksetup.pl that's just for changing the list of possible values. This is in comparison to a field like 'keywords', which has a special meaning within Bugzilla and can only contain specific values. As for the status whiteboard field, although it is enabled/disabled by a Bugzilla parameter, it's not used as a special field inside Bugzilla (again, as far as I know). The product & category fields can also have their labels changed to something user-defined. For example, I'm using 'category' and 'area'. Of course, I'm open to discussion regarding additions to, and deletions from, the list above. Also, before I continue it's worth noting that this discussion may already be taking place in a different bug, though I couldn't find any. The primary bug tracking the ability to add custom free-form text fields (I don't have the # right now) doesn't seem to mention anything about modifying or deleting the standard fields that Bugzilla ships with (which includes the fields on the list above). If there is a bug that covers making customizations or modifications to, or the ability to delete, one of the fields that comes on a fresh installation of Bugzilla, then this bug is probably a duplicate of that. Otherwise, this bug may be relatively unique. Now, back to my reasons why. I got some comments from LpSolit a number of hours ago (by thw way, thanks very much for your comments LpSolit!). You can read the discussion on IRC by going to <http://tinyurl.com/cx3e7>. The relevant times are 00:45 to 01:05. I was originally thinking, if there are different words that could be used for "Bug", why can't there be different words used instead of "product" and "component"? You might not even be using Bugzilla as a means to track bugs in software. You could use it as a general issue tracker, replacing "product" and "component" with appropriate terms to suit your application. Yes, some features of Bugzilla would not be useful (such as CVS integration) and yes, documentation would have to be changed (examples reworked, certain resolutions and statuses slightly redefined, etc.), but it could work. Assuming it does work, and that someone does decide to do this, then there are a large number of templates that must be changed. In the end I had to modify 42 template files that had the terms "product" and/or "component". Each of those 42 template files means more work when a new release comes out. Of course, there will always be templates that will have to be reviewed and modified during an upgrade to a new release, but at least half of those 42 templates (probably more) were modified ONLY to change the "product" and "component" words. If those terms were already templatized, the would be much less template code to review during an upgrade. Anyway, that's my reasoning behind this bug. Of course, I'm open to comments & questions (and votes 8-). In comment 3 I'll cover the movement to complete templatization, and I'll describe one problem I found.

In In comment 2 I explained in more detail my motivation behind this. Of course, there is a problem. Well, at least one (I've only come up with one problem so far). The terms that would be templatized appear in many different places, including non-template CGI code. This includes .cgi files that have not been templatized (such as reports.cgi in 2.18.1), and it includes little text and HTML snippets that are generated by several scripts. Those areas are beyond the reach of the Template Toolkit. Although the non-templatized .cgi scripts can be templatized (I think there's a bug for that already), what about the little snippets of HTML that appear in many .cgi scripts? Those little snippets would be completely out of reach. My suggested solution to this problem would be to convert the terms hash from being defined in a template to being defined in a .pl file. One default .pl file would provide the Bugzilla-approved definitions for the various terms, and that default .pl file would parse a second .pl file that contains customized templates, along with any new additions (the second file could be processed the same way the params file is processed). The .pl files would be processes at the start of each script (like params), and the resulting %terms hash would be passed to the Template Toolkit whenever templates are processed. I believe this would mean that all references to [% terms.bug %] (and the like) in templates now would not be affected. Another solution would be to move every piece of HTML and text seen by the user into template files, no matter how small the piece may be. Considering the number of additional templates this could create, I'd opt for the former option instead of the latter. Anyway, does what I described above sound like a valid problem? Any other solutions?

> First of all, I was thinking of the following fields whose names should be > converted into template terms: > > * Product > * Category > * URL > * Status Whiteboard > * Hardware > * OS A case could be made for product, component, and classification, but URL, hardware, and OS all have specific, well-defined meanings, and status whiteboard is an optional field. If you need a freetext field like status whiteboard but with a different name, the custom freetext fields feature being implemented in bug 287325 is your solution (in fact, it's the solution for the whiteboard field too, which will be made custom in bug 287323). The fields with well-defined meanings, on the other hand, should retain their meaning-specific names, but they should be made optional, so you can turn them off if they don't work well in your environment. Also custom fields with similar functionality should be made available if you need something similar to those fields, which is bug 287326 for single-select fields like OS and hardware and bug 287328 plus some additional functionality for a field like URL. > Another solution would be to move every piece of HTML and text seen by the > user into template files, no matter how small the piece may be. That's exactly what we should be doing. > Considering the number of additional templates this could create, > I'd opt for the former option instead of the latter. How many occurrences are there? I know the words appear a lot in code, but is there really that much user-targeted text left in the Perl scripts (not including the scripts whose output has yet to be templatized, of course)?

(In reply to comment #4) > A case could be made for product, component, and classification, but URL, > hardware, and OS all have specific, well-defined meanings, and status whiteboard > is an optional field. > > <<<snip>>> > > The fields with well-defined meanings, on the other hand, should retain their > meaning-specific names, but they should be made optional, so you can turn them > off if they don't work well in your environment. Also custom fields with > similar functionality should be made available if you need something similar to > those fields, which is bug 287326 for single-select fields like OS and hardware > and bug 287328 plus some additional functionality for a field like URL. Agreed. I see no reason with shortening the list down to Product, Component, and Classification (a new field?). > > Another solution would be to move every piece of HTML and text seen by the > > user into template files, no matter how small the piece may be. > > That's exactly what we should be doing. Agreed. I believe there are already bugs in the system for handling most of this. > > Considering the number of additional templates this could create, > > I'd opt for the former option instead of the latter. > > How many occurrences are there? I know the words appear a lot in code, but is > there really that much user-targeted text left in the Perl scripts (not > including the scripts whose output has yet to be templatized, of course)? > Just to make sure I'm current, I looked at the tip as of 05:38 AM 17 June 2005 GMT, ignoring everything in contrib/ and docs/, as well as all .xml, .rdf, and .ics files, as well as importxml.pl and editparams.cgi (which had many, many mentions). There were a lot fewer in tip than I expected! * defparams.pl includes the terms in various parameter definitions * quicksearch.html contains references to all terms, as does quicksearchhack.html * sanitycheck.cgi refers to all terms, and when I say this I'm not talking about table/column names, I'm talking about error messages and status messages (as in "Checking for bugs with groups violating their product's group controls" on line 757). In addition to those references, there is the fielddefs table in the database. That has the terms "Product", "Component", and "Classification" pre-defined, with no admin-facing way (that I could find) for editing it, except maybe to modify checksetup.pl before running it for the first time.

See also bug 218746.

*** This bug has been marked as a duplicate of 218746 ***

Actually, believe it or not, this bug is not completely a duplicate of bug 218746. The reason is that field_descs has one entry for each field, and the name is capitalized. However, the words "Product" and "Component" are used *everywhere* in Bugzilla, and not just as field names. I've actually implemented a fix for this bug in 2.22, and I'm waiting on copyright release to bring it forward. But this is a case where this really belongs in the "terms" hash, and not in field_descs.

Will this patch be prepared for localization? Meaning, will it take non-English languages transforming words for different cases into account?

The patch has "terms.Product" and "terms.product". It doesn't go quite as far as having aProduct and aproduct. I'm not sure that's quite as necessary, but we could do it, maybe.

I've converted some terms to use TT vars include these for 2.22. I've finished to sync templates translation for Japanese, now I could grep terms.(product|component) to get the list :-) there may be some places the translation don't have, though :-P

Comment on attachment 250935 [details] [diff] [review] patch for tip >+ "product" => "product", >+ "Product" => "Product", >+ "compoent" => "component", >+ "Compoent" => "Component" Two things come to mind: 1) Plural of some words 'foo' is not 'foos'. Obvious examples exist at least in french and german, and I suppose in english too. 2) I'm not a fan of all these terms.foo variables within templates.

Just to let you know, internally at Everything Solved we have basically-complete patches which do this for 3.0, and which we have permission to release. They address LpSolit's concern #1, but not #2 which is unavoidable.

Comment on attachment 250935 [details] [diff] [review] patch for tip This doesn't apply cleanly anymore so let's take better patch from mkanat instead.

See also bug 407752

I attached a patch for adding the term product to variables.none.tmpl. I ran the tests and confirmed that there were no regressions. I'm adding the patch here because the bug that I opened (1152518) was marked as duplicate of this bug.

Updating diff to fix one instance of the term product that I missed in user-error.html.tmpl

sorry to do this to you omar, but i think this bug should not be fixed. it adds a lot more complexity to the product, especially during development, and imho doesn't provide enough of a gain to offset that complexity. it doesn't make sense to just do product without component, so the amount of changes you see in omar's patch is only part of the impact. justdave, mcote: what are your thoughts on this?

For completeness, and for the benefit of other bugzilla users, I updated the patch to also include component. It wasn't that difficult since component is mentioned fewer times than product. I don't think this add too much complexity. We are already doing the same thing for the terms 'bug' and 'comment'.

Maybe this should block bug 218746?

(In reply to Omar Ali from comment #20) > I don't think this add too much complexity. We are already doing the same > thing for the terms 'bug' and 'comment'. It definitely adds complexity, especially when you think about all these /[a|A|][p|P]roduct/ combinations. We don't do it for comment(s); the reason they appear in variables.none.tmpl is for quoteUrls() only, but they are not used in templates. And for "bug", this is a whole separate story. It's very common to read "issue" or "ticket" instead of "bug". I agree with glob that we shouldn't do this. Bugzilla has classifications, products and components. If you want to rename them to category, sub-category, and sub-sub-category, well, maybe this could make sense, but does it worth the complexity involved? And then one will probably want to rename "severity" and then "priority", etc... [% terms.Things %] [%+ terms.would %] [%+ terms.become %] [%+ terms.much %] [%+ terms.less %] [%+ terms.readable %].

My 2c is that, for these two terms, it is indeed worth the complexity. The terms "product" and "component" are so specific that they match a very narrow spectrum of Bugzilla use cases only. If we had a more generic term (think "classification" -- we're hearing few complaints about this), it wouldn't be much of a problem, but "product" and "component" don't work very well as generic terms.

I don't think I'm the appropriate person to make a call here, but I do see Marc and Omar's point. "Product" and "Component" are a lot more arbitrary than many other fields, as Myk pointed out in comment 4, so I see an argument for making Product and Component configurable but stopping there. However, I can't really comment on the added complexity. If glob thinks it significantly increases complexity and development/maintenance burden, I would go with his recommendation.

marking as wontfix. (In reply to Omar Ali from comment #20) > Created attachment 8591287 [details] [diff] [review] > v2, patch for product and component > I don't think this add too much complexity. even with this patch the API, DTD, and documentation will still refer to 'products' and 'components'.

This is circular reasoning. You're stating (a part of) the problem as a reason not to fix it.

> even with this patch the API, DTD, and documentation will still refer to > 'products' and 'components'. Isn't this also true for the other terms in variables.none.tmpl? Does the API, DTD, and documentation currently use the custom terms for 'Bug', 'Comment' and 'Bugzilla'?

glob: Could you please reply to the last two comments (that I also sympathize with)?

glob: Could you please reply to the last two comments (that I also sympathize with)?

the crux of this is this adds a real cost to ongoing maintenance that we cannot afford. yes, there are inconsistencies with the current 'terms' implementation, but that's a side point.