Closed
Bug 142231
Opened 22 years ago
Closed 22 years ago
template/.cvsignore should contain es, de, ... not custom
Categories
(Bugzilla :: User Interface, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: burnus, Assigned: myk)
Details
Attachments
(1 file)
339 bytes,
patch
|
gerv
:
review+
gerv
:
review+
|
Details | Diff | Splinter Review |
The .cvsignore file in ./template/ contains presently custom. Since custom moved to ./template/en/ this is no longer needed. Instead it would be nice if it contained languages which are not in CVS (yet?). If I recall correctly there are presently only Spanish and German (es, de), but there might be others.
Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
The idea is that those languages would be added to cvs, though, right? We can't .cvsignore everything except for {en,.cvsignore}, can we?
Comment 3•22 years ago
|
||
Whether the languages are added to CVS is a decision Dave has to make - he'll presumably either set some policy, or decide on a case-by-case basis. If there's no way to get .cvsignore to ignore "all except {set}" then we should just add whatever languages to .cvsignore that people ask us to (and remove them if their language ever gets checked in.) Or does that approach have problems? Gerv
Comment 4•22 years ago
|
||
I'd like to check them in as long as we can get people willing to maintain them. Maybe we can add components for the language sets that assign to the people maintaining them...
Comment 5•22 years ago
|
||
I think Dave's on the right track there. Using the main Bugzilla CVS is probably best for the translations as long as there isn't another good place for a Bugzilla translation community. Could you people then configure a cvs loginfo script so that every time something is committed into the templates/en tree, a new translators@bugzilla.org (for example) mailing list would receive the cvs diff? I'm going start a Finnish translation at some point and I'd very much like to stay up to date with the template modifications (without the strain of frequently checking yet another bookmarked bonsai query).
Comment 6•22 years ago
|
||
Dave said: > I'd like to check them in as long as we can get people willing to maintain them. That's cool, but I don't think they should be part of the default pull. It's bloated enough already with 3 copies of the docs. ;-) Jouni said: > I'd very much like to stay up to date with the template modifications I would say it's far more work than necessary to update any translation constantly. You should do so only at release time (hopefully we'll be releasing more frequently in the future.) It's far easier to have the simple rule that "translations don't work (or are not supported) in CVS" than to have something like "Er, some translations work at the moment - to find out exactly which ones, consult the authors, and hope that by the time they reply we haven't broken anything in the mean time". Anyway, if someone's doing "de" and "es" then we can add them to .cvsignore. 2xr=gerv on the patch. Gerv
Comment 7•22 years ago
|
||
>I would say it's far more work than necessary to update any translation >constantly. You should do so only at release time (hopefully we'll be releasing >more frequently in the future.) You people set the rules on what gets into the cvs (and when). You decide whether you offer template change notifications. But please, don't base your rulings on thoughts about what is necessary for someone else. That cannot be known in a project like this. I know that at least I won't be updating any translations continously, but I'd still like to receive the template notifications to stay informed of changes that could potentially be worth doing even before the release. This applies especially since our installation seems to have an continously increasing need of both a good translation and running fairly close to the cvs tip (meaning that waiting for releases is not always acceptable). >It's far easier to have the simple rule that "translations don't work (or are >not supported) in CVS" than to have something like "Er, some translations work >at the moment - to find out exactly which ones, consult the authors, and hope >that by the time they reply we haven't broken anything in the mean time". I agree with you on this 100%. Personally I couldn't care less if translations were checked in only once per release. It's probably quite impossible to have most of them even remotely up-to-date in CVS between releases anyway. But IMO, all this still doesn't make informing the translators about template changes unnecessary.
Comment 8•22 years ago
|
||
OK, that's a fair point (or several fair points.) I don't know if such a script can be set up - if Dave approves, we'd need to file a bug on mozilla.org and get Myk or Dawn to either set it up or file one on AOL server ops. Gerv
Assignee | ||
Comment 9•22 years ago
|
||
>This applies
>especially since our installation seems to have an continously increasing need
>of both a good translation and running fairly close to the cvs tip (meaning that
>waiting for releases is not always acceptable).
b.m.o has the same need, and other installations do too. We discussed it a few
months ago and decided to start releasing "developers" releases every month or
two after 2.16 gets released. These releases won't have specific release goals,
so they can't get delayed like 2.16, but they will have short pre-release
freezes (probably about a week) to ensure some measure of stability. So, the
situation should shortly get better.
Comment 10•22 years ago
|
||
Comment on attachment 82327 [details] [diff] [review] Simple patch: Remove custom add 'de' and 'es' to template/.cvsignore 2xr=gerv. Gerv
Attachment #82327 -
Flags: review+
Comment 11•22 years ago
|
||
Fixed. Checking in template/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/template/.cvsignore,v <-- .cvsignore new revision: 1.3; previous revision: 1.2 done Gerv
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Target Milestone: --- → Bugzilla 2.16
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•