httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yoshiki Hayashi <>
Subject Re: Web site translation
Date Mon, 29 Nov 2004 09:49:19 GMT
André Malo <> writes:

> * Justin Erenkrantz wrote:
>> --On Monday, November 29, 2004 11:44 AM +0900 Yoshiki Hayashi
>> <> wrote:
>> > More than a year after I proposed web site translation, I
>> > finally sat down for a while and did necessary coding to add
>> > translation support.
>> BTW, this might need to be discussed on dev@httpd as well.  This is going
>> to affect all developers who touch the site.
> In fact, I wanted to wait until we have the new layout and a better build 
> system (with xslt). We also need to think about the paths of the 
> translation in conclusion with the docs etc.

I didn't know you were going to replace the build system.
All I knew was CSS work and it doesn't conflict with my
change because layout is only handled by site.vsl which I
didn't really change much.

Could you elaborate on your new build system?  I've never
heard of it before.  I'd rather stick with current system
than going XSLT (I hate XSLT as a language).  If we change
the build system at all, I think it's better to consider
using projects like forrest than creating yet another
documentation system.

>> >   Does anyone object to the direction we are going? i.e.,
>> >   having translation of web site at all?
>> No, not really.  However, I'm concerned about how long the translations
>> could stay out of sync.  There's going to be times when we try to post an
>> urgent notice and if the translator is asleep (or AWOL for a few weeks),
>> then that's troublesome.  One idea: perhaps when we change the English
>> version of a page, we pull all translations until the individual
>> translation is sync'd up?
> That could be done similar to the docs. Either a note on the top or just 
> dropping outdated translation (perhaps a combination).

That's exactly what I had in mind.

>> >   Now that we have true version control software, I think
>> >   the way to go is to create a branch like Paul did.
>> >   I'm going to create
>> >
>> >   unless someone objects.
>> >   Is there any policy on how to create and use branch?
>> That's fine, I guess.  However, if we have two branches going: one for
>> css deployment and translation, that could end up being nasty to merge
>> back together....
> One of the reasons I would wait.

As I said above, my work doesn't conflict with CSS work.
Translation focuses on contents whereas CSS does on layout.
Thanks to Velocity, those two are mostly separated.

I also don't intent to start translation on the branch.  It
should wait after the build system is moved to main branch
and it can even wait until the CSS change goes to the trunk.
It's main purpose is to give people time to look at the
build system and raise concerns and/or brush up the build

Justin Erenkrantz <> writes:

>>   I extended Anakia to do some new things like providing
>>   context to get available languages and getting the
>>   destination filename.  I'd like to put the source code
>>   somewhere in Subversion repository.  Where shoud I put it?
>> looks like a
>>   good candidate to me.
> First, you should post the source code changes either to here or dev@httpd so 
> that we can review it.  I'm not sure what exactly you changed.  Did you change 
> Velocity?  Or, just the Velocity templates that we used?  -- justin

It's both.  I extended AnakiaTask to contain additional
contexts to make some of the operation required by
translation possible.  What I have done is to add mapper
support to map *.xml to *.html.en and *.xml.ja to
*.html.ja.euc-jp etc. and add new context $language to get
list of available translations for a given file.  I also
modified template to include "Available Language:" thingy at
the bottom of the page (you can see it at and
added a template and a build rule to generate typemap.

I attach the patches.  The build system change is also in my
copied working copy at
You need jars in there to actually try it out.

View raw message