Issue Nomenclature

Vitaly Fedrushkov willy at
Sun Feb 2 11:21:17 UTC 2003

Good $daytime,

> Date: Mon, 27 Jan 2003 18:07:21 +0000
> From: Gervase Markham <gerv at>
> To: developers at
> Subject: [Fwd: Re: Issue Nomenclature]

> See the below newsgroup message. What do people think of the idea of
> a patch (or incremental change) to convert all instances of "bug"
> etc. to [% _bug %], [% _Bug %], [% _bugs %] etc.?

> Would this just be a maintainability headache for the templates, or
> would it allow people to make a much-requested customisation without
> the need for custom templates and hassle?

I wish things were so simple...  IMHO the question is twofold:

Generic Bugzilla installation can be used to handle events of a
different nature:

o  Bugs themselves (i.e. coding errors)
o  Design problems/deficiencies
o  Requests for enhancement
o  Planned tasks
o  Support requests
o  Complex project-tracking nodes (a.k.a meta-bugs at

or what else can happen within issue/problem tracking system.  For
some applications (like support contract management) term 'bug' is
especially unwelcome :-)

These can be made configurable and engine can be written to
auto-linkify all of them.  One can even ignore the fact these terms
are non-interchangeable and then refrain from creating 'Class' field
in bugs table.

Another problem is localization.  Hardcoded components would require
complete rewrite.  With inflexional languages even regexp matches may
die of complexity.  For instance, paradigm of word 'bug' in Russian
consists of twelve forms.  Fully localized template set is unavoidable
here, as well as locale-aware coding.

Simply telling '[% _bug %]' from '[% _bugs %]' is not enough, more
likely we need a set of 'naming operators', like bug_count(number,


No easy hope or lies        | Vitaly "Willy the Pooh" Fedrushkov
Shall bring us to our goal, | Control Systems and Processes Division
But iron sacrifice          | LUKOIL Company, Chelyabinsk Branch
Of Body, Will and Soul.     | willy at  +7 3512 620367
                  R.Kipling | VVF1-RIPE

More information about the developers mailing list