Closed
Bug 182975
Opened 22 years ago
Closed 17 years ago
Bugzilla directory structure to be adopted to l10n needs
Categories
(Bugzilla :: Bugzilla-General, enhancement, P2)
Bugzilla
Bugzilla-General
Tracking
()
RESOLVED
FIXED
Bugzilla 3.2
People
(Reporter: vitaly.fedrushkov, Assigned: himorin)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 11 obsolete files)
18.77 KB,
patch
|
mkanat
:
review+
LpSolit
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461) Build Identifier: We need to extend current Bugzilla directory structure to localization needs. AFAICT visible localized parts are: 1. templates (under templates/*) 2. help pages (*.html) 3. online documentation (docs/*) To date, only page template structure can handle multilanguage framework. And CVS does not handle renames/moves very well, so, before we (translators) make incompatible forks it is time to stop and think a moment. Requirements: 1. A localized template set MUST NOT overwrite any files from release. However, original files MAY require patches to make things work, and localization package SHOULD include them or explicitly mention required changes in documentation. 2. Localized templates should link to localized help/documentation pages. So (under req. 1) template set SHOULD keep them aside, not over, original documentation. 3. Bugzilla site administrators are not expected to speak the language in question. So minimal setup documentation SHOULD be put in English :-) Proposal: help/<LANG>/*.html for help pages; docs/<LANG>/{sgml,txt,html}/ to accommodate documentation; Note that original help pages (*.html) aren't placed very well -- think about access control at WebDAV driven sites. Problems: 1. Not sure whether pages like keyword descriptions belong -- in wider sense -- to database content or online help. Things may get worse when/if user-defined fields will be implemented. No good idea on how such content -- name it 'administrative database content' or 'data driven online help pages' -- should be properly localized. 2. Some languages have more than one encoding. In Russia we have four :-(, and a special Apache fork to handle all these. Not sure about other marvels of the nature. Do we need */<LANG>/<encoding>/* ? Reproducible: Always Steps to Reproduce:
Comment 1•22 years ago
|
||
> 1. templates (under templates/*) I think this is well localizable. >1. A localized template set MUST NOT overwrite any files from release. > However, original files MAY require patches to make things work, and > localization package SHOULD include them or explicitly mention required > changes in documentation. I think the goal is that installing a localized version only requires to add files to templates/<lang-tag> and to docs/<lang-tag> an not further changes. This is not completely true right now as at least bug 126955 should be fixed (I try to find time to do so, but at the moment I'm again studing for an exam). Additionally some files still need to be templatatized... By the way, I favour quoting a bug to including the patch directly; since those patches seem to change rather fast - at least in unstable (2.17[.1]), > 2. help pages (*.html) Those should go away anyway (bug 106612). > 3. online documentation (docs/*) I would also favour docs/en/ to docs/ for the English documentation, but docs is more or less only documentation for the admin rather than for the novice user. And as long there is no language with "txt" as 3 letter language tag, it is fine to add the localized version to docs/<lang-tag> anyway. > 2. Some languages have more than one encoding. In Russia we have four :-(, > and a special Apache fork to handle all these. Not sure about other marvels > of the nature. Do we need */<LANG>/<encoding>/* ? Hmm. I do dislike the introduction of an encoding subdirectoy, but I'm in the happy situation that for English almost all encodings are suitable and for German with ü instead of 8bit encoding this holds true for at least ascii, utf-8, latin1. One could though use /<lang>.<encoding>/ as done for the locales under Unix. (See also bug 126266)
Comment 2•22 years ago
|
||
Why would encoding matter, as long as its identified correctly? At this point, I'm becoming more and more convinced that we should simply send everything as utf-8. This has the advantage that perl5.8 supports it natively, plus we can store comments and so on in the db consistently. See the separate encoding bug for thoughts on that.
Comment 3•22 years ago
|
||
> Why would encoding matter, as long as its identified correctly? No idea. But I live in a utf-8/latin1 environment anyway which are rather easily detectable/changeable. > At this point, I'm becoming more and more convinced that we should simply send > everything as utf-8. At least for browser -> bugzilla I see the problem with ISO-8859-1 (etc.?) encodings which then would need to be converted. (At least I remember problems with Netscape 4 [here still widely used :-(] for UTF-8 for form submissions and printing Latin1 characters encoded as utf8 as garbage. For formsubmission I used a hidden form with "ü" which I then compared with the latin1/utf8 string ...) What for the utf8 transition still would be need is that e.g. Ü and ü both match (case-insensitivity), but this is currently not possible, so there would be no change. > See the separate encoding bug for thoughts on that. => bug 126266, "Allow administrator to set charset encoding for pages and email"
Depends on: bz-charset
Reporter | ||
Comment 4•22 years ago
|
||
> > 2. help pages (*.html)
> Those should go away anyway (bug 106612).
Should we use template/*/default/help/*.html.tmpl instead?
It should be noted that help pages are slightly different in their consumer
qualities: they're off from typical user navigation path, and in frame-capable
template set they should open in separate window. There is little in equipping
them with standard header/footer, etc.
None the less, this will make upcoming user-defined states and fields more
documentable.
Reporter | ||
Comment 5•22 years ago
|
||
> Why would encoding matter, as long as its identified correctly? Yes it is, but we don't know the result. Encoding detection logic in Apache does this for us, so that web site content can be kept in single encoding and all others are derived according to auto- detected client charset or explicit request. CGI form data are no exception. It works well: we can write in any encoding we like, and httpd does the rest. But it breaks when we send email with database fields quoted: we know how we have stored them, but we don't know which encoding was used to access them. At least without interaction with mod_charset. Bug 126266 discussion also implicitly assumes our knowledge of client-side charset -- or at least his/her capability to read email in ours :-)
Reporter | ||
Comment 6•22 years ago
|
||
> I do dislike the introduction of an encoding subdirectory...
Me too, because I can get Russian Apache to solve my problem. I've put this
under 'Problems' because there are several encodings for Chinese, Arabic and
Hebrew, and I am not sure whether Cyrillic approach is applicable there.
Comment 7•22 years ago
|
||
I'm not convinced we need to do anything about the docs directory... As for charset, I am convinced we should just use UTF-8. All modern browsers support it now. Not sure what really needs to be done here. All of the *.html files are supposed to be getting replaced with templates, so that's a moot point. The template directory is already split up by language. The only other issue remaining here is the docs directory...
Assignee: justdave → jake
Status: UNCONFIRMED → NEW
Component: Bugzilla-General → Documentation
Ever confirmed: true
Reporter | ||
Comment 8•22 years ago
|
||
Then we'll wait until bug 106612 lands. At the moment I have no resources to shoot it down myself. So the question boils down to docs/<LANG>/* If that's OK, we have a decision for now.
Depends on: 106612
Comment 9•22 years ago
|
||
I'm not really sure that we need to change the directory structure. I don't forsee any translated versions of the Guide being in CVS. I'm also not sure that anybody would have an extreme desire to put their translation in the docs/ folder, but I could be wrong about that.
Updated•22 years ago
|
Priority: -- → P5
Comment 10•21 years ago
|
||
Jake is leaving for a while (Reserve unit got called up), and we don't have a new docs owner yet. Anyone interested in helping out, please add documentation@bugzilla.org to your watch list in your email preferences in Bugzilla.
Assignee: jake → documentation
Comment 11•21 years ago
|
||
Preliminarily moving all docs bugs to 2.18, we should make a valiant attempt to have the docs as up-to-date as possible when 2.18 releases.
Target Milestone: --- → Bugzilla 2.18
Updated•20 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.22
Comment 12•20 years ago
|
||
Officially marking this as "Future". I don't think we need this right now. It's not something I want to throw out though because it is logical, and we may decide we want it down the line. Right now we don't.
Assignee: documentation → nobody
Target Milestone: Bugzilla 2.22 → Future
Comment 13•19 years ago
|
||
Well, I just found out this one... Isn't the right time now, to go together/after the few related UTF-8 bugs? Seems all demepdencies are fixed now in trunk. We have the new utf8 parameter (bug #126266), some initial utf8 conversion tools (bug #280633) and long forgotten general comments (bug #135762). Adding Japanese to the problematic encodings, I think we should stick with UTF-8 where possible. As an alternative to a directory structure, going the apache way, add a language extension to every file, like: help/index.ja.html help/index.bg.html help/index.it.html This way, at least for the web part, incomplete translations will default to $file.en.html and thus gradual translation will be possible (e.g. CVS/svn export will do it on a live system). Might be a bit difficult for translators though, depending on the tools used. As a plus, having a single XML source file (with lang attributes, e.g. lang="ja") and a simple XSLT to parse it into the required documentation will greatly enhance the configurability/maintainance of a multi-lingual instalation. Is such a thing real for 2.22?
Comment 14•19 years ago
|
||
For the record... Gradual translation, defaulting to en, is already possible if you keep defaultlanguage at en.
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Target Milestone: Future → ---
![]() |
||
Comment 15•17 years ago
|
||
We talked about this l10n problem at our Bugzilla meeting today, and its priority has somewhat increased since then. :) We already have template/<lang> and we plan to add docs/<lang> and maybe t/<lang> so that 006spellcheck.t and 009bugwords.t can do language-specific checks. This way, each l10n tarball would need a template/<lang>, docs/<lang> and t/<lang> directory, and no conflict with the default files would occur.
Assignee: nobody → general
Component: Documentation → Bugzilla-General
Priority: P5 → P3
Target Milestone: --- → Bugzilla 3.2
Updated•17 years ago
|
Summary: Bugzilla directory structure to be adopted to l10n needs → Bugzilla documentation directory structure to be adopted to l10n needs
Updated•17 years ago
|
Summary: Bugzilla documentation directory structure to be adopted to l10n needs → Bugzilla directory structure to be adopted to l10n needs
![]() |
||
Comment 16•17 years ago
|
||
Max, would you block 3.2 on it?
Comment 17•17 years ago
|
||
No, it's not a blocker, but it's simple enough that it could and should be done anyway.
![]() |
||
Comment 18•17 years ago
|
||
I really don't want to work on it, but we need it and nobody else seems to be interested in this bug. :-/
Comment 19•17 years ago
|
||
Any reason himorin couldn't work on it?
Reporter | ||
Comment 20•17 years ago
|
||
Not sure how much work is meant here, besides moving some files between dirs in CVS. Am I missing something?
Assignee | ||
Comment 21•17 years ago
|
||
(In reply to comment #19) > Any reason himorin couldn't work on it? ok. :) (In reply to comment #20) > Not sure how much work is meant here, besides moving some files between dirs in > CVS. > > Am I missing something? As already commented on comment #15 by LpSolit, what we needed to do is * move docs/* to docs/en (lang=en) * modify docs/makedocs.pl to work with docs/<lang> * modify t/006spellcheck.t and t/009bugwords.t to support l10n About the last one, I think we can make the evilwords and bugwords in t/006 and t/009 to be templates and store the files (which include the list of evilwords and bugwords) in template/<lang>.
Reporter | ||
Comment 22•17 years ago
|
||
(In reply to comment #14) > For the record... Gradual translation, defaulting to en, is already possible if > you keep defaultlanguage at en. True. Moreover, a number of templates (32 of 274 in 3.0) have no user readable texts and do not need any l18n: config.js.tmpl config.rdf.tmpl admin\users\listselectvars.html.tmpl attachment\diff-footer.html.tmpl bug\field.html.tmpl bug\show.xml.tmpl bug\time.html.tmpl bug\create\comment.txt.tmpl global\banner.html.tmpl global\footer.html.tmpl global\header.html.tmpl global\help-header.html.tmpl global\help.html.tmpl global\initialize.none.tmpl global\js-products.html.tmpl global\message.txt.tmpl global\select-menu.html.tmpl global\tabs.html.tmpl global\textarea.html.tmpl global\userselect.html.tmpl list\list.csv.tmpl list\list.ics.tmpl list\list.js.tmpl list\list.rdf.tmpl reports\duplicates.rdf.tmpl reports\report-bar.png.tmpl reports\report-line.png.tmpl reports\report-pie.png.tmpl reports\report.csv.tmpl reports\series-common.html.tmpl search\search-plugin.xml.tmpl whine\multipart-mime.txt.tmpl Today localized instances have two options: 1. force defaultlanguage to 'en' 2. copy all missing from en/default/ to <lang>/default/ and track them by hand during upgrades. What about setting up 'NULL' language and template search order as follows: 1. user Accept-Language 2. defaultlanguage 3. NULL
Reporter | ||
Comment 23•17 years ago
|
||
(In reply to comment #21) > About the last one, I think we can make the evilwords and bugwords in t/006 and > t/009 to be templates and store the files (which include the list of evilwords > and bugwords) in template/<lang>. This approach is already used in t/008 and template/<lang>/default/filterexceptions.pl See also bug 192677 comment 26.
Assignee | ||
Comment 24•17 years ago
|
||
(In reply to comment #22) > True. Moreover, a number of templates (32 of 274 in 3.0) have no user readable > texts and do not need any l18n: no. > global\textarea.html.tmpl as bug 388723, Japanese users will get some-kind broken display without 'wrap="hard"'. > reports\report-bar.png.tmpl > reports\report-line.png.tmpl > reports\report-pie.png.tmpl we need font definitions in these templates (currently). I think we can solve this with making template/default or something, and add 'default' as language name in getTemplateIncludePath. L10n-er can edit and provide files as a part of l10n-archive. Directory hierarchy will be as the following. template/default/default/config.js.tmpl (and so on.) template/en/default/xxxx template/fr/default/xxxx template/ru/default/xxxx template/ja/default/xxxx etc. etc...
![]() |
||
Comment 25•17 years ago
|
||
(In reply to comment #19) > Any reason himorin couldn't work on it? If he wants to work on this bug, I would be very happy to reassign it to him. My TODO list for Bugzilla 3.2 is already long enough. himorin, feel free to reassign the bug to you.
![]() |
||
Comment 26•17 years ago
|
||
(In reply to comment #21) > About the last one, I think we can make the evilwords and bugwords in t/006 and > t/009 to be templates and store the files (which include the list of evilwords > and bugwords) in template/<lang>. That's a great idea! Let's do that instead, so that we don't need another t/<lang>.
Reporter | ||
Comment 27•17 years ago
|
||
(In reply to comment #24) > > global\textarea.html.tmpl > as bug 388723, Japanese users will get some-kind broken display without > 'wrap="hard"'. To the point! Any template MAY be overridden by <lang>/{default,custom}/ Note 'MAY' in RFC 2119 sense, neither 'SHOULD' nor 'MUST'.
Assignee | ||
Comment 28•17 years ago
|
||
(In reply to comment #25) > > Any reason himorin couldn't work on it? > > If he wants to work on this bug, I would be very happy to reassign it to him. > My TODO list for Bugzilla 3.2 is already long enough. himorin, feel free to > reassign the bug to you. Ok. I take this bug. :) (In reply to comment #27) > > > global\textarea.html.tmpl > > as bug 388723, Japanese users will get some-kind broken display without > > 'wrap="hard"'. > > To the point! Any template MAY be overridden by <lang>/{default,custom}/ > > Note 'MAY' in RFC 2119 sense, neither 'SHOULD' nor 'MUST'. At that point, i think we SHOULD keep templates in template directory and keep to be customizable.. (In reply to comment #24) > I think we can solve this with making template/default or something, and add > 'default' as language name in getTemplateIncludePath. L10n-er can edit and > provide files as a part of l10n-archive. > > Directory hierarchy will be as the following. > template/default/default/config.js.tmpl (and so on.) > template/en/default/xxxx > template/fr/default/xxxx > template/ru/default/xxxx > template/ja/default/xxxx > etc. etc... This has a bug. lol 1. user sent multi-langs as Accept-Languages like fr,ja,en 2. site uses multi-language templates like en,fr,ja,xx etc. 3. ja template have customized template/default/default/xxx files with 1 and 2, getTemplateIncludePath returns path includes fr, ja, and en in this order. When template dispatcher searches 'config.js.tmpl', it fails on fr templates but ja templates. And use config.js.tmpl in ja for fr users.
Assignee: LpSolit → shimono
Comment 29•17 years ago
|
||
(In reply to comment #28) > 1. user sent multi-langs as Accept-Languages like fr,ja,en > 2. site uses multi-language templates like en,fr,ja,xx etc. > 3. ja template have customized template/default/default/xxx files > > with 1 and 2, getTemplateIncludePath returns path includes fr, ja, and en in > this order. > When template dispatcher searches 'config.js.tmpl', it fails on fr templates > but ja templates. And use config.js.tmpl in ja for fr users. Well, if the site has en,fr,ja,xx installed, and a user requests fr,de,xx, then imho the site must proceed *as it does now* and try fr,xx,en in this order. In particular, ja must not be shown in this case.
Comment 30•17 years ago
|
||
Make sure you're looking at the tip code, on that. The code lives in Bugzilla::Install::Util::template_include_path, now. (Which also has POD that documents its behavior.)
Reporter | ||
Comment 31•17 years ago
|
||
(In reply to comment #28) > This has a bug. lol > 1. user sent multi-langs as Accept-Languages like fr,ja,en > 2. site uses multi-language templates like en,fr,ja,xx etc. > 3. ja template have customized template/default/default/xxx files > with 1 and 2, getTemplateIncludePath returns path includes fr, ja, and en in > this order. Not this way. Comment #22 should read: > ... search order as follows: 1. Best value negotiated using Accept-Languages and installed templates 2. defaultlanguage 3. template/default/default Note step 1 yielding a single value, not an order of preference. > When template dispatcher searches 'config.js.tmpl', it fails on fr templates > but ja templates. And use config.js.tmpl in ja for fr users. This will still happen with defaultlanguage=ja. But, under Postel's law, default language SHOULD be more robust than others ;-)
Assignee | ||
Comment 32•17 years ago
|
||
(In reply to comment #31) > > This has a bug. lol > > > 1. user sent multi-langs as Accept-Languages like fr,ja,en > > 2. site uses multi-language templates like en,fr,ja,xx etc. > > 3. ja template have customized template/default/default/xxx files > > > with 1 and 2, getTemplateIncludePath returns path includes fr, ja, and en in > > this order. > > Not this way. Comment #22 should read: > > ... search order as follows: > > 1. Best value negotiated using Accept-Languages and installed templates hmm. best 'single' value. (as noted below) if we use Accept-Language for critical reason (?), i think we should consider about q-value for Accept-Language and languages. > 2. defaultlanguage > 3. template/default/default > > Note step 1 yielding a single value, not an order of preference. So, change Bugzilla::Install::Util::template_include_path to select a single language rather than to select multiple languages? > > When template dispatcher searches 'config.js.tmpl', it fails on fr templates > > but ja templates. And use config.js.tmpl in ja for fr users. > > This will still happen with defaultlanguage=ja. But, under Postel's law, > default language SHOULD be more robust than others ;-) Yeah, it might happen with defaultlangauge=ja. Of cource, i think default language SHOULD be more robust, but it depends on the quality of the localization. Under the Murphy's law, everyone will make heavy mistakes :-) I don't know how other languages translate templates, I (at Bugzilla-ja) first copy all new files (and changes) from -en tar ball, and start translation. If localizers on other languages do the same thing, i think it's safe to keep files in the template directory in each language.
Comment 33•17 years ago
|
||
(In reply to comment #32) > I don't know how other languages translate templates, I (at Bugzilla-ja) first > copy all new files (and changes) from -en tar ball, and start translation. > If localizers on other languages do the same thing, i think it's safe to keep > files in the template directory in each language. For the French locale, the initial localization was made from the en-US tarball. Now, we have a CVS on sourceforge.net for 3.0.x branch and for the trunk and keep them up-to-date following the changes on bonsais.
![]() |
||
Comment 34•17 years ago
|
||
For now, all I want is the docs/<lang>/ structure, using the same mechanism as template/<lang>/, i.e. if your browser is configured to read french templates, then display french documentation as well. If something is suboptimal or should use <default>/ or whatever, this should be fixed in a separate bug.
Comment 35•17 years ago
|
||
I don't know if you guys noticed, but both language parameters are gone from the current CVS HEAD. So there is no "defaultlanguage".
Reporter | ||
Comment 36•17 years ago
|
||
(In reply to comment #35) > I don't know if you guys noticed, but both language parameters are gone from > the current CVS HEAD. So there is no "defaultlanguage". Wow. Not a single word at http://wiki.mozilla.org/Bugzilla:Params After reading bug 374331 and bug 365378 I guess it falls back to <en> in any case. If so please disregard comment #22 and following discussion.
![]() |
||
Comment 37•17 years ago
|
||
(In reply to comment #36) > Wow. Not a single word at http://wiki.mozilla.org/Bugzilla:Params A single word about what? Bugzilla:Params lists all existing parameters. And as you can see, it doesn't mention defaultlanguage, meaning that this parameter no longer exists.
Comment 38•17 years ago
|
||
What LpSolit is saying is that the parameters were removed before the discussion that generated Bugzilla:Params.
Assignee | ||
Comment 39•17 years ago
|
||
(In reply to comment #34) > For now, all I want is the docs/<lang>/ structure, using the same mechanism as > template/<lang>/, i.e. if your browser is configured to read french templates, > then display french documentation as well. If something is suboptimal or should > use <default>/ or whatever, this should be fixed in a separate bug. ok. i'll be focused at that point. So, needed to do is * move docs/* to docs/en (lang=en) * modify docs/makedocs.pl to work with docs/<lang> * modify t/006spellcheck.t and t/009bugwords.t to support l10n as comment #21. (In reply to comment #36) > > I don't know if you guys noticed, but both language parameters are gone from > > the current CVS HEAD. So there is no "defaultlanguage". > > Wow. Not a single word at http://wiki.mozilla.org/Bugzilla:Params > > After reading bug 374331 and bug 365378 I guess it falls back to <en> in any > case. If so please disregard comment #22 and following discussion. i've update my knowledge with the current tip. Bugzilla searches the template directory and make a list of installed languages, and merges with Accept-Language in the HTTP request. (If, it's wrong, pls point.)
Status: NEW → ASSIGNED
Comment 40•17 years ago
|
||
(In reply to comment #39) > Bugzilla searches the template directory and make a list of installed > languages, and merges with Accept-Language in the HTTP request. (If, it's > wrong, pls point.) It doesn't merge. It creates an intersection, retaining the order given in the Accept-Language header. Plus, it adds "en" at the end, if not part of the intersection.
Assignee | ||
Comment 41•17 years ago
|
||
patch for * t/009bugwords.t (uses template/<lang>/default/009bugwords) * docs/makedocs.pl It works on current tip actually, but i consider this as only for a proposal of the algorithm.
Attachment #297143 -
Flags: review?(mkanat)
Assignee | ||
Comment 42•17 years ago
|
||
Assignee | ||
Comment 43•17 years ago
|
||
(In reply to comment #40) > > Bugzilla searches the template directory and make a list of installed > > languages, and merges with Accept-Language in the HTTP request. (If, it's > > wrong, pls point.) > > It doesn't merge. It creates an intersection, retaining the order given in the > Accept-Language header. Plus, it adds "en" at the end, if not part of the > intersection. Oops,,. Sorry for my poor english :-) s/merges/intersection/ (mathematically AND).. mm, i've made a oversight for default en. # but i think we shouldn't consider that users always have en templates.. # of cource, i should file another bug if i want to discuss about this. (as comment #34)
Comment 44•17 years ago
|
||
I think we should keep requiring that the en templates are always there. This allows for small incomplete localizations (for example, only for enter_bug and show_bug), or incremental localization work. (If we don't require en, these would need to make non-translated templates part of their localization, which is a notion I don't like very much.)
![]() |
||
Comment 45•17 years ago
|
||
The final patch will need: 1) A correct and readable indentation 2) the real 009bugwords.none.tmpl template included in the patch.
Assignee | ||
Comment 46•17 years ago
|
||
(In reply to comment #45) > The final patch will need: > 1) A correct and readable indentation > 2) the real 009bugwords.none.tmpl template included in the patch. Should I set the name of '009bugwords' file with .tmpl? If so, i should exclude the file in 009bugwords.t.
![]() |
||
Comment 47•17 years ago
|
||
(In reply to comment #46) > Should I set the name of '009bugwords' file with .tmpl? It's a template, so yes.
Comment 48•17 years ago
|
||
Also, the path should be template/en/default/test/009bugwords.none.tmpl (none.tmpl is only if it's a real Template Toolkit file. If it's just a Perl file, it should be .pl.)
Comment 49•17 years ago
|
||
This is a blocker because changing the directory structure is something we should do sooner rather than later. I don't want to delay this until 4.0.
Flags: blocking3.2+
Assignee | ||
Comment 50•17 years ago
|
||
patch rev.2
Attachment #297143 -
Attachment is obsolete: true
Attachment #297144 -
Attachment is obsolete: true
Attachment #297143 -
Flags: review?(mkanat)
Assignee | ||
Updated•17 years ago
|
Attachment #297547 -
Flags: review?(mkanat)
Assignee | ||
Updated•17 years ago
|
Attachment #297547 -
Flags: review?(LpSolit)
Comment 51•17 years ago
|
||
Comment on attachment 297547 [details] [diff] [review] patch v.2 Please attach a "cvs diff -u".
Attachment #297547 -
Flags: review?(mkanat) → review-
Assignee | ||
Comment 52•17 years ago
|
||
(In reply to comment #51) > (From update of attachment 297547 [details] [diff] [review]) > Please attach a "cvs diff -u". aaaahhh... Forgot.
Assignee | ||
Comment 53•17 years ago
|
||
w/ -u.
Attachment #297547 -
Attachment is obsolete: true
Attachment #297548 -
Flags: review?(mkanat)
Attachment #297547 -
Flags: review?(LpSolit)
Assignee | ||
Comment 54•17 years ago
|
||
* i think we don't need modify t/006 (it's only for scripts) * we should move contents of docs/ to docs/en README.docs html images pdf rel_notes.txt txt xml * translated documents (xmls) should be placed at docs/<lang>
Comment 55•17 years ago
|
||
Comment on attachment 297548 [details] [diff] [review] patch v.2 rev2 I haven't looked this over in detail, but I know that at least there are parts of Bugzilla that link to the docs, and so you'll have to fix those links, I'm pretty sure.
Attachment #297548 -
Flags: review?(mkanat) → review-
Assignee | ||
Comment 56•17 years ago
|
||
includes patch for Filesystem.pm and some templates.
Attachment #297548 -
Attachment is obsolete: true
Assignee | ||
Updated•17 years ago
|
Attachment #297778 -
Flags: review?(mkanat)
Assignee | ||
Updated•17 years ago
|
Attachment #297778 -
Flags: review?(mkanat)
Assignee | ||
Comment 57•17 years ago
|
||
add docs/rel_notes.txt for moving (modify only Bugzilla/Install/Filesystem.pm) I've made patch for file move, whose size is > 300kB in gzip format.. # i couldn't include gif files.
Attachment #298274 -
Flags: review?
Assignee | ||
Comment 58•17 years ago
|
||
(In reply to comment #57) > Created an attachment (id=298274) [details] > patch v4 > > add docs/rel_notes.txt for moving (modify only Bugzilla/Install/Filesystem.pm) > > I've made patch for file move, whose size is > 300kB in gzip format.. > # i couldn't include gif files. i couldn't attach the file above. (patch for docs dir) to move followings from docs/ to docs/en * README.docs * html * images * rel_notes.txt * xml
![]() |
||
Comment 59•17 years ago
|
||
Comment on attachment 298274 [details] [diff] [review] patch v4 >Index: Bugzilla/Install/Filesystem.pm >- 'docs/rel_notes.txt' => { perms => $ws_readable }, >- 'docs/README.docs' => { perms => $owner_readable }, >+ 'docs/*/rel_notes.txt' => { perms => $ws_readable }, >+ 'docs/*/README.docs' => { perms => $owner_readable }, Is it legal to use wildcards here? >Index: docs/makedocs.pl >+my @langs = ('en'); >+my $docparent = getcwd(); >+foreach my $lang (@langs) { I don't get it: you set @langs to 'en' and then loop over it. So it only contains 'en'? Meaning that makedocs.pl won't compile other language documentation.
Assignee | ||
Comment 60•17 years ago
|
||
(In reply to comment #59) > (From update of attachment 298274 [details] [diff] [review]) > >Index: Bugzilla/Install/Filesystem.pm > > >- 'docs/rel_notes.txt' => { perms => $ws_readable }, > >- 'docs/README.docs' => { perms => $owner_readable }, > >+ 'docs/*/rel_notes.txt' => { perms => $ws_readable }, > >+ 'docs/*/README.docs' => { perms => $owner_readable }, > > Is it legal to use wildcards here? ah,, no. i'll fix it. > >Index: docs/makedocs.pl > > >+my @langs = ('en'); > >+my $docparent = getcwd(); > >+foreach my $lang (@langs) { > > I don't get it: you set @langs to 'en' and then loop over it. So it only > contains 'en'? Meaning that makedocs.pl won't compile other language > documentation. aaaaahh,, created from old one...
Assignee | ||
Updated•17 years ago
|
Attachment #298274 -
Flags: review?
Comment 61•17 years ago
|
||
(In reply to comment #60) > > Is it legal to use wildcards here? > > ah,, no. > i'll fix it. Are you sure? I use wildcards in other places--I'm pretty sure that gets run through glob().
Assignee | ||
Comment 62•17 years ago
|
||
(In reply to comment #61) > > > Is it legal to use wildcards here? > > > > ah,, no. > > i'll fix it. > > Are you sure? I use wildcards in other places--I'm pretty sure that gets run > through glob(). i've seen wrong lines. sorry. FILESYSTEM->all_files (includes files) are used in sub fix_all_file_permissions and evaluated in glob (line 571).
Assignee | ||
Comment 63•17 years ago
|
||
fixed docs/makedocs.pl as comment #59
Attachment #297778 -
Attachment is obsolete: true
Attachment #298274 -
Attachment is obsolete: true
Attachment #301088 -
Flags: review?
![]() |
||
Comment 64•17 years ago
|
||
Comment on attachment 301088 [details] [diff] [review] patch v.5 >Index: Bugzilla/Config/Core.pm > name => 'docs_urlbase', > type => 't', >- default => 'docs/html/', >+ default => 'docs/en/html/', >Index: template/en/default/pages/release-notes.html.tmpl >- <a href="docs/rel_notes.txt">Release Notes for [% terms.Bugzilla %] 2.22 >+ <a href="[% Param('docs_urlbase') FILTER html %]rel_notes.txt">Release Notes The change in Config/Core.pm bothers me. Hardcoding the lang in docs_urlbase won't let users see the documentation in their own language, if available. I would like docs_urlbase to use some magic string, e.g. %lang%, which would be replaced by the language given by the web browser, if available, else falls back to 'en'. So we would have docs/%lang%/html/.
Assignee | ||
Comment 65•17 years ago
|
||
(In reply to comment #64) > >Index: Bugzilla/Config/Core.pm > > > name => 'docs_urlbase', > > type => 't', > >- default => 'docs/html/', > >+ default => 'docs/en/html/', > > > >Index: template/en/default/pages/release-notes.html.tmpl > > >- <a href="docs/rel_notes.txt">Release Notes for [% terms.Bugzilla %] 2.22 > >+ <a href="[% Param('docs_urlbase') FILTER html %]rel_notes.txt">Release Notes > > The change in Config/Core.pm bothers me. Hardcoding the lang in docs_urlbase > won't let users see the documentation in their own language, if available. I > would like docs_urlbase to use some magic string, e.g. %lang%, which would be > replaced by the language given by the web browser, if available, else falls > back to 'en'. So we would have docs/%lang%/html/. agree with this. hmm. 1. set as Param('xxx') FILTER html FILTER user_depend and regexp %lang% to the language given by the ua (the top value from Bugzilla::Install::Util::_sort_accept_language() or only_language) I think it's not good to modify the value in Bugzilla/Config.pm. 2. set suitable language code into template variables, and use [% Param('docs_urlbase') FILTER html %]/[% language %]/html for docbase. 3. the other options.
![]() |
||
Comment 66•17 years ago
|
||
(In reply to comment #65) > 1. set as Param('xxx') FILTER html FILTER user_depend and regexp %lang% to the > language given by the ua (the top value from > Bugzilla::Install::Util::_sort_accept_language() or only_language) I don't like |FILTER user_depend|, but I agree we could reuse some code from Bugzilla::Install::Util. Instead of your new FILTER, you could use Param('docs_urlbase').replace('%lang%', $my_lang), see http://www.template-toolkit.org/docs/manual/VMethods.html#method_replace > 2. set suitable language code into template variables, and use [% > Param('docs_urlbase') FILTER html %]/[% language %]/html for docbase. This won't work if the path is not of the form bla/%lang%/html I would go with option 1.
Assignee | ||
Comment 67•17 years ago
|
||
updated as comment #66, for 'my_lang = sub' part in the Bugzilla::Template, i think it might be better to add new method like Bugzilla::Install::Util::template_language() or something, which returns an array of languages. # files and directories in docs/ are needed to be moved, too.
Attachment #301088 -
Attachment is obsolete: true
Attachment #305204 -
Flags: review?(myk)
Attachment #305204 -
Flags: review?(mkanat)
Attachment #305204 -
Flags: review?(LpSolit)
Attachment #301088 -
Flags: review?
![]() |
||
Comment 68•17 years ago
|
||
Having looked at the current patch v6, I think we should restrict it to: 1) Move the doc from docs/xml to docs/en/xml (will be done via CVS). 2) Change makedocs.pl to compile each docs/%lang%/xml directory. The patch about it looks good in v6 (but I didn't test yet). 3) Fix the docs_urlbase parameter to now point to docs/%lang%/html/ by default. This is done in this patch. 4) Implement some magic code which will replace %lang% by the preferred language passed by the browser. In most cases, this will be the same language as the template itself. 5) Rather than fixing 006 and 009 to work per language, we should rather (at least for now) ask them to ignore l10n templates and only check english ones. I think it's much easier to fix. That's all. This should also make the patch a bit smaller I think.
Assignee | ||
Comment 69•17 years ago
|
||
(In reply to comment #68) > Having looked at the current patch v6, I think we should restrict it to: ok. > 4) Implement some magic code which will replace %lang% by the preferred > language passed by the browser. In most cases, this will be the same language > as the template itself. i think this is done in v6. (my_lang code in Bugzilla/Template.pm) of cource?, i hope to add a new method into Bugzilla::Install::Util as comment #67. or, should i add some parameter in global/variables.none.tmpl like terms.lang? > 5) Rather than fixing 006 and 009 to work per language, we should rather (at > least for now) ask them to ignore l10n templates and only check english ones. I > think it's much easier to fix. i think we don't need to consider about 006. 006 checks only perl code file. for 009, to ignore l10n templates (and only to consider the en templates), only i should do is to delete patchse fot t/009 and template/en/009bugwords.none.tmpl > That's all. This should also make the patch a bit smaller I think. 536 => 359 lines.
Attachment #305204 -
Attachment is obsolete: true
Attachment #307038 -
Flags: review?(myk)
Attachment #307038 -
Flags: review?(mkanat)
Attachment #307038 -
Flags: review?(LpSolit)
Attachment #305204 -
Flags: review?(myk)
Attachment #305204 -
Flags: review?(mkanat)
Attachment #305204 -
Flags: review?(LpSolit)
![]() |
||
Comment 70•17 years ago
|
||
Comment on attachment 307038 [details] [diff] [review] patch v7 >Index: Bugzilla/Template.pm >+ # Copied from Bugzilla::Install::Util::template_include_path() >+ 'my_lang' => sub { >+ my @wanted; >+ my $params = Bugzilla->params; >+ if ($params->{only_language}) { Rather than duplicating the code from template_include_path(), you should rather call it (this method is already imported). Moreover, Bugzilla->params->{only_language} doesn't exist. The $params variable defined in template_include_path() has nothing to do with Bugzilla->params.
Attachment #307038 -
Flags: review?(myk)
Attachment #307038 -
Flags: review?(mkanat)
Attachment #307038 -
Flags: review?(LpSolit)
Attachment #307038 -
Flags: review-
Assignee | ||
Comment 71•17 years ago
|
||
(In reply to comment #70) > >Index: Bugzilla/Template.pm > > >+ # Copied from Bugzilla::Install::Util::template_include_path() > >+ 'my_lang' => sub { > >+ my @wanted; > >+ my $params = Bugzilla->params; > >+ if ($params->{only_language}) { > > Rather than duplicating the code from template_include_path(), you should > rather call it (this method is already imported). Moreover, here, we don't need template include directory path, but only template 'language code'. > Bugzilla->params->{only_language} doesn't exist. The $params variable defined > in template_include_path() has nothing to do with Bugzilla->params. I've missed to read these codes. I've considered the $params (argument $_[0]) in Bugzilla::Install::Util::template_include_path() to be the same as that of global Buzilla->param. :p So, the resolution of this, is to insert the similar code w/o $param releated codes?
![]() |
||
Comment 72•17 years ago
|
||
(In reply to comment #71) > here, we don't need template include directory path, but only template > 'language code'. In this case, refactor the code in Bugzilla::Install::Util and make it a separate (public) method which template_include_path() and makedocs.pl will call.
Assignee | ||
Comment 73•17 years ago
|
||
(In reply to comment #72) > > here, we don't need template include directory path, but only template > > 'language code'. > > In this case, refactor the code in Bugzilla::Install::Util and make it a > separate (public) method which template_include_path() and makedocs.pl will > call. ok. I'll make a new (separate public) method (like template_include_language) and refactor the current template_include_path code into two methods.. like template_include_path calls new method in it.
Assignee | ||
Comment 74•17 years ago
|
||
re-newed patch! with adding Bugzilla::Install::Util::template_include_language.
Attachment #307038 -
Attachment is obsolete: true
Attachment #312574 -
Flags: review?(mkanat)
Attachment #312574 -
Flags: review?(LpSolit)
![]() |
||
Comment 75•17 years ago
|
||
Comment on attachment 312574 [details] [diff] [review] patch v9 >+++ template/en/default/009bugwords.none.tmpl 2008-03-30 16:37:25.000000000 +0900 >+bug=bugs? >+bugzilla=Bugzilla This template has nothing to do here, AFAIK.
Assignee | ||
Comment 76•17 years ago
|
||
(In reply to comment #75) > This template has nothing to do here, AFAIK. ah, yes. i've miss not to copy this file from my old one.. and, i found that patch 9 doesn't have pod for new method in Bugzilla/Install/Util.pm, i'll add one in my next patch. # and where v.8 is :p
![]() |
||
Comment 77•17 years ago
|
||
Comment on attachment 312574 [details] [diff] [review] patch v9 I will summarize what I said on IRC, for the record. >Index: Bugzilla/Template.pm >+ # Copied from Bugzilla::Install::Util::template_include_path() This comment no longer applies. >+ 'my_lang' => sub { >+ require Bugzilla::Install::Util; >+ my @language = Bugzilla::Install::Util::template_include_language(); >+ return $language[0]; >+ }, Two things: - import template_include_language() so that you don't need to specify the full path to the method. - replace my_lang by docs_urlbase and make it return the already converted path to the doc. This will make the change in templates much easier, see below. >Index: Bugzilla/Install/Util.pm >+sub template_include_language { This method needs POD. >Index: docs/makedocs.pl >+ if (($_ eq '.') || ($_ eq '..') || (! -d $_)) { >+ next; >+ } Nit: you could put all this on a single line: next if (...); >+ if (!-d 'pdf') { >+ unlink 'pdf'; >+ mkdir 'pdf', 0755; >+ } Also create html/ and html/api/ if they are missing. They are part of CVS, but I'm sure most l10n doc tarballs will omit them. This makes me think that html/api/style.css should be moved elsewhere, else each l10n doc would need to include it in their tarball, which is painful. This can be fixed in a separate bug. >Index: template/en/default/admin/params/core.html.tmpl >+ "Leave this empty to suppress links to the documentation." _ >+ "'%lang%' will be replaced into users' langauge.", Should be "'%lang%' will be replaced by user's preferred language (if available)." >Index: template/en/default/pages/release-notes.html.tmpl >- <a href="[% Param('docs_urlbase') FILTER html %]api/">[% terms.Bugzilla %] >+ <a href="[% Param('docs_urlbase').replace('%lang%', my_lang) FILTER html %]api/">[% terms.Bugzilla %] With my change proposed in Template.pm, rather than appending .replace('%lang%', my_lang) everywhere, you can now write [% docs_urlbase FILTER html %], which is much simpler. This is the trick we used for urlbase versus [% Param("urlbase") %]. >+++ template/en/default/009bugwords.none.tmpl 2008-03-30 16:37:25.000000000 +0900 As I said in my previous comment, this template must go away. Else your patch looks good and works great. Next one should be the final one. ;)
Attachment #312574 -
Flags: review?(mkanat)
Attachment #312574 -
Flags: review?(LpSolit)
Attachment #312574 -
Flags: review-
Assignee | ||
Comment 78•17 years ago
|
||
updated as comments on irc. (or comment #77)
Attachment #312574 -
Attachment is obsolete: true
Attachment #312920 -
Flags: review?(mkanat)
Attachment #312920 -
Flags: review?(LpSolit)
![]() |
||
Comment 79•17 years ago
|
||
Comment on attachment 312920 [details] [diff] [review] patch v.10 >Index: Bugzilla/Install/Filesystem.pm > 'docs/makedocs.pl' => { perms => $owner_executable }, >+ 'docs/*/rel_notes.txt' => { perms => $ws_readable }, >+ 'docs/*/README.docs' => { perms => $owner_readable }, Having style.css being duplicated in each l10n pack is bad as this is the single file in html/api/ and most packs will omit it for sure. We should move docs/*/html/api/style.css into docs/style.css and let all l10n packs use it. To make it work, you have to add the following entry to the list above: 'docs/style.css' => { perms => $ws_readable }, >Index: docs/makedocs.pl >+ if (!-d 'html') { >+ unlink 'html'; >+ mkdir 'html', '0755'; >+ } >+ if (!-d 'html/api') { >+ unlink 'html/api'; >+ mkdir 'html/api', '0755'; >+ } You MUST NOT enclose 0755 in quotes, which sets permissions incorrectly. 0755 is in octal format, not a string, see: perldoc -f chmod. >+ make_pod() if $pod_simple; You need to fix make_pod() at two distinct places: - First, update add_css() to be $converter->add_css('./../../../style.css'); The initial ./ is mandatory, else the link doesn't work correctly. - Secondly, batch_convert() needs be $converter->batch_convert(['../../'], 'html/api/'); because it has to go one level deeper to find the bugzilla/ directory as we now have an additional %lang%/ directory under docs/. Else our Bugzilla .pm modules won't be found by the script. >Index: template/en/default/global/docslinks.html.tmpl >- <a href="[% Param('docs_urlbase') %] >+ <a href="[% docs_urlbase %] docs_urlbase needs to be HTML-filtered (due to XSS). Running runtests.pl throws this error. >Index: template/en/default/global/per-bug-queries.html.tmpl >- <a href="[% Param('docs_urlbase') %]query.html#individual-buglists">the named tag</a> >+ <a href="[% docs_urlbase %]query.html#individual-buglists">the named tag</a> Same here, add FILTER html to docs_urlbase. You forgot to replace Param("docs_urlbase") by urlbase in global/common-link.html.tmpl at the very bottom of the template: [% Param("docs_urlbase") _ doc_section FILTER html %]. Everything else works fine.
Attachment #312920 -
Flags: review?(mkanat)
Attachment #312920 -
Flags: review?(LpSolit)
Attachment #312920 -
Flags: review-
Assignee | ||
Comment 80•17 years ago
|
||
Should i change the docs_urlbase description in xml/administrator.xml? (In reply to comment #79) > >Index: Bugzilla/Install/Filesystem.pm > > > 'docs/makedocs.pl' => { perms => $owner_executable }, > >+ 'docs/*/rel_notes.txt' => { perms => $ws_readable }, > >+ 'docs/*/README.docs' => { perms => $owner_readable }, > > Having style.css being duplicated in each l10n pack is bad as this is the > single file in html/api/ and most packs will omit it for sure. We should move > docs/*/html/api/style.css into docs/style.css and let all l10n packs use it. To > make it work, you have to add the following entry to the list above: > > 'docs/style.css' => { perms => $ws_readable }, ok. > >Index: docs/makedocs.pl > > >+ if (!-d 'html') { > >+ unlink 'html'; > >+ mkdir 'html', '0755'; > >+ } > >+ if (!-d 'html/api') { > >+ unlink 'html/api'; > >+ mkdir 'html/api', '0755'; > >+ } > > You MUST NOT enclose 0755 in quotes, which sets permissions incorrectly. 0755 > is in octal format, not a string, see: perldoc -f chmod. ah, yeah. i know that.. i wonder why i did so :-( > >+ make_pod() if $pod_simple; > > You need to fix make_pod() at two distinct places: > - First, update add_css() to be $converter->add_css('./../../../style.css'); > The initial ./ is mandatory, else the link doesn't work correctly. > - Secondly, batch_convert() needs be $converter->batch_convert(['../../'], > 'html/api/'); because it has to go one level deeper to find the bugzilla/ > directory as we now have an additional %lang%/ directory under docs/. Else our > Bugzilla .pm modules won't be found by the script. i've fogot this. > >Index: template/en/default/global/docslinks.html.tmpl > >- <a href="[% Param('docs_urlbase') %] > >+ <a href="[% docs_urlbase %] > >Index: template/en/default/global/per-bug-queries.html.tmpl > >- <a href="[% Param('docs_urlbase') %]query.html#individual-buglists">the named tag</a> > >+ <a href="[% docs_urlbase %]query.html#individual-buglists">the named tag</a> For these two, i did this with sed like tool. Should i file them against 3.0 branch? > You forgot to replace Param("docs_urlbase") by urlbase in > global/common-link.html.tmpl at the very bottom of the template: [% > Param("docs_urlbase") _ doc_section FILTER html %]. fixed.
Assignee | ||
Comment 81•17 years ago
|
||
Attachment #312920 -
Attachment is obsolete: true
Attachment #313020 -
Flags: review?(mkanat)
Attachment #313020 -
Flags: review?(LpSolit)
![]() |
||
Comment 82•17 years ago
|
||
Comment on attachment 313020 [details] [diff] [review] patch v.11 >Index: docs/makedocs.pl >- print "\n"; >+ print "+\n"; This change doesn't make sense and should go away. Everything else works fine. This patch is ready for checkin. r=LpSolit Max, do you want to review it too or can we go with checkin?
Attachment #313020 -
Flags: review?(LpSolit) → review+
![]() |
||
Comment 83•17 years ago
|
||
Note: I will do the checkin myself as there are many files to move (and I reviewed many iterations of the patch, so I know what has to move and where).
Keywords: relnote
Whiteboard: [LpSolit will do the checkin. Many files to remove and add to CVS]
Comment 84•17 years ago
|
||
Comment on attachment 313020 [details] [diff] [review] patch v.11 >Index: Bugzilla/Template.pm >+ # Allow templates to access docs url with users' preferred language >+ 'docs_urlbase' => sub { >+ my @language = template_include_language(); Nit: You could also do my ($language) if you wanted. >Index: Bugzilla/Install/Filesystem.pm >+ 'docs/style.css' => { perms => $ws_readable }, >+ 'docs/*/rel_notes.txt' => { perms => $ws_readable }, >+ 'docs/*/README.docs' => { perms => $owner_readable }, Nit: Align the arrows, on checkin. >Index: Bugzilla/Install/Util.pm >+sub template_include_language { Nit: That should probably be include_languages. >@@ -493,7 +499,8 @@ > override a template of the same name and path in F<default>. > > C<$language> is a language code, C<en> being the default language shipped >-with Bugzilla. Localizers ship other languages. >+with Bugzilla. Localizers ship other languages. And C<$language> are from >+C<template_include_language>. I'm not sure what that POD is trying to say. Also, that should be "is" instead of "are". (But even if it was, I wouldn't know what was being said here.) >Index: docs/makedocs.pl >+ $converter->add_css('./../../../style.css'); Nit: That first ./ is unnecessary. >+opendir(LANGS, './'); >+foreach (readdir(LANGS)) { Please add a variable there, don't use $_. Also, it's usually easier to use glob() for this instead of readdir/opendir. Otherwise this all looks fine. I think everything I listed above can be fixed on checkin, although run the POD by me, first, if I'm around.
Attachment #313020 -
Flags: review?(mkanat) → review+
![]() |
||
Comment 85•17 years ago
|
||
(In reply to comment #84) > >+ $converter->add_css('./../../../style.css'); > > Nit: That first ./ is unnecessary. Without ./, the string above was "hardcoded" in each HTML page, which doesn't work for pages in subdirectories. I had to add ./ as above to have the generator to correctly fix the path in subdirectories. So it should not be removed.
Flags: approval+
![]() |
||
Comment 86•17 years ago
|
||
Wow, that was painful. Administration in CVS is really bad! Checking in Bugzilla/Template.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v <-- Template.pm new revision: 1.89; previous revision: 1.88 done Checking in Bugzilla/Config/Core.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Core.pm,v <-- Core.pm new revision: 1.9; previous revision: 1.8 done Checking in Bugzilla/Install/Filesystem.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v <-- Filesystem.pm new revision: 1.28; previous revision: 1.27 done Checking in Bugzilla/Install/Util.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Util.pm,v <-- Util.pm new revision: 1.14; previous revision: 1.13 done Removing docs/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/.cvsignore,v <-- .cvsignore new revision: delete; previous revision: 1.3 done Removing docs/README.docs; /cvsroot/mozilla/webtools/bugzilla/docs/README.docs,v <-- README.docs new revision: delete; previous revision: 1.12 done Checking in docs/makedocs.pl; /cvsroot/mozilla/webtools/bugzilla/docs/makedocs.pl,v <-- makedocs.pl new revision: 1.19; previous revision: 1.18 done Removing docs/rel_notes.txt; /cvsroot/mozilla/webtools/bugzilla/docs/rel_notes.txt,v <-- rel_notes.txt new revision: delete; previous revision: 1.48 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/style.css,v done Checking in docs/style.css; /cvsroot/mozilla/webtools/bugzilla/docs/style.css,v <-- style.css initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/.cvsignore,v done Checking in docs/en/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/en/.cvsignore,v <-- .cvsignore initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/README.docs,v done Checking in docs/en/README.docs; /cvsroot/mozilla/webtools/bugzilla/docs/en/README.docs,v <-- README.docs initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/rel_notes.txt,v done Checking in docs/en/rel_notes.txt; /cvsroot/mozilla/webtools/bugzilla/docs/en/rel_notes.txt,v <-- rel_notes.txt initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/bzLifecycle.png,v done Checking in docs/en/images/bzLifecycle.png; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/bzLifecycle.png,v <-- bzLifecycle.png initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/bzLifecycle.xml,v done Checking in docs/en/images/bzLifecycle.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/bzLifecycle.xml,v <-- bzLifecycle.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/caution.gif,v done Checking in docs/en/images/caution.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/caution.gif,v <-- caution.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/note.gif,v done Checking in docs/en/images/note.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/note.gif,v <-- note.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/tip.gif,v done Checking in docs/en/images/tip.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/tip.gif,v <-- tip.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/warning.gif,v done Checking in docs/en/images/warning.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/warning.gif,v <-- warning.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/1.gif,v done Checking in docs/en/images/callouts/1.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/1.gif,v <-- 1.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/2.gif,v done Checking in docs/en/images/callouts/2.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/2.gif,v <-- 2.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/3.gif,v done Checking in docs/en/images/callouts/3.gif; /cvsroot/mozilla/webtools/bugzilla/docs/en/images/callouts/3.gif,v <-- 3.gif initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/.cvsignore,v done Checking in docs/en/xml/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/.cvsignore,v <-- .cvsignore initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/Bugzilla-Guide.xml,v done Checking in docs/en/xml/Bugzilla-Guide.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/Bugzilla-Guide.xml,v <-- Bugzilla-Guide.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/about.xml,v done Checking in docs/en/xml/about.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/about.xml,v <-- about.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/administration.xml,v done Checking in docs/en/xml/administration.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/administration.xml,v <-- administration.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/conventions.xml,v done Checking in docs/en/xml/conventions.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/conventions.xml,v <-- conventions.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/customization.xml,v done Checking in docs/en/xml/customization.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/customization.xml,v <-- customization.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/gfdl.xml,v done Checking in docs/en/xml/gfdl.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/gfdl.xml,v <-- gfdl.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/glossary.xml,v done Checking in docs/en/xml/glossary.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/glossary.xml,v <-- glossary.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/index.xml,v done Checking in docs/en/xml/index.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/index.xml,v <-- index.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/installation.xml,v done Checking in docs/en/xml/installation.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/installation.xml,v <-- installation.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/integration.xml,v done Checking in docs/en/xml/integration.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/integration.xml,v <-- integration.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/introduction.xml,v done Checking in docs/en/xml/introduction.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/introduction.xml,v <-- introduction.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/modules.xml,v done Checking in docs/en/xml/modules.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/modules.xml,v <-- modules.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/patches.xml,v done Checking in docs/en/xml/patches.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/patches.xml,v <-- patches.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/requiredsoftware.xml,v done Checking in docs/en/xml/requiredsoftware.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/requiredsoftware.xml,v <-- requiredsoftware.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/security.xml,v done Checking in docs/en/xml/security.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/security.xml,v <-- security.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/troubleshooting.xml,v done Checking in docs/en/xml/troubleshooting.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/troubleshooting.xml,v <-- troubleshooting.xml initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/using.xml,v done Checking in docs/en/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/using.xml,v <-- using.xml initial revision: 1.1 done Removing docs/html/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/html/.cvsignore,v <-- .cvsignore new revision: delete; previous revision: 1.1 done Removing docs/html/api/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/html/api/.cvsignore,v <-- .cvsignore new revision: delete; previous revision: 1.1 done Removing docs/html/api/style.css; /cvsroot/mozilla/webtools/bugzilla/docs/html/api/style.css,v <-- style.css new revision: delete; previous revision: 1.1 done Removing docs/images/bzLifecycle.png; /cvsroot/mozilla/webtools/bugzilla/docs/images/bzLifecycle.png,v <-- bzLifecycle.png new revision: delete; previous revision: 1.4 done Removing docs/images/bzLifecycle.xml; /cvsroot/mozilla/webtools/bugzilla/docs/images/bzLifecycle.xml,v <-- bzLifecycle.xml new revision: delete; previous revision: 1.3 done Removing docs/images/caution.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/caution.gif,v <-- caution.gif new revision: delete; previous revision: 1.2 done Removing docs/images/note.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/note.gif,v <-- note.gif new revision: delete; previous revision: 1.1 done Removing docs/images/tip.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/tip.gif,v <-- tip.gif new revision: delete; previous revision: 1.2 done Removing docs/images/warning.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/warning.gif,v <-- warning.gif new revision: delete; previous revision: 1.2 done Removing docs/images/callouts/1.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/callouts/1.gif,v <-- 1.gif new revision: delete; previous revision: 1.1 done Removing docs/images/callouts/2.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/callouts/2.gif,v <-- 2.gif new revision: delete; previous revision: 1.1 done Removing docs/images/callouts/3.gif; /cvsroot/mozilla/webtools/bugzilla/docs/images/callouts/3.gif,v <-- 3.gif new revision: delete; previous revision: 1.1 done Removing docs/xml/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/xml/.cvsignore,v <-- .cvsignore new revision: delete; previous revision: 1.1 done Removing docs/xml/Bugzilla-Guide.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/Bugzilla-Guide.xml,v <-- Bugzilla-Guide.xml new revision: delete; previous revision: 1.77 done Removing docs/xml/about.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/about.xml,v <-- about.xml new revision: delete; previous revision: 1.26 done Removing docs/xml/administration.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v <-- administration.xml new revision: delete; previous revision: 1.89 done Removing docs/xml/conventions.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/conventions.xml,v <-- conventions.xml new revision: delete; previous revision: 1.12 done Removing docs/xml/customization.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/customization.xml,v <-- customization.xml new revision: delete; previous revision: 1.43 done Removing docs/xml/gfdl.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/gfdl.xml,v <-- gfdl.xml new revision: delete; previous revision: 1.11 done Removing docs/xml/glossary.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/glossary.xml,v <-- glossary.xml new revision: delete; previous revision: 1.25 done Removing docs/xml/index.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/index.xml,v <-- index.xml new revision: delete; previous revision: 1.6 done Removing docs/xml/installation.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/installation.xml,v <-- installation.xml new revision: delete; previous revision: 1.155 done Removing docs/xml/integration.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/integration.xml,v <-- integration.xml new revision: delete; previous revision: 1.14 done Removing docs/xml/introduction.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/introduction.xml,v <-- introduction.xml new revision: delete; previous revision: 1.6 done Removing docs/xml/modules.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/modules.xml,v <-- modules.xml new revision: delete; previous revision: 1.13 done Removing docs/xml/patches.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/patches.xml,v <-- patches.xml new revision: delete; previous revision: 1.25 done Removing docs/xml/requiredsoftware.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/requiredsoftware.xml,v <-- requiredsoftware.xml new revision: delete; previous revision: 1.7 done Removing docs/xml/security.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/security.xml,v <-- security.xml new revision: delete; previous revision: 1.18 done Removing docs/xml/troubleshooting.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/troubleshooting.xml,v <-- troubleshooting.xml new revision: delete; previous revision: 1.13 done Removing docs/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml new revision: delete; previous revision: 1.79 done Checking in template/en/default/index.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v <-- index.html.tmpl new revision: 1.40; previous revision: 1.39 done Checking in template/en/default/admin/params/core.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/core.html.tmpl,v <-- core.html.tmpl new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/global/common-links.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/common-links.html.tmpl,v <-- common-links.html.tmpl new revision: 1.14; previous revision: 1.13 done Checking in template/en/default/global/docslinks.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/docslinks.html.tmpl,v <-- docslinks.html.tmpl new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/global/per-bug-queries.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/per-bug-queries.html.tmpl,v <-- per-bug-queries.html.tmpl new revision: 1.13; previous revision: 1.12 done Checking in template/en/default/pages/release-notes.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/release-notes.html.tmpl,v <-- release-notes.html.tmpl new revision: 1.15; previous revision: 1.14 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [LpSolit will do the checkin. Many files to remove and add to CVS]
Comment 87•17 years ago
|
||
So basically, I'm restoring a backup of the mozilla/webtools/bugzilla directory on the CVS server from last night. This check-in basically hosed all of our CVS history and we're going to have to do it over the correct way. The files touched by the check-in for bug 410902 (the only other commit since the last backup was made) do not overlap, so I'll probably be able to successfully make a selective backup restore that only backs out this commit. Some advance warning of this to the developers@ mailing list would have been really useful.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 88•17 years ago
|
||
And to head off the comments that I already saw on IRC, yes, this was talked about in meetings, but *a LONG time ago*. A heads-up warning that it was actually getting implemented and how it was going to be done a day or two ahead of time would have been really useful as a reminder. We all agreed a while back on doing it, that's not in question. The method by which it got done is what's in question, which we would have been able to discuss and have it correct the first time with said communication.
Reporter | ||
Comment 89•17 years ago
|
||
Anybody going to summarize what was happened, to post on developers@ and/or discuss on next meeting? I am about sensemaking, not CVS.
Comment 90•17 years ago
|
||
16:00:52 <@mkanat> SnowyOwl: I wouldn't say it's that much of a problem, this is the first time it's happened in my memory. 16:02:52 <@justdave> yeah, same here. 16:03:04 <@justdave> this is the only time I know of that this kind of thing has happened. 16:03:17 <@justdave> so I'm quite willing to chalk it up as a "we'll know better next time" :) Basic summary: we've got a procedure at Mozilla for moving files in CVS which preserves their history. CVS itself doesn't support it, so it's scripts we run on the server end to make it happen. Frédéric didn't know about it, and because people who did didn't find out about it ahead of time, it got done with the old cvs remove/add tricks which lost all the history. Here's my plan: I have a backup restore of mozilla/webtools/bugzilla in progress now, to a temporary directory outside of the tree. I'm going to run the cvs copy script on the current contents of docs to move it all to docs/en *in the temp directory with the restored backup*. I'm then going to rsync the docs/en from the restored backup into docs/en in the production tree. This should avoid having to redo all the rest of the commits, and preserve the existing dead state on the old file locations.
![]() |
||
Comment 91•17 years ago
|
||
justdave: I hope you realized that at least one .cvsignore has changed, so that you don't overwrite changes I did while *coying* files.
Comment 92•17 years ago
|
||
CVS copies of the backed up files have been completed, see bug 426944 for all the gory details. Any changes you made to the files during commit when you moved them *have* been lost. That's part of the cvs copy, the files are copied exactly as they were on the trunk to the new location. You'll need to make those changes again and commit them at the new location now that the history has been restored. I did manage to leave all of the other modified files intact, and only replaced the newly-created files. The deleted files also remained deleted.
![]() |
||
Comment 93•17 years ago
|
||
I relanded docs/en/.cvsignore which was the only file being moved *and* modified. The CVS copy reverted changes made to it: Checking in docs/en/.cvsignore; /cvsroot/mozilla/webtools/bugzilla/docs/en/.cvsignore,v <-- .cvsignore new revision: 1.4; previous revision: 1.3 done
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment 94•17 years ago
|
||
Just FYI, this change broke the docs build stuff on the website. I filed bug 436424 for that.
Comment 95•16 years ago
|
||
Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.
Keywords: relnote
You need to log in
before you can comment on or make changes to this bug.
Description
•