Re: [gentoo-dev] GLEP #10 -- Proposal for restructuring the CVS regarding documentation wrt internationalization proposal

[Sven Vermeulen]

On Tue, Aug 12, 2003 at 08:45:17AM -0400, Kurt Lieber wrote:
> 2) One thing that isn't clear in the GLEP.  Is
> http://www.gentoo.org/${LANGUAGE} an *exact* copy of
> http://www.gentoo.org/en/?  Or are the internationalization teams allowed
> to change things?  For the most part, I would like to ensure that we have
> one, consistent web site, so I'd like to see translations happening, but
> not alternate content per se.

I was hoping not to translate the site, but have the
http://www.gentoo.org/${LANGUAGE} be something like this:
	http://dev.gentoo.org/~swift/international.html

It provides the user with:
	- translated documentation
	- a listing of community sites in that language
	- language-specific newsitems:
		* new translations (both doc or GWN)
		* new community site
		* perhaps translated news items from www.gentoo.org

> You touch a bit upon this in the "Internationalized Website" but I'm still
> not clear on how it works, so some clarification would be appreciated.

Personally I don't believe in translating a site, although I've left the
possibility open since there are probably people who do like to see
www.gentoo.org translated. 
 
> 3) Regarding permissions, I don't really like the idea of the entire docs
> team having commit access to /en/main/.  I realize that's the case now
> because of where docs.xml resides, but if we're going to restructure things
> then I'd like to change that.  Ideally, I would like members of cvsdoc to
> have commit access to /en/docs/ and the cvsweb group to have commit access
> to /en/main/.  cvswebdoc is a nasty hack of a solution created because of
> our current structure.  I'd like to see it killed off as part of this
> restructure.

Fine by me. The stricter the permissions, the better. 

You can also seperate the main website from the "translated" websites. Have
the main website in [gentoo]/xml/htdocs/main, while all the rest resides in
[gentoo]/xml/htdocs/${LANGUAGE}/main (with ${LANGUAGE} including "en").

With this, the cvsweb group has commit access to the main website, while the
cvsdocen has to the english, cvsdocnl to the dutch, cvsdocfr to the french
etc...

So, more schematic:

* http://www.gentoo.org
	- Main website
	- CVS: [gentoo]/xml/htdocs/main and subdirectories
	- CVS-commit: "cvsweb" group

* http://www.gentoo.org/en    ( == http://en.gentoo.org)
	- English documentation / communities website
	- CVS: [gentoo]/xml/htdocs/en/ and subdirectories
	- CVS-commit: "cvsdocen" group

* http://www.gentoo.org/fr    ( == http://fr.gentoo.org)
	- French documentation / communities website
	- CVS: [gentoo]/xml/htdocs/fr and subdirectories
	- CVS-commot: "cvsdocfr" group

etc.

As FRLinux pointed out somewhere, a strict policy on how the
http://${LANGUAGE}.gentoo.org website looks like, and what comes on it is
probably needed.
 
> 4) How do /en/proj/* pages get translated?

By the translationteams, who have access to
	${LANGUAGE}/
so can translate
	${LANGUAGE}/proj/*
 
> 5) One significant problem we have with the GWN is translation teams not
> keeping things up to date.  This may be outside of the scope of this GLEP,
> but I'd sure like to see a defined policy that states what is expected of
> the translation teams and at what point a language will be "killed off"
> from the web site for falling behind.  We *do not* want to have
> /<language>/doc/gentoo-x86-install.xml handing out the wrong information.
> If we can't keep a language up to date, it should be removed entirely imo.

Agreed. However, this is related to the GDP policy itself (for documentation)
and indeed not related to this GLEP. Sergey and I will make sure that
translations do not fall behind, and that they are removed from the website
if they do.

I'm not speaking in behalf of the GWN though, it's not really my domain.
 
> 6) Backwards compatibility needs to be maintained.  Think of all the
> external links to http://www.gentoo.org/doc/en/gentoo-x86-install.xml on
> other sites.  We can't simply cause all of them to break.  We can do some
> fancy footwork with mod_rewrite to facilitate this, but the GLEP needs to
> be updated to reflect the fact that we *will* make a best effort to
> maintain backwards compatibility.

One way to do so is to have a /doc with symlinks all over the place. Since
there is no /doc in the proposal, no precautions have to be taken. Except
ofcourse allowing the webserver to follow symlinks.

Wkr,
	Sven Vermeulen

-- 
    Save some animals, eat a vegetarian.