Vitaly Fedrushkov Reporter
	Description • 22 years ago

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:

	Tobias Burnus
	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 &uuml; 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)

	Bradley Baetz (:bbaetz)
	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.

	Tobias Burnus
	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"

	Vitaly Fedrushkov 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.

	Vitaly Fedrushkov 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 :-)

	Vitaly Fedrushkov 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.

	Dave Miller [:justdave]
	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...

	Vitaly Fedrushkov 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.

	Jacob Steenhagen
	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.

	Dave Miller [:justdave]
	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.

	Dave Miller [:justdave]
	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.

	Dave Miller [:justdave]
	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.

	Kalin Kozhuharov
	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?

	Marc Schumann [:Wurblzap]
	Comment 14 • 19 years ago

For the record... Gradual translation, defaulting to en, is already possible if
you keep defaultlanguage at en.

	Frédéric Buclin
	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.

	Frédéric Buclin
	Comment 16 • 17 years ago

Max, would you block 3.2 on it?

	Max Kanat-Alexander
	Comment 17 • 17 years ago

No, it's not a blocker, but it's simple enough that it could and should be done anyway.

	Frédéric Buclin
	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. :-/

	Max Kanat-Alexander
	Comment 19 • 17 years ago

Any reason himorin couldn't work on it?

	Vitaly Fedrushkov 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?

	A. Shimono [:himorin] 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>.

	Vitaly Fedrushkov 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

	Vitaly Fedrushkov 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.

	A. Shimono [:himorin] 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...

	Frédéric Buclin
	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.

	Frédéric Buclin
	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>.

	Vitaly Fedrushkov 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'.

	A. Shimono [:himorin] 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.

	Marc Schumann [:Wurblzap]
	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.

	Max Kanat-Alexander
	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.)

	Vitaly Fedrushkov 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 ;-)

	A. Shimono [:himorin] 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.

	Cédric Corazza
	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.

	Frédéric Buclin
	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.

	Max Kanat-Alexander
	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".

	Vitaly Fedrushkov 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.

	Frédéric Buclin
	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.

	Max Kanat-Alexander
	Comment 38 • 17 years ago

What LpSolit is saying is that the parameters were removed before the discussion that generated Bugzilla:Params.

	A. Shimono [:himorin] 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.)

	Marc Schumann [:Wurblzap]
	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.

	A. Shimono [:himorin] 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.

	A. Shimono [:himorin] 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)

	Marc Schumann [:Wurblzap]
	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.)

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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.

	Frédéric Buclin
	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.

	Max Kanat-Alexander
	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.)

	Max Kanat-Alexander
	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.

	A. Shimono [:himorin] Assignee
	Comment 50 • 17 years ago

patch rev.2

	Max Kanat-Alexander
	Comment 51 • 17 years ago

Comment on attachment 297547 [details] [diff] [review]
patch v.2

Please attach a "cvs diff -u".

	A. Shimono [:himorin] 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.

	A. Shimono [:himorin] Assignee
	Comment 53 • 17 years ago

w/ -u.

	A. Shimono [:himorin] 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>

	Max Kanat-Alexander
	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.

	A. Shimono [:himorin] Assignee
	Comment 56 • 17 years ago

includes patch for Filesystem.pm and some templates.

	A. Shimono [:himorin] 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.

	A. Shimono [:himorin] 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

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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...

	Max Kanat-Alexander
	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().

	A. Shimono [:himorin] 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).

	A. Shimono [:himorin] Assignee
	Comment 63 • 17 years ago

fixed docs/makedocs.pl as comment #59

	Frédéric Buclin
	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/.

	A. Shimono [:himorin] 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.

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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.

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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.

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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?

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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.

	A. Shimono [:himorin] Assignee
	Comment 74 • 17 years ago

re-newed patch!
with adding Bugzilla::Install::Util::template_include_language.

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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

	Frédéric Buclin
	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. ;)

	A. Shimono [:himorin] Assignee
	Comment 78 • 17 years ago

updated as comments on irc. (or comment #77)

	Frédéric Buclin
	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.

	A. Shimono [:himorin] 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.

	Frédéric Buclin
	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?

	Frédéric Buclin
	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).

	Max Kanat-Alexander
	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.

	Frédéric Buclin
	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.

	Frédéric Buclin
	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

	Dave Miller [:justdave]
	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.

	Dave Miller [:justdave]
	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.

	Vitaly Fedrushkov 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.

	Dave Miller [:justdave]
	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.

	Frédéric Buclin
	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.

	Dave Miller [:justdave]
	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.

	Frédéric Buclin
	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

	Dave Miller [:justdave]
	Comment 94 • 16 years ago

Just FYI, this change broke the docs build stuff on the website.  I filed bug 436424 for that.

	Max Kanat-Alexander
	Comment 95 • 16 years ago

Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.