13540 - Bugzilla should be more generic, adaptable, and customizable

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P2)

Description

[Daniel Roberts]

Hello Terry,

I have been toying with Bugzilla 2.6 recently.  I have come to the conclusion
that Bugzilla serves well not JUST as a bug reporting system, bug as a general
solution for the more general idea of "problem" or "incident" reporting.

In fact, I've found this out as I continue trying to hack Bugzilla for use as a
contact management system for an association management provider firm that I am
currently working for.

This being the case, I have been changing the term "bug" in many cases to
"report."  I'd like to suggest that Bugzilla use this term in appropriate cases
in the stock code distribution as well.

Comment 1

[Daniel Roberts]

CC'ing someone who might be interested.

Comment 2

[Matthew Tuck [:CodeMachine]]

I'm actually designing a problem reporting system at the moment, with different
sort of goals to Bugzilla, and I generally use the terminology "problem report".

Comment 3

[Daniel Roberts]

I use the term "report," because in my case, they are "contact reports" that I
am dealing with.  Not even necessarily "problems" at all.  That's why I'm saying
I think Bugzilla is great for tracking ANY kind of thing that needs attention,
be it a problem, or just something that plain needs attention.  I'm saying I
think Bugzilla can be adapted to suit a much more general set of conditions with
these kinds of needs.  Bugzilla is VERY adaptable, and very flexible.  I'm
saying I think the terminology should reflect this flexibility a little.

Comment 4

[Matthew Tuck [:CodeMachine]]

I've been thinking that it would be good if Bugzilla was "modular".  For
example, you could have a dependencies module, a milestones module, etc.  They
would allow you to plug in your own bits, and remove what you don't want.  This
could be related to that.

Comment 5

[Daniel Roberts]

I think your ideas there are *VERY* much related to my idea.  In fact, I think
you've hit upon the larger issue I'm heading towards (without even realizing
it).  So, I'm changing the bug summary to reflect this.

I think the idea for modularity, (greater) customizability, extensibility, etc.,
is a general idea which is well worth looking into.  IMHO, this would make
Bugzilla much easier to customize/adapt to people's own projects/needs.

Actually, looking at the code here, I think the main thing that needs to be done
to achieve this is to do some cleanup/reorganization of the code.  I think
Bugzilla is conceptually a VERY sound (and complete) design, but the code is a
little bit ugly, and quite Mozilla-specific.  The latter does not surprise me,
since Bugzilla (I assume) was originally designed to address a very specific
need that Mozilla had.

However, I do think that since Bugzilla is also becoming a noteworthy product in
itself now, this idea is worth considering.

Terry, is the Bugzilla code in CVS exactly what Mozilla.org uses for its
particular installation at this given moment?  I guess the reason I'm asking is
that I'd like to know if it is okay for me to check stuff in (pending review by
you, if you desire) to this tree, or if I would potentially be messing up the
code that Mozilla.org is using in its installation.

Comment 6

[Matthew Tuck [:CodeMachine]]

Yep, I've been meaning to submit something about this.  Here's what I think a
module should have.

(1) A set of fields that it maps to on the underlying database.  There needs to
be some way of adding/removing modules and hence fields and knowing how this
would map to the database underneath (SQL actions?).
(2) A set of module that this is dependant on and can hence be relied on to be
present.
(3) Both a simple legal field values specifications, and possibly inter-field
constraints as well.
(4) Triggers on change, eg for dependencies.

Comment 7

[Terry Weissman]

It's hard to disagree with much of anything written here, since it's all wrapped
up in motherhood and apple pie.  But it's real work to do all this and to do it
well, and I'm not likely to have the cycles.  I will happily look at any
patches, and will take things that look good and don't irrevokably break any
existing installations.

The http://bugzilla.mozilla.org/ installation of bugzilla *does* run off of the
tip.  This is a little too aggressive, I agree, but I will always want it to be
running very near the tip.  So, no, I do not want things checked into the tree
directly, until I have reviewed a patch and given it an OK.  If you prefer, we
can also set up a branch on the tree for stuff.  (Just don't go living on the
branch too long; when a branch and the tip diverge for very long, it becomes
very very hard to land the branch.  This is why the Redhat changes never made it
into Bugzilla.)

If you really plan on working on making bugzilla more "generic, adaptable, and
customizable", feel free to reassign this bug to yourself.

Comment 8

[Daniel Roberts]

Re-assigning to myself then.  I probably won't have too much time to work on it
at the moment, so don't expect anything anytime soon, but I will try to work on
it as I find the time.

Comment 9

[Daniel Roberts]

Accepting new assignment.

Comment 10

[Daniel Roberts]

Would love it if anyone wants to help achieve this goal.

Comment 11

[Matthew Tuck [:CodeMachine]]

Well, I can talk, but am unlikely to be able to code anything.

One thing you'll have to be wary of is what to do with the query and bug
screens.

- Where do you place the fields in comparison to the others?
- What widgets do they use?
- Is there some way to group related fields that might be in totally different
modules?

Comment 12

[Matthew Tuck [:CodeMachine]]

After seeing the Redhat Bugzilla site ( http://developer.redhat.com/bugzilla/ ),
I'm not sure how extendible Bugzilla is.  Have they just hacked everything out,
or is this modularity partly there, and if so, what?

This might be obvious, but the way I would suggest to do this is implement the
module system and then attempt to add new modules.  Then you could try to move
the base functionality into modules.

Comment 13

[Terry Weissman]

Redhat hacked the hell out of Bugzilla a long time ago, promised to land their
changes, and never did.  The longer they put off landing, the harder it is to
land it, and so the less likely it is to happen.  This is a sore point with me.

And, yeah, of course things can always be designed to make such things easier.
As I said above, this is all real work.

Comment 14

[Daniel Roberts]

I just submitted bug #5953 to Red Hat's Bugzilla.  You can see it at
http://developer.redhat.com/bugzilla/show_bug.cgi?id=5953

Comment 15

[Matthew Thomas, usability weenie]

Repeat for me what the other Matty T said ... I can brainstorm good ideas
whenever you need them, but learning C++ will have to wait a while.

Comment 16

[Daniel Roberts]

Another idea has occured to me...  Terry, tell me how feasable you think this

is, but how about creating a sort of INI type thingy for Bugzilla, or perhaps

several INI files, where one could store certain settings, like the name of the

project (Mozilla in Mozilla's case, or "Red Hat" in Red Hat's case, etc.), the

bug resolutions (AbiSource uses different ones from Mozilla, for example), and

(dare I say this--this one will probably explode into another holy war) query

screen settings?  This would definitely help to make Bugzilla more adaptable,

since people then wouldn't have to tinker with the code itself so much to change

these things.  What do you think?

Comment 17

[Daniel Roberts]

Since the development roadmap basically is echoing what I wrote in this bug so
long ago, I am re-assigning it to someone who might be able to help.  Perhaps we
could use this as a meta-bug, to track more specific things that can be done to
achieve the goal stated in this one?

Comment 18

[Dave Miller [:justdave]]

An idea for implementation...

There could be a "modules" directory.  Inside this directory would either be a 
directory for each module with a set of files in it.  The reason it needs to be 
more than one file for each module is there needs to be at least one routine that 
doesn't have any dependencies on CGI.pl or globals.pl that can be called by 
checksetup.pl to assure that any database or setup requirements of that module 
are in place.

Things like whiteboard status, URLs, and keywords would be really good candidates 
to get modules, since they're already in places within the query screen which 
make them easy to add/remove at will (and a couple of those already can be via 
params).

The next question is how to deal with module management.  Since checksetup needs 
to be able to know which ones you're using, one of three things would need to be 
done...   Either 1) a list of modules to be used should be placed in localconfig, 
2) two directories should exist, one for modules in use, and one for modules not 
in use, or 3) a flag file of some sort should be placed in the module directory 
to tell if it's in use or not.

Personally, of those 3, I think #3 would most lend itself to being able to manage 
which modules are in use from the web interface.

Things each module would need to have:

1) as mentioned above, a setup file that can be called by checksetup to ensure 
any database or other setup dependencies are met.

2) a way to define fields for the enter_bug, query, and show_bug screens.  
perhaps with some sort of "field type" definition that will allow the above cgi's 
to make intelligent decisions about where to place the fields on the generated 
pages.  

3) routines that can be called if any of the defined fields exist in a submitted 
form that will add the necessary SQL to the database query, or update the 
necessary information in the database, as required.

4) a way to define columns that can be shown on the buglist.cgi page.

Wow, this sounds like a huge project now.  But definitely something that could be 
done, if someone had a few days to sit down and spend on it.

I would think a good definition of how the modules will interact with bugzilla 
would be important to have before any programming work starts on it, to ensure 
future expansion capabilities of the modules after they've been created.

Comment 19

[Tara Hernandez]

Dave--this is exactly the sort of thing Chris and I have been kicking around, 
and it ties into the whole change in concept on how parameters are handled that 
we've also been kicking around.  At some point in the next week or so we're 
probably going to sit down with some folks who know a lot more about database 
structures than we do and stare really hard at the current schema, see where we 
need to go, then start working from that point on the rest of the project would 
change around it.

Comment 20

[Matthew Tuck [:CodeMachine]]

The more I've thought about this the more I think that you're going to have to
have a lot of hooks.  And there's probably going to be a lot of cruft and
various other things in Bugzilla not designed with this in mind.

But whoever does this will have the adoration of people worldwide.  Bring on the
draft spec!

Comment 21

[Matthew Tuck [:CodeMachine]]

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

Comment 22

[Hixie (not reading bugmail)]

This should be an easy fix, taking...

Comment 23

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 24

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 25

[Hixie (not reading bugmail)]

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)

Comment 26

[Dave Miller [:justdave]]

The Bugzilla 3 component is going away.  We're going to depend on the Milestones 
for this.  At the time this component was created, we didn't have milestones for 
Bugzilla.

Comment 27

[stephen roberts]

We recently adopted Bugzilla (woohoo for the good guys!) for tracking things in
our shop. One of our big selling points was that we had the source code, so
could adapt it.

In our case, Management didn't like the term "bug", so I went through and
changed all visible cases of "bug" with "issue" (including in autolinkification).

The ability to change some of the visual aspects of the program would be good as
a global thing (like "$callBugs ='bug';" and "$noBugsFoundmsg ='Zaroo Boogs
found';" in globals.pl)...


I'll gladly help with this idea as soon as the trunk gets back to letting
Windows work, till then I'm stuck back at 2.14.4 (I couldnt convince them to let
me run it on a linux box :-(

Comment 28

[Jon Wilmoth]

I have suffered through the same changes of renaming "bug" to "issue" (as well 
as rebranding Bugzilla to another name) in my installation and would be 
willing to submit a patch for 2.17.3 in an effort to ease the pain of 
upgrading.  My solution was to introduce a new template 
(../global/variable.html.tmpl) that defined "bug.label" and "app.name" and 
simply added a [% INCLUDE global/variables.html.tmpl %] statement to all pages 
that had a reference to.  This works for everything that is templatized 
however there are still a few cgi scripts (i.e. reports.cgi) that create html 
and have "bug" in there that require a hard coded replacement.  My thought was 
if this were added to the Parameters page it could be referenced in both cgi 
and templates.  If this is the preferred location please let me know.  I'd 
like to have this incorporated in the 2.18 release.

Comment 29

[Dave Miller [:justdave]]

I'm all for it.  Eventually everything output to a user will be a template so
that's definitely the right place to put it for the long term.  Big thing to
keep in mind is there's a variety of ways the word might be used (initial caps
or not, plural or not, etc).

Comment 30

[Jon Wilmoth]

Attachment: 2.17.3 based patch using termanology variables across all templates

I went through all the 2.17.3 templates and replaced hard coded references to
bug (all cases), the "zero issues found" and Bugzilla replacing them with
variables defined in a new template global/variables.none.tmpl.  Any chance
this can make the 2.17.5 release?

Comment 31

[Jon Wilmoth]

Attachment: 2.17.3 based patch using termanology variables across all templates

Previous zip file contained customized values for termanology for my testing
purposes.  This zip file contains existing hard-coded values for "bugLabel",
"appName", "permissionBit", "zeroSearchResults" and the singular/plural
modifiers.

Comment 32

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

I don't think this issue really blocks 48822 (a XUL interface to Bugzilla),
which has just been resolved fixed without this bug being fixed, so removing
that bug from this bug's blocker list.

Comment 33

[Jon Wilmoth]

Comment on attachment 121738 [details]
2.17.3 based patch using termanology variables across all templates

Requesting review of the submitted patch as I'd like to have this incorporated
in the next release.

Comment 34

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

Comment on attachment 121738 [details]
2.17.3 based patch using termanology variables across all templates

You should ask someone specific to review the patch or else it'll never happen.
 Making that person be me for the moment, but I'm overworked, so if you don't
get a response quickly enough feel free to move the request to someone else.

Comment 35

[Joel Peshkin]

Jon,

   The customary way to attach a patch is to perform a unified diff and attach
the result.  This makes it very easy for a reviewer to see exactly what you
changed and they can also apply it to a version that is not exactly what you
started with.

   Please attach your patch as a unified diff.  If you need help with this, the
IRC channel is a good place for tricks.

Comment 36

[Jon Wilmoth]

Attachment: 2.17.4 based patch to replace hardcoded termanology with template variables

The attached path (in unified diff format) replaces hard-coded BZ termanology
(i.e. all instances of the word bug, in all cases and plural/singular) with
variables defined in template/en/default/global/variables.none.tmpl.  I
couldn't get the new template included in the diff, so I'll attach that
separately.

Comment 37

[Jon Wilmoth]

Attachment: Part 2 of 2 - 2.17.4 based patch to replace hardcoded termanology with template variables

This new template is required for attachment #125851 [details] [diff] [review].

Comment 38

[Jon Wilmoth]

Comment on attachment 125851 [details] [diff] [review]
2.17.4 based patch to replace hardcoded termanology with template variables

Requesting review of patch for inclusion in next maintenance release.

Comment 39

[Gervase Markham [:gerv]]

My thoughts:

- We are eliminating use of "|" in favour of "FILTER", because it's much easier
  for our auto-security-hole-detection scripts to spot. 
- "global.terms" seems overkill - "terms" would do fine.
- +[% INCLUDE global/variables.none.tmpl %] could this be done in 
  header.html.tmpl? If it's needed beforehand in a couple of templates, we could
  include it twice.
- global.terms.pluralBugLabelModifier is very long-winded :-) I don't know if TT
  supports case-sensitive hash keys, but if I does, I suggest:

  terms.bug
  terms.bugs
  terms.Bug
  terms.Bugs

  This avoids upper/lowercase and plural/singular issues in a simple, easy to 
  understand, short way. 

- Also, this brings out a more general point. We should be using e.g.
  terms.Bugzilla instead of terms.appName - this makes the page read much more
  sanely. 
- Please keep lines to < 80 chars where possible.

Gerv

Comment 40

[Jon Wilmoth]

Attachment: Part 2 of 2 - 2.17.4 based patch to replace hardcoded termanology with template variables

Replaced variables with case sensitive versions.  Also renamed
global.terms.appName with global.terms.Bugzilla.

Comment 41

[Jon Wilmoth]

Attachment: 2.17.4 based patch to replace hardcoded termanology with template variables (Version 2)

This revision replaces the "FILTER" shorthand "|" with the longer version to
support auto-security-hole-detection scripts.  So many of the 112 templates use
"Bug" in the "title" variable passed to the header.html.tmpl that I decided for
consistency to be explicite in the reference.  "global" is a namespace
declaration that allows variables to be used from included files and as such
has to remain.	TT does support case-sensitive hash keys, so I've replaced the
per template concatination with appropriate case-sensitive variables in
variables.none.tmpl.  I've also replaced global.terms.appName with
global.terms.Bugzilla.

Comment 42

[Gervase Markham [:gerv]]

> This revision replaces the "FILTER" shorthand "|" with the longer version to
> support auto-security-hole-detection scripts.  

You are, of course, running this script (along with the other tests) and making
sure Bugzilla still passes with your patch applied, aren't you? ;-) (runtests.sh)

> "global" is a namespace
> declaration that allows variables to be used from included files and as such
> has to remain.

I don't understand this sentence. There is no technical reason why you need the
"global".

I had another idea, actually. You could save all the "FILTER html"s by either:
- specifying that terms are plaintext only (a reasonable restriction IMO)
  or
- having a variables.html.tmpl file which is included in the HTML files, and a 
  variables.csv.tmpl for CSV, etc, and a variables.none.tmpl for other things.

Out of curiousity, why have you used this mechanism for the words "bit" and "bits"?

Gerv

Comment 43

[Jon Wilmoth]

I was not aware of the runtest.pl script and did manual click-through testing 
to ensure everything worked.  Unfortunately, I am not able to run the 
runtest.pl script as returned what I believe to be perl environment config 
errors:

bash-2.03$ /usr/bonsaitools/bin/perl runtests.pl
t/001compile........Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/per
l/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/001compile.t line 33.
BEGIN failed--compilation aborted at t/001compile.t line 33.
t/001compile........dubious
        Test returned status 2 (wstat 512, 0x200)
t/002goodperl.......Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/002goodperl.t line 35.
BEGIN failed--compilation aborted at t/002goodperl.t line 35.
t/002goodperl.......dubious
        Test returned status 2 (wstat 512, 0x200)
t/003safesys........Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/003safesys.t line 33.
BEGIN failed--compilation aborted at t/003safesys.t line 33.
t/003safesys........dubious
        Test returned status 2 (wstat 512, 0x200)
t/004template.......Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/004template.t line 41.
BEGIN failed--compilation aborted at t/004template.t line 41.
t/004template.......dubious
        Test returned status 2 (wstat 512, 0x200)
t/005no_tabs........Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/005no_tabs.t line 36.
BEGIN failed--compilation aborted at t/005no_tabs.t line 37.
t/005no_tabs........dubious
        Test returned status 2 (wstat 512, 0x200)
t/006spellcheck.....Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/006spellcheck.t line 43.
BEGIN failed--compilation aborted at t/006spellcheck.t line 43.
t/006spellcheck.....dubious
        Test returned status 2 (wstat 512, 0x200)
t/007util...........Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/007util.t 
line 31.
BEGIN failed--compilation aborted at t/007util.t line 31.
t/007util...........dubious
        Test returned status 2 (wstat 512, 0x200)
t/008filter.........Can't locate Test/More.pm in @INC (@INC contains: 
t /opt/perl/lib/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread-
multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at 
t/008filter.t line 39.
BEGIN failed--compilation aborted at t/008filter.t line 39.
t/008filter.........dubious
        Test returned status 2 (wstat 512, 0x200)
Uncaught exception from user code:
        FAILED--8 test scripts could be run, alas--no output ever seen
        Test::Harness::runtests
('t/001compile.t', 't/002goodperl.t', 't/003safes
ys.t', 't/004template.t', 't/005no_tabs.t', 't/006spellcheck.t', 't/007util.t',
't/008filter.t') called at runtests.pl line 41
bash-2.03$

There actually is a very good technical reason to include global...TT requires 
it ;).   http://www.template-
toolkit.org/docs/plain/Manual/Variables.html#Local_and_Global_Variables

I like the idea of having variables.html.tmpl, variables.csv.tmpl, but also 
think the plain text restriction is reasonable and simplifies things 
tremendously.  I'm willing to do either to get this incorporated in the next 
release.

Comment 44

[Gervase Markham [:gerv]]

> bash-2.03$ /usr/bonsaitools/bin/perl runtests.pl
> t/001compile........Can't locate Test/More.pm in @INC (@INC contains: 

You need to install the Test framework :-) I believe
perl -MCPAN -e "install 'Test'" should do the trick, but I'm not sure.

> There actually is a very good technical reason to include global...TT requires 
> it ;).

But if something is included at the top level, it'll be visible to all
sub-templates anyway. If it does turn out we need it, then you could do:

[% terms = global.terms %]
in the variables.x.tmpl template, so everyone could use the shorter syntax.

(The global keyword does not persist values between requests - you knew that,
right?)

> I like the idea of having variables.html.tmpl, variables.csv.tmpl, but also 
> think the plain text restriction is reasonable and simplifies things 
> tremendously. 

Let's go with the plain text restriction then, call it variables.none.tmpl, and
add an exception to 008template.t to exclude all directives starting with "terms."

Gerv

Comment 45

[Jon Wilmoth]

Attachment: 2.17.4 based patch to replace hardcoded termanology with template variables (Version 3)

Incorporated Gerv's requests for shorter variable names.

Comment 46

[Jon Wilmoth]

Attachment: Part 2 of 2 - 2.17.4 based patch to replace hardcoded termanology with template variables

Shorter variable names per Gerv's request.

Comment 47

[Gervase Markham [:gerv]]

Comment on attachment 126564 [details] [diff] [review]
2.17.4 based patch to replace hardcoded termanology with template variables (Version 3)

Pants. One mis-click and there goes a whole review.

Basically, r=gerv if you fix:

- The unnecessary filter in index.html.tmpl (line 10 or so of the patch)
- The few instances where you are still using the typeFooBarBaz style of type
declaration - search carefully, I think there are at least 3
- the places where you do BLOCK%] instead of BLOCK %] (that's a nit.)

Gerv

Comment 48

[Jon Wilmoth]

Attachment: 2.17.4 based patch to replace hardcoded termanology with template variables (Version 4)

Removed the unnecessary filter in index.html.tmpl

Replaced | html with "FILTER html"
\template\en\default\global\hidden-fields.html.tmpl

Left "typeLabelLowerPlural" & "typeLabelLowerSingular" variables in
\template\en\default\admin\flag-type\edit.html.tmpl as the value is either
terms.bug or attachment depending on the flag type.

terms.zeroSearchResults remains

Comment 49

[Gervase Markham [:gerv]]

Comment on attachment 126628 [details] [diff] [review]
2.17.4 based patch to replace hardcoded termanology with template variables (Version 4)

r=gerv. John - you don't have checkin privs, do you?

Gerv

Comment 50

[Dave Miller [:justdave]]

-> patch author

The patch is huge, so flagging the huge patches bug as a dependency so the
people who care get notified that it's coming down the pike.

Comment 51

[Gervase Markham [:gerv]]

Attachment: Merged to tip v.1

This version combines the two patches, removes all the Windows line endings and
tabs, merges it to the tip and fixes all the conflicts, and makes all the tests
pass. Phew :-)

Gerv

Comment 52

[Gervase Markham [:gerv]]

I plan to check this in pretty soon - [e-mail], if you have a
second, could you look it over and make sure I haven't broken anything you can see?

Thanks,

Gerv

Comment 53

[Gervase Markham [:gerv]]

Fixed. (I won't list all the checkin logs here.) Thanks to Jon for persevering
with this.

Gerv

Comment 54

[Dave Miller [:justdave]]

Nobody ran tests....  the tree is burning...

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Bugzilla

Comment 55

[Gervase Markham [:gerv]]

That's really weird. I ran tests before checking in, and they all passed - and
the errors it's flagging correspond to errors I know I fixed during the merge.

<checks> It seems filterexceptions.pl didn't get checked in. <sigh>

Gerv

Comment 56

[Gervase Markham [:gerv]]

Re-fixed.

Gerv

Comment 57

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

Comment on attachment 121738 [details]
2.17.3 based patch using termanology variables across all templates

cancelling unneeded review request

Comment 58

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

Comment on attachment 125851 [details] [diff] [review]
2.17.4 based patch to replace hardcoded termanology with template variables

cancelling unneeded review request

Comment 59

[Dave Miller [:justdave]]

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

Comment 60

[P P N]

There are similar changes /updates we would like to see in bugzilla. I would like to know if the changes have been completed and whether we could avail the same if were to install bugzilla now.

Please read the BUG #344086 asking for same customization changes

Comment 61

[Frédéric Buclin]

(In reply to comment #42)
> Out of curiousity, why have you used this mechanism for the words "bit" and "bits"?

That's a very good question. This term is unusable for translation, and is only used in 3-4 places.

Comment 63

[Steve Kelem]

So...how do I change my bugzilla (3.4.1) to say "issues" instead of "bugs"?

Comment 64

[Gervase Markham [:gerv]]

http://www.bugzilla.org/docs/3.4/en/html/cust-templates.html#template-specific

Gerv