How out of date is misc/rewriteguide.xml?

[Yoshiki Hayashi]

I started translating some stuff under misc and I noticed
it's way out of date.  For example, there's Moved
DocumentRoot example in
http://httpd.apache.org/docs-2.1/misc/rewriteguide.html.en#ToC2

The example configuration is

RewriteEngine on
RewriteRule   ^/$  /e/www/  [R]

and it even goes to say it cannot be done by mod_alias
because all mod_alias con do is prefix matching.  But
mod_alias can do more than mere prefix matching and even
with my limited mod_rewrite and mod_alias knowledge, I know
it is equivalent to

RedirectMatch ^/$ /e/www/

After glancing through the whole document, I'm ++1 to Rich's
idea to write our rewrite cookbook (actually, I prefer more
general url mapping cookbook.  mod_alias is powerful enough
unless you really need to use black magic).

In the meantime, I'm tempted to rip things that can also be
handled by mod_alias off of rewriteguide and use it as seeds
to populate urlmappingguide or whatever the new name of that
document.  I'm not very comfortable that we are knowingly
recommending the use of mod_rewrite where mod_alias is
sufficient.  Opinions?

I also want to clean up the rewriteguide docs further at
later time, but I want to start small and finish one thing
at a time.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web site translation

[Yoshiki Hayashi]

Astrid Keßler [EMAIL PROTECTED] writes:

   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
   https://svn.apache.org/repos/asf/httpd/site/branches/translation
   unless someone objects.
   Is there any policy on how to create and use branch?

 Hm, please, don't use branches. This would differ completely from the
 way we do translation at our documentation. 

Please see my other mail.  It's for the improvement of build
system, not for the actual translation work.

 Let's use the same structure
 - and as well the same build system. I would prefer a general xslt based
 build system. It is really flexible and most of the work has already
 been done.

I already stated my opinion so I don't reiterate myself
here.  But I do object to the tone of argument from XSLT
camp.  My work is just an evolution along the current web
site framework.  The developers see no change in how they
work except maybe longer build time due to the additional
transformation of the translation of modified files to
include out of date notice.

On the other hand, adopting documentation system used by
manual for web is a big change, especially for those who
have only worked with web site docs and not manual docs.  If
there will be a consensus to move to it, that'd be great.
But XSLT people have to sell the idea to developers.  It's
not an already set course we decided long time ago.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Web site translation

[Yoshiki Hayashi]

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.

The demo is available at http://www.apache.org/~yoshiki/httpd-site/
Note that only index.html at top level is translated into
Japanese.  Also note that links at the left side menu are
broken because of the way transformation is done.  You can
type in the relative portion of some of the URLs there.

Now my questions are:

  Does anyone object to the direction we are going? i.e.,
  having translation of web site at all?

  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
  https://svn.apache.org/repos/asf/httpd/site/branches/translation
  unless someone objects.
  Is there any policy on how to create and use branch?

  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?
  https://svn.apache.org/repos/asf/httpd/site-build looks like a
  good candidate to me.

The modifed httpd-site can be found at
cvs.apache.org:~yoshiki/httpd-site for now if you are
interested.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web site translation

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 * Justin Erenkrantz wrote:

 --On Monday, November 29, 2004 11:44 AM +0900 Yoshiki Hayashi

 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
https://svn.apache.org/repos/asf/httpd/site/branches/translation
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
system.

Justin Erenkrantz [EMAIL PROTECTED] 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?
   https://svn.apache.org/repos/asf/httpd/site-build looks like a
   good candidate to me.

 First, you should post the source code changes either to here or [EMAIL 
 PROTECTED] 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
http://www.apache.org/~yoshiki/httpd-site/index.html) 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 cvs.apache.org:~yoshiki/httpd-site.
You need jars in there to actually try it out.

--- AnakiaTask.java 2004-11-29 18:46:35.0 +0900
+++ HttpdSiteDoc.java   2004-11-29 09:30:12.0 +0900
@@ -1,4 +1,4 @@
-package org.apache.velocity.anakia;
+package org.apache.httpd.docs;
 
 /*
  * Copyright 2001-2004 The Apache Software Foundation.
@@ -28,6 +28,8 @@
 import org.apache.tools.ant.DirectoryScanner;
 import org.apache.tools.ant.Project;
 import org.apache.tools.ant.taskdefs.MatchingTask;
+import org.apache.tools.ant.types.Mapper;
+import org.apache.tools.ant.util.FileNameMapper;
 
 import org.xml.sax.SAXParseException;
 
@@ -42,6 +44,12 @@
 import org.apache.velocity.util.StringUtils;
 
 import org.apache.velocity.VelocityContext;
+import org.apache.velocity.anakia.AnakiaJDOMFactory;
+import org.apache.velocity.anakia.OutputWrapper;
+import org.apache.velocity.anakia.TreeWalker;
+import org.apache.velocity.anakia.XPathTool;
+import org.apache.velocity.anakia.Escape

Re: svn commit: r106229 - /httpd/site/branches/css-test

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 * Yoshiki Hayashi [EMAIL PROTECTED] wrote:

 ++1.  I'm ready to help, too.  I was playing with web site
 documentation to start providing translation of those pages
 and wondered why we haven't moved to CSS yet.

 Just wanted to let you know: I've talked to the guy, who made a lot of base
 design work for the docs layout (Gernot Winkler) and asked him, if he 
 could do some outlines for the website, too. If this is ok for you -- he'd
 start working on it mid/late december.

I'm no way in a rush so I don't have problem with that.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: elements glossary and phonetic

[Yoshiki Hayashi]

Hiroaki KAWAI [EMAIL PROTECTED] writes:

 Anothoer point that came up to my mind is, how far should we translate 
 the glossary index words. Refering the example, phonetic elements are 
 to help only the words that are not familiar with newbie. This is 
 reasonable. The point is, the indexes are localized ones. 

Well, the intent of kess was pretty clear to me but you
probably need a little bit of German knowledge to understand
it.  If you look at kess's example, the only place phonetic
elements are uesd are English word in German which is
pronounced as English word.  I don't think those will be
added to English documents although I don't object if
someone did.  In German, getting the pronunciation of words
are straightforward because they follow the simple rule.
But some exceptions are made for words imported from
English, e.g. Baseball, which are pronounced like English
words and do not follow the pronunciation rule.  So I
believe kess wanted to clarify when technical terms are
pronounced as English in German to avoid confusion of how to
pronounce the words correctly.  (I feel a little bit odd
that I, Japanese, is explaining German to another Japanese
in English on mailing list where lots of German people are
reading. :-)

 So, if we, Japanese staff, translate this glossary page into 
 Japanese, how should we treat the phonetic elements?
 I think we should use 'katakana' for translated Japanese words, 
 phonetic symbols for English words that still does not have a 
 corresponding translations. Any ideas, yoshiki?

I don't think we need phonetic elements in Japanese
translation at all so we just drop it if those are there.
It's almost always pretty clear how to pronounce Japanese
words.  In cases where we use English words as is in
Japanese, we can use IPA phonetic elements just like German
does.  We can also leave it without phonetic symbols because
similar pronunciation confusion is very unlikely in
Japanese.  We can do whatever we want but I just don't see
there will be any problem with phonetic elements.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r106229 - /httpd/site/branches/css-test

[Yoshiki Hayashi]

Paul Querna [EMAIL PROTECTED] writes:

Author: pquerna
Date: Mon Nov 22 14:55:35 2004
New Revision: 106229

Added:
   httpd/site/branches/css-test/
  - copied from r106228, httpd/site/trunk/
Log:
create a copy of the trunk to test out a CSS based website.
 
 
 FWIW: I'd really like something based on what the docs are built on
 (semantically and syntactically valid xhtml strict, valid CSS and perhaps the
 build system [which is in stage of being rebuilt currently ;-)]).

 ++1, I want that too!

 And I'm ready to help.

 Sweet.

 I decided to start small and try out using CSS instead of the hard coded 
 colors.

++1.  I'm ready to help, too.  I was playing with web site
documentation to start providing translation of those pages
and wondered why we haven't moved to CSS yet.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: translation versioning in 2.1 is working again.

[Yoshiki Hayashi]

Astrid Keßler [EMAIL PROTECTED] writes:

 * André Malo [EMAIL PROTECTED] wrote:

 the 2.1 tree (together with the latest build tools) now recognizes the
 svn revision number references properly (or should, at least). I'm going to
 convert the 2.0 branch tomorrow.

 Done.

 Nice work. Thank you very much :)

Yes, thanks a lot, Andre.  I need to buy you some beer if I
can make it to Stuttgart next year. :-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: elements glossary and phonetic

[Yoshiki Hayashi]

Astrid Keßler [EMAIL PROTECTED] writes:

 together with the German translation of the glossary, I want to add two
 new xml-elements to our docs:

   glossary for references to an anchor in the glossary file
   phonetic for phonetic annotations (using the IPA standard)

 See glossary.html.de and glossary.xml.de at http://www.apache.org/~kess/
 for an example how to use them and how the transformation could look.

+1

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Translation status page

[Yoshiki Hayashi]

I wrote small python scripts to gererate some HTML pages to
list Japanese translation status and have been using it at:
http://cvs.apache.jp/~yoshiki/httpd-docs/
(follow the last link for 2.1 because it's more interesting
than other versions.)

My current pet project is to write tools and improve
infrastructure to make translation easier.  So I thought I'd
ping this list if anyone else has interest in having the
similar list generated for language he/she is working on.  I
need to do a little bit of refactoring to supprot multiple
languages but it's not too hard to get the pages generated
for other languages.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Docs for programs (dbmmanage)

[Yoshiki Hayashi]

Rich Bowen [EMAIL PROTECTED] writes:

 Is it generally frowned upon to modify the xml documentation for a
 program, like dbmmanage? There are some changes that I'd like to make to
 it, like putting useful working examples in there, but I wasn't sure if
 I was supposed to do that in the XML or if I have to actually go edit
 icky troff somewhere.

I thought the XML documentation *is* the one we modify.
I've never touched those documents but just run build.sh
afterwards and it should take care of regenerating man page.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about translation

[Yoshiki Hayashi]

At Thu, 28 Oct 2004 15:06:47 +0700,
muhammad panji wrote:

   I also have a plan translating the manual into Indonesian
   Language(Bahasa Indonesia). are there just CVS that I could use?
  
  Hmm, this depends on what you want to do and how you want to work... A
  regular tarball/zip package may be sufficient to begin with a new
  translation and there's also the possibility to use rsync to keep your
  local source tree up to date if you can't use CVS.
 Where to get the tarball? I have an apache 2.0 docs on my computer. If
 I'm not false there are xml files for each files. could I start from
 it?

Yes, you can, but there is a chance that those files are already
updated in the CVS and you have to update translation later.  You can
check out files using anonymous CVS.  I suggest you read the tutorial
Erik mentioned first.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some translations

[Yoshiki Hayashi]

At Mon, 13 Sep 2004 09:05:01 +0400,
Sokolov Nikolay wrote:

 Can anyone explain me, how I should translate documents into non-English 
 language? I would like to translate some documents from 2.0 branch into 
 Russian language.

Have you read http://httpd.apache.org/docs-project/, especially
http://httpd.apache.org/docs-project/translations.html?

For Russsian translation, contactin Ilia would be a good start.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs.apache.or.jp to cvs.apache.jp

[Yoshiki Hayashi]

At Mon, 13 Sep 2004 22:54:38 +1000,
Jason Lingohr wrote:

 On Mon, Sep 13, 2004 at 06:32:24PM +0900, [EMAIL PROTECTED] wrote:
 
  site of japanese translation project moved to cvs.apache.jp
 
 Can anyone confirm this?  If so, I'll commit the patch.

Yes, I can say it is moved.  Basically, it is still the same host
because cvs.apache.or.jp is just redirected to cvs.apache.jp.  That's
why I haven't bothered enough to change it myself but I don't object
to you changing it. :-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New offline formats

[Yoshiki Hayashi]

At Sun, 5 Sep 2004 20:20:48 +0200,
André Malo wrote:

 - *.war (Konqueror web archive), which can be opened directly by Konqueror
 browsers. These files are just tar.gz renamed to .war.

FWIW, I tested httpd-docs-2.0.51.ja.war and it worked fine with
Konqueror 3.3.

+1 to adding those packages.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual urlmapping.xml.ja

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 People have also stated concerns about people deliberately putting garbage 
 in the docs (Free Tibet).  I am not personally concerned about that.

Me neither.  I don't think people will work hard to earn
trust only to pull one time show.

 Well, I sort of thought that there was reviewing going on 
 behind-the-scenes for the stuff you committed.

If you consider myself reviewing my translations sometimes a
couple of months after those are translated, yes, all of
them were reviewed.  If someone reviewed some files
explicitly, they were always mentioned in 'reviewed by'
field.  Others are sort of implicit review.  They stayed up
on Japanese site so I believe people read it.  But since
they don't give us any comments, I don't know for sure they
didn't have anything to say or no people actually read it.

Our CVS server died last month because of pserver hole and I
have been too busy to make the service back up.  Because of
this, a couple of changes by Hiroaki wasn't reviewed but
most of the changes were actually reviewed beforehand.  But
since the change history was gone with the server, I guess
it was difficult for him to know which one was reviewed by
whom.

 I'm not the right person to argue with on this subject, since, as I've 
 said, I'm in favour of relaxed standards.  I also agree that, over the 
 years, we have spent way too much time debating this issue.  But as an 
 issue of oversight, I thought it important not to change our standards 
 under-the-covers.  Now that this issue is out in the open, anyone who 
 objects should speak up.

Well, I'm not really trying to argue with you specifically
but we weren't very strict about enforcing it for regular
contributors and I actually liked it.  So I'm just voicing
my opinion.

 I assume that your proposed standards are something like:

 - All translations from non-committers must be reviewed before being 
 committed.
 - Commit access will not be granted to a translator until we have 
 developed a degree of trust in his or her translations.  (For example, if 
 we post the translated and reviewed docs for a period of time and get no
 objections from our readers, then this would be a reason to trust the 
 translator.)
 - If a translator is given commit access *and* there is at least one other 
 active participant who is fluent in that language (and reads the commit 
 mailing list), then small translations and updates may be committed 
 without prior review.  Translations of new docs should still get reviewed 
 prior to commit.

Yes, this is pretty much what I'm proposing.  I think the
hurdle is still too hard for one time contributor or
non-committer but I can't come up with a good way to make it
easier without having the risk of accepting bad translation.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Japanese transformation is not stable

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 Last few months, I've encountered some bugs of the implementation of 
 iso-2022-jp charset converter of Sun JRE, but the converter will be soon 
 stable I think. 

Well, I have a reason to believe it will never be their top
priority to fix those bugs.

 The second, though not so important reason is, that I'm currently working on
 restructuring the docs to create a better platform for translators which
 includes rewriting the styles and the build tools. I'm using the result diffs
 to check if something went wrong.

It would be nice if you could add a target which takes an
XML file as an argument and transforms only that file.

 Ok. That's reason why I've asked. I've had shift_jis in my mind, since we're
 currently recoding to shift_jis for the CHM files, because the html help
 compiler seems to support only this charset for Japanese. If euc-jp is better
 for the online pages, we should use it.

Japanese Windows defaults to shift_jis.  I don't think any
software beside MUA and web browser support other character
encoding scheme.  I don't know how well Windows supports
UTF-8 nowadays.

 Just to make clear: that this doesn't affect the *source* encoding. Keep it as
 you like.

I thought a little bit about shift_jis's advantage of
directly editable by whatever editor on Windows but soon I
realized it is only for transformed files. ;-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Japanese transformation is not stable

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 Hmm. It still happens, that different JREs (?) produce different iso-2022-jp
 output (i.e. any time someone builds all and diffs, he gets .ja.jis diffs.

Well, at least mine removes bogus escape sequences and
produce more desirable output but yeah, it still happens.

 I'd suggest to switch the transformation finally to shift_jis, which is more
 stable (because there are none of these problematic escape sequences).

I'd rather use euc-jp than shift_jis.  For one thing,
shift_jis is a nightmare for auto detection since almost all
byte sequence can represent a valid character.  If I choose
from three major character encoding scheme in Japan, I
always choose euc-jp.  It doesn't have quirks sjis has.  The
fact that current one uses iso-2022-jp is just from legacy
reasons.

 If we decide to switch the charset then we also need to decide, whether we
 want to move the files in CVS (ja.jis to ja.sjis) or just change to charset
 configuration for the docs directories. I'd prefer the latter. But for
 backwards compat reasons we may need to move the files.

I prefer moving files and add redirection magic to make old
directly pointing URLs to work.  It doesn't look right to
get euc-jp or shift_jis file from .ja.jis ending URL.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual urlmapping.xml.ja

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 I've always leaned towards the more relaxed side of review standards on 
 translations, but our concensus policy has always been to have reviews on 
 anything non-english.

I believe the original intention to have reviews on
translations was to prevent absurd translation to go into
our repository.  IMHO, if one can be trusted enough to be a
committer, he/she can be trusted enough to decide whether
particular translation should go into the repository or
needs review first.

 I'm personally willing to see commit-then-review on small changes, as long 
 as the two of you promise to watch the commits and to inform us if you 
 ever stop watching the commits.

It seems nobody cared about review of Japanese translation
when I was the only committer.  I wonder why is this sudden
interest?  I'm curious because I've never seen the rule
enforced strictly except the translation is the first
submission of someone.  I also thought it *was* mostly for
non-committer patch submission.  The first time additional
reviewer is mentioned in my archive is the reply from Ricard
Oliva to your mail in March 21, 2001.

| 2. I think that we are going to try to make it a policy that we only
| accept non-english patches when we have at least one reviewer in addition
| to the author.  That way we avoid embarrassing stuff like the former Polish
| page and the current Brazilian Portuguese page.  An exception can be made
| in the case of the It worked page, since we certainly want to clean up
| the garbage that is there.  However, in the future, we probably won't
| accept patches this way.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual urlmapping.xml.ja

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 Just a reminder: all translations should include a reviewed by comment 
 in the commit message so that we know that it was properly reviewed.

Can we be a little bit lax about translations especially
when there are more than one committers?  When I was the
only committer of Japanese translation, I made sure all
files are reviewed before committed.  That included my own
translation.  Since nobody helped reviewing my translation,
I usually reviewed my translation after a week or so.  That
process was good to ensure the quality of the translation,
it was also quite a burden.  Sometimes multiple revisions is
made to the English document that means the translated files
will not be committed to the repository for a while.

I believe the changes as small as this are OK to be in CTR
rather than RTC and is actually better that way.
Furthermore, these changes are made to 2.1 branch instead of
2.0.  There's plenty of time for these change to be reviewed
before going into production.  So I hope we can apply CTR to
translation in 2.1 when there are multiple committers to the
language.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: outdate

[Yoshiki Hayashi]

Andr Malo [EMAIL PROTECTED] writes:

 Wouldn't this be better using real xml fields, which we could then
 transform in the docs so that readers of translations would know if they
 were reading the most recent version?

 Well, BTDT.
 Here's a suggestion:

 http://www.apache.org/~nd/manual/ru/new_features_2_0.html

 The message needs to be translated, of course.
 Opinions?

I think it would be nicer if the revision numbers are in it,
like: Original revision: 1.3  Translated revision: 1.1
Many people probably have no clue what revision number means
but it will give you a rough idea of how out of date the
translation is.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shift_Jis for generated japanese output?

[Yoshiki Hayashi]

Andr Malo [EMAIL PROTECTED] writes:

 Not really.  Iso-2022-jp is the most auto-detection friendly
 encoding because of infamous escape sequence but shift_jis
 would be OK, too.  I'm +-0 on conversion at the moment
 because it hasn't caused me much trouble so far.

 Well, then we should stick with it.

 I find it just annoying that the recoding is not stable (i.e. the xalan
 serializer output differs from version to version and depending on other
 things like moon phases or so :).

From my experience, it was Java version that mattered.
After I upgraded to JDK 1.4, I don't have problem with
encoding.  The reason this happens is that iso-2022-jp is a
stateful encoding.  After an escape sequence, following
bytes are interpreted in certain state.  After one escape
sequence, bytes are interpreted as ASCII character and after
another, those are are interpreted as some Japanese
characters.  Because of this, you can have bogus escape
sequences like switching to another state and then
immediately going back to previous state.  There were lots
of these sequences when I was using JDK 1.2.  I'm hoping
this won't happen anymore since all files are re-encoded
with newer JDK.  If this happens again, I would give +1 for
changing the generated files to shift_jis.

 (though... actually I don't know if shift_jis would make the things better)

Yes, shift_jis would make it easier because it's a plain
8bit character encoding scheme.  There is only one way to
encode a character.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Contribution offer: Turkish Translation of Error Documents

[Yoshiki Hayashi]

Emre SOKULLU [EMAIL PROTECTED] writes:

  I would like to help the Apache community in turn by translating Error
 Documents into Turkish or by reviewing other translators' work.
 I have already translated all of them. If you wish, if there were no Turkish
 translation to be reviewed, I can post my works.

Welcome to the project.

Yes, it would be nice to have Turkish translation of error
messages.  However, note that we require one other Turkish
speaker to review your work.  See
http://httpd.apache.org/docs-project/translations.html for
reason why it is required.  The reviewer should post a
message to this list to confirm he or she reviewed the
documents.  I haven't seen any Turkish speaker on this list
so probably you need to ask your friends to do the task.
Thank you for your contribution.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: translation - .pt (error messages)

[Yoshiki Hayashi]

Lopo Pizarro [EMAIL PROTECTED] writes:

 I've added the portuguese .pt to the (error messages), and I'm sending
 the files.

Thanks for the contribution.  As in the Turkish case, we
require another speaker to review your work.
http://httpd.apache.org/docs-project/translations.html

Also, please send them as a patch, not whole files.  For how
to create a patch, see docs project tutorial at
http://apache-server.com/tutorials/ATdocs-project.html

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: french translation

[Yoshiki Hayashi]

Stanislas Renan [EMAIL PROTECTED] writes:

 is there any current project to translate the apache 2.1 documentation
 into french ?
 I cannot find it through a google search, and there is no trace of such
 a translation in the CVS repository.

I don't think there're any ongoing activities on French
translation.  new_feaures_2_0 and upgrading are translated
to French in the repository but those are really old.  Those
aren't even updated to XML.  The log of upgrading.html.fr
says

revision 1.1
date: 2001/02/18 15:50:35;  author: cholet;  state: Exp;
new French translation
PR:
Obtained from:
Submitted by:   Herve Dumont [EMAIL PROTECTED]
Reviewed by:Eric Cholet [EMAIL PROTECTED]

So it's almost 3 years old.  Probably you need to start your
own project for translation.  At least you don't have to
worry too much about reviewers because Eric is a member of
docs project.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Korean translation of Apache 2.0's error pages

[Yoshiki Hayashi]

Lee Heejoon [EMAIL PROTECTED] writes:

 I reviewed Shin's translation.
 I'm confirming it.

Thank you.  I applied the patch to both 2.0 and 2.1.  Please
check the version in CVS and make sure I didn't screw up
anything while applying the patch.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Korean translation of Apache 2.0's error pages

[Yoshiki Hayashi]

Jaeho Shin [EMAIL PROTECTED] writes:

 BTW, when is my patch going to be committed?

It's committed now. :-)
Sorry for the delay.  I was just being lazy during the
vacation.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Korean translation of Apache 2.0's error pages

[Yoshiki Hayashi]

Welcome to the docs project.

Jaeho Shin [EMAIL PROTECTED] writes:

 I'm using a different network now, and can finally send msgs to the
 list. I'm looking for another person to review my patch now. He or she
 will post a message to this list sooner or later.

Jeongho Jeon ([EMAIL PROTECTED]) submitted some patches
about Korean translation a while ago.  Also, Donggyoo
([EMAIL PROTECTED]) submitted Korean translation of
error message in February.  Maybe you can contact them to
see whether they are willing to review your translation?
All I can say about your patch is that Donggyoo's and yours
looks similar (I don't understand Korean but same words
appear in both translation) and I learned server is saba and
gateway is keiduwei in Korean. :-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Website translation project?

[Yoshiki Hayashi]

I've been thinking about the new translation project of
httpd.apache.org website.  Since this is not in the scope of
original docs project, I'd like to ask this list whether it
is the way to go before I invest serious amount of time.

The rationale of this is that website is easier to translate
(less technical and smaller in size compared to manual) is
more visible so it might attract more people to translation
efforts.  The drawback is it might make our scarce resource
even more sparse.  Also, it's a good thing to have
translations of our official site.  I think it's worth a
try.  What do you think?

One concern raised somewhere else (I think it was
community@) about having transalated web site is that
translation might become out of date.  I think it can be
solved by enhancing Anakia or use some other small programs
to check whether document is up to date by comparing CVS
revision of original document and 'English revision' comment
in translation at transformation stage.  If we decide to go
forward with website translation, I'll look into Anakia or
Ant to see how we can solve it.  Anakia has it's own quirks
of handling multilingual text so it has to be solved, too.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Spanish custom error messages in the Apache HTTP Server v6

[Yoshiki Hayashi]

Daniel Lopez [EMAIL PROTECTED] writes:

 The error messages look all look fine to me now.
 I have a few more comments on Readme.es, I will submit that as a separate mail

Thank you Simo and Daniel.  I committed the patch to the CVS
repository.  Please make sure I committed the correct
version.  Let us know if there's any problem.

Is README.es ready to be committed, too?

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

./build.sh metafiles stalls

[Yoshiki Hayashi]

If I run ./build.sh metafiles, the build stalls after
showing:

metafiles:
 [echo] checking metafiles...

But if I run './build.sh -verbose metafiles' to get more
information, build succeeds without a problem.  Does anyone
else experienced the same behavior?

I'm using Java version:

 java -version
java version 1.4.1
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Translation instruction on web page

[Yoshiki Hayashi]

I was reading docs-project web site and found out this:

We also encourage you to place the name of the
translator in a comment at the top of the file

Is this true?  I thought it was not the Apache way to
encourage ownership of a file.

On a related note, I noticed we don't have enough visibility
for non-committer contributors.  Can we add a new page or
enhance participants section at docs home page at
http://httpd.apache.org/docs-project/ to include them?  I'm
thinking mostly about other Japanese contributors but I
think there are lots of others in different language area
like Michael for German.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ja translation new comer

[Yoshiki Hayashi]

Tetsuya Kitahata [EMAIL PROTECTED] writes:
(B
(Bli$BK\%=%U%H%&%'%"$,[EMAIL PROTECTED]&$"[EMAIL PROTECTED]"(B
(B  "Apache" $B5Z$S(B "Apache Software 
(B  Foundation"$B$NL>>N$r!";vA0$NJ8LL$G$N5v2D(B
(B  $B$NL5$$$^$^;HMQ$7$F$O$J$j$^$;$s!#([EMAIL PROTECTED]"Mm$N>e!"(B
(B  [EMAIL PROTECTED]$K$7$F2$5$$!#(B/li
(B 
(B I don't think $B!VAH$_9~$^$l$?!W(B is a good translation of
(B derived.  [EMAIL PROTECTED](B is more common, I think.
(B 
(B The latter sentence can give the feeling that written
(B permission is always granted.  I'd translate it as
(B [EMAIL PROTECTED](B [EMAIL PROTECTED] $B$KO"Mm$7$F$/(B
(B [EMAIL PROTECTED](B
(B
(B Mmmm. Probably, this is just related to my Japanese sense of beauty,
(B I prefer
(B [EMAIL PROTECTED]"Mm$Ne!"[EMAIL PROTECTED]$K$7$F2$5$$!#(B],
(B often used in real business world (and contracts) and rather fluent
(B Japanese phrase.
(B
(BI still think the same as before.  It gives me the
(Bimpression that most of the time written permission is
(Bgiven.  I don't care much about those contracts you
(Bmentioned but I imagine those are used when they are willing
(Bto grant permission.  I read the original English sentence
(Bas "If you ever want to use the name "Apache" or "Apache
(BSoftware Foundation" to promote your products, be sure to
(Bcontact [EMAIL PROTECTED] first.  Depending on the situation
(Bwe might or might not give you the permission."  Your
(BJapanese translation of the last sentence of section 4 is
(Blike, "Contact [EMAIL PROTECTED] and get the written
(Bpermission."  I don't think it has the same connotation.
(B
(B $B!VEj9F!W(Bor$B!V9W8%(B/$B4sM?!W(Bare very difficult to distinguish 
(B when we
(B translate "CONTRIBUTION". The former makes us feel "easiness to
(B contribute" and the latter rather "barriers for contribution".
(B ("Apatchy spirits" taken into consideration, "$BEj9F(B" might be
(B more applicable in Apache Land :-)
(B
(BWe normally use $B!V9W8%!W(B in open source software world.  The
(Bfirst meaning come to my mind when I see the word $B!VEj9F!W(B 
(Bis to submit something like a research paper.  You can
(Bsubmit valuable information but you can also submit rubbish.
(BI don't think you can just send a worthless patch to a
(Bmailing list and claim the contribution.  That's why I think
(Bthe word $B!VEj9F!W(B is not an appropriate word for
(Bcontribution.
(B
(B Also, these sentences are "the most sensitive" part in this
(B license agreement (In other words, if we translate these lines
(B precisely, the other ones could be omitted :-P), so the "easy to read"
(B could be of secondary importance :-)
(B
(BI can't follow you here.  What do you mean by "other ones"?
(BWhat I meant by readability is not about the word but the
(Bsyntax used in those sentences like the one in parentheses.
(BI don't know where you get the idea of my suggesting
(Bimprecise translation.  You can have readable and precise
(Btranslation.  The one thing I don't know is whether it is
(Bpossible in legal documents.
(B
(B I've put "take 2" in this mail, attached, using more legal mode (L-Mode?)
(B of expression :)
(B Maybe, it can be more *fluent* japanese license agreement
(B compared to the translations of Java 2, Standard Edition (J2SE)
(B Specification :)
(B
(BWell, I can say nothing about J2SE license because I haven't
(Bread one.  I won't read Japanese translation of English
(Blicense because most of the time those are poorly
(Btranslated.
(B
(BI glanced through the translation but I won't do detail
(Breview of this one.  I'd like to stay away from legal things
(Bas much as possible.  I cannot find obvious mistakes so I
(Bdon't mind using this as a basis for Japanese translation.
(B
(B-- 
(BYoshiki Hayashi
(B
(B-
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]

Re: need an idea :)

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 # Don't compress images
 SetEnvIfNoCase Request_URI \
 \.(?:gif|jpe?g|png)$ no-gzip dont-vary

 # Make sure proxies don't deliver the wrong content
 Header append Vary User-Agent env=!dont-vary

 The problem is that a lot of people don't read carefully enough and seem to
 assume that dont-vary is a magic variable, recognized by the httpd or the
 like. Any idea how (where?) to clarify that misunderstanding better?

Perhaps changing the varaible name to something that doesn't
look like magic varaible will help?  Say, dont-vary-if-image
or tell-httpd-not-to-compress-if-this-variable-is-set? :-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ja translation new comer

[Yoshiki Hayashi]

Welcome to the project!

Tetsuya Kitahata [EMAIL PROTECTED] writes:

 I wondered how to put the translated jakarta.apache website (pages)
 to apache.org, however, I found that there were still many rooms
 for the contributions to this http-docs projects, especially
 for the httpd-docs-2.0. (Right??)

 # I presumed that there could be no rooms for the contribution
 # ,especially japanese resources! ;-)

Yes, we need more contributions.  Japanese translation
project really needs more help.

Japanese translation is mostly done on Japanese counterpart
of docs mailing list.  You can find the information at
http://cvs.apache.jp/docs-project/
It's actually a bit out of date so if you have any
questions, don't hesitate to ask us.  We don't strictly
follow the procedure described there.

The job most in need is reviewing the translation.  Because
I'm virtually the only person reviewing Japanese translation
done by others, there're a number of translations not yet
committed to apache.org repository.  To tell you the truth,
reviewing is not the very fun thing to do.  There's always
an ego problem so you must be careful not to upset the
original translator.  The only time reviewing becomes easy
is when translation is so good you have nothing to do.  This
is not often the case, though.  Most of the time, I myself
have to rewrite some of my own translation because the first
draft is almost always not good enough.

If you'd rather do new translations, that will be fine,
too.  But don't bark on me if those don't get committed to
apache.org repository in timely manner. :-)

Anyways, welcome to the project.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ja translation new comer

[Yoshiki Hayashi]

I don't know the outcome of license team discussion but I'll
(Bcomment on the translation anyway.  IANAL so there maybe
(Bthose obscure words used by legal documents but I might
(Brephrase them because I can't recognize them.
(B
(BOn the encoding of the translation, starting from example,
(BUS-ASCII characters are changed to JIS X 0201 Roman
(Bcharacters.  Because of that, the document probably isn't a
(Bvalid XML document.  If your text editor does funny things
(Bwith those characters, I suggest you to run nkf -j.
(B
(BTetsuya Kitahata [EMAIL PROTECTED] writes:
(B
(B   p
(B   $B2~JQ$NM-L5$rLd$o$:!"0J2<$NMW7o$,K~$?$5$l$l$P!"%=!<%9%3!<%I7A<0$"$k$$(B
(B   $B$O%P%$%J%j7A<0$G$N:FHRI[5Z$SMxMQ$,5v2D$5$l$^$9!#(B
(B   (J/p(B
(B
(BI'd swap first two clauses to read like $B!V0J2<$NMW7o$,K~$?$5(B
$B$l$l$P!"2~JQ$NM-L5$rLd$o$:!W(B...
(B
(B   (Jol(B
(B   
(B (Jli$B%=!<%9%3!<%I$N:FHRI[$r9T$&>l9g!">e5-$NCx:n8"$K4X$9$kI=5-!?$3$3$G<($5$l$F$$$kMW7o$NI=5-!?0J2<[EMAIL
(B  PROTECTED];v9`$NI=5-$r$=$N$^$^;D$7$F$*$/I,MW$,$"$j$^$9!#(J/li(B
(B
(BI don't know why you use $B!V!?!W(B here.  Why not $B!V$H!W(B or
(Bsimply $B!V!"!W(B?  The same goes for other $B!V!?!W(B.
(B
(B   
(B (Jli$B%P%$%J%j7A<0$G$N:FHRI[$r9T$&>l9g$O!">e5-$NCx:n8"$K4X$9$kI=5-!&$3$3$G<($5$l$F$$$kMW7o$NI=5-!&0J2<[EMAIL
(B  PROTECTED];[EMAIL 
(B PROTECTED]"HRI[J*$KIU?o$9$kJ8=q$*$h$S!J$"$k$$$O!KJL;qNA$KAH$_F~$l$kI,MW$,$"$j$^$9!#(J/li(B
(B
(BThe usage of $B!V!&!W(B looks inconsistent from the above.
(BI may also change the translation of "and/or" part to
$B!VHRI[J*$KIU?o$9$kJ8=q$*$h$SJL;qNA$NN>J}$b$7$/$O$I$l$+$KAH$_(B
$BF~$l$kI,MW$,$"$j$^$9!#!W(B
(B
(B   
(B (Jli$B:FHRI[MQ$N%(%s%I%f!<%6J8=q$,$b$7$"$l$P!"0J2<$Ne5-$NoI=<($5$l$k2U=j$K!"J,$+$k$h$&$KAH$_9~$s$GD:$$$F:9$7;Y$($"$j$^$;$s!#(J/p/li(B
(B
(BThe original paragraph is talking only about the
(Backnowledgement in software itself, not other part of the
(Bproduct.
(B
(BIf I translate it, it would be like
$B!V%(%s%I%f!<%6J8=q$NBe$o$j$K!">e5-$NoI=<($5$l$k2U=j$,$"$l$P!"$=$3$KI=<($5(B
$B$;$k$3$H$b$G$-$^$9!#!W(B
(B
(B   (Jli$BK\%=%U%H%&%'%"$,[EMAIL PROTECTED]&$"[EMAIL 
(B PROTECTED]"(J"Apache"(B $B5Z$S(B (J"Apache(B (JSoftware(B 
(B (JFoundation"$B$NL>>N$r!";vA0$NJ8LL$G$N5v2D$NL5$$$^$^;HMQ$7$F$O$J$j$^$;$s!#([EMAIL
(B  PROTECTED]"Mm$Ne!"[EMAIL PROTECTED]$K$7$F2$5$$!#(J/li(B
(B
(BI don't think $B!VAH$_9~$^$l$?!W(B is a good translation of
(Bderived.  [EMAIL PROTECTED](B is more common, I think.
(B
(BThe latter sentence can give the feeling that written
(Bpermission is always granted.  I'd translate it as
(B[EMAIL PROTECTED](B [EMAIL PROTECTED] $B$KO"Mm$7$F$/(B
(B[EMAIL PROTECTED](B
(B
(B   (Jli$BK\%=%U%H%&%'%"$,[EMAIL PROTECTED]"(JApache(B 
(B (JGroup$B$X$N;vA0$NJ8LL$G$N5v2D$NL5$$>l9g$O!"(JApache"$B$H$$$>>N$=$l<+BN!"$"$k$$$O(J"Apache"$B$H0lIt$KL>A0$,$D$+$J$$$h$&$K$7$F2<$5$$!#(J/li(B
(B
(BThe same goes here for the translation of "derived".
(BI prefer $B!V(BApache Group $B$+$i$N!W(B to $B!V(BApache Group 
$B$X$N!W(B.
(B
(B   
(B (Jnote$BK\%=%U%H%&%'%"$O!"!I$"$j$N$^$^$K!IDs6!$5$l$F$$$^$9$N$G!">\E*!"FCDjL\E*$KAj1~$7$$$+$I$&$+$r4^$a!"L@<(E*$"$k$$$O0E<(E*$JJ]>[EMAIL
(B  PROTECTED]"[EMAIL PROTECTED]"$j$^$;$s!K$r$$$?$7$^$;$s!#(B
(B
(BI'm not sure about the LIMITED TO translation here.  If I
(Bwere you, I'd say:
$B!VK\%=%U%H%&%'%"$O!"!V$=$N$^$^!W$N7A$GDs6!$5$l$F$$$^$9!#>(B
$BL\E*!"FCDjL\E*$X$NE,[EMAIL PROTECTED]:!"$$$+$J$kL@<(E*!"0EL[E*$JJ](B
$B>Z$b$$$?$7$^$;$s!#!W(B
(B
(B  $B$$$+$J$k;vBV$,H/@8$7$h$&$H$b!"(JApache(B (JSoftware(B 
(B (JFoundation(B $B$"$k$$$O$=$NEj9F%a%s%P$O!"D>@\E*!&[EMAIL 
(B PROTECTED]6vH/E*!FClE*!E57?E*!I,A3E*$JB;32!?B;:!JBeMQ$NIJ$d%5!%S%9$NDs6!%3%9%H(J---$BMxMQ5!2q!&%G!<%?!$NB;<:!'%S%8%M%9$NCfCG$r4^$_$^$9!#C"$7!"$3$l$K8B$C$?;v$G$O$"$j$^$;[EMAIL
(B  PROTECTED],Nc$(!"$I$N$h$$J860x$GH/@8$7$h$$,!"[EMAIL 
(B PROTECTED],$"$m$$,!"[EMAIL 
(B PROTECTED]e$K($5$l$F$$$h$$,!"6/@)K!5,e$G$"$m$$,!"$^$?$OITK!9T0Y!J8N0U$d$=$NB$r4^$`!K$G$"$m$$,!"$3$N%=%U%H%%'%"$N;HMQ$+$iH/@8$9$k$$$+$J$k;[EMAIL
(B  PROTECTED];$s!#$^$?!"$=$N$h$$JB;[EMAIL 
(B PROTECTED],;vA0$K2?$i$+$N7A$G;XE$5$l$F$$$?$H$7$F$b!"F1MM$G$9!#(J/note(B
(B
(BI don't think $B!VEj9F!W(B is the correct translation for
(B"contributor".  We normally use $B!V9W8%!W(B.  I believe
(Btranslation here would be improved for more readability but
(Bthere are lots of legal words so it might be better to ask
(Blawyers how to translate them.
(B
(B   (Jp$BK\%=%U%H%&%'%"$O!"(JApache(B (JSoftware(B (JFoundation(B 
(B $B$KBP$9$k!"B?$/[EMAIL PROTECTED]([EMAIL PROTECTED])$C$F$$$^$9!#(JApache(B 

Re: ja translation new comer

[Yoshiki Hayashi]

Tetsuya Kitahata [EMAIL PROTECTED] writes:

 Hayashi-san, please verify the translated file I've put to
 docs at httpd.apache.org if you can read the file via MUA
 or online.

I'll try to review it as soon as possible but I've just
relocated so I cannot tell how soon that will be.  I might
be able to do it tonight or tomorrow.  I think I have some
free time until classes begin.

 P.S.  Are you in US (El Paso, Texas??) now?  Hayashi-san

Yes, it was a really long trip.  I'm still trying to recover
form jet lag. :-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual env.xml.ja filter.xml.ja handler.xml.ja install.xml.ja logs.xml.ja suexec.xml.ja

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 * [EMAIL PROTECTED] wrote:

   Index: install.xml.ja
   ===
 ...
   -href=http://httpd.apache.org/download.cgi;Apache Software
   +href=http://www.apache.org/dist/httpd/;Apache Software
Foundation

 Hmm. I think this change is should be reversed. The official download site is
 download.cgi (which distributes the traffic to the mirrors).

Oops.  Thanks for catching this.  Too many commits in one
day, I guess.  The original cause of the problem is that I
didn't review sync to 1.13 carefully enough.  My quick
glance of cvs diff before commit didn't catch it either.
I'll fix it shortly.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Bring 2.1 mod_example.xml up to date

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 I've never played with mod_example myself, but it appears there are still
 some problems in the docs.  For example, I don't think that the example of
 creating mod_myexample will work, since config.m4 would also need to be
 updated and buildconf run.

Yes, I thought it was necessary but I wasn't sure it was.

 Other than that, I don't have time to look in detail right now.  Sorry.

No problem.  I haven't had time to work on it, either.
Fortunately, I could find some time to update the docs this
week.  I hope someone has time to review my patch this time.

The only change from the previous version is that I added
config.m4 and autoconf step to add your own module section
as suggested by Joshua.  I think adding a new module should
be covered by its own docs together with apxs for DSO but I
wouldn't go that far this time and only concentrate on bring
the doc up to date.

Here's the update patch.  I have also put the full HTML
version at http://cvs.apache.org/~yoshiki/mod/mod_example.html.en

Index: mod_example.xml
===
RCS file: /home/penny/cvsroot/httpd-2.0/docs/manual/mod/mod_example.xml,v
retrieving revision 1.4
diff -u -r1.4 mod_example.xml
--- mod_example.xml 18 Apr 2003 02:28:28 -  1.4
+++ mod_example.xml 4 Jul 2003 08:48:00 -
@@ -10,14 +10,7 @@
 identifierexample_module/identifier
 
 summary
-note type=warning
-  This document has not been updated
-  to take into account changes made in the 2.0 version of the
-  Apache HTTP Server. Some of the information may still be
-  relevant, but please use it with care.
-/note
-
-pThe files in the codesrc/modules/example directory/code
+pSome files in the codemodules/experimental/code directory
 under the Apache distribution directory tree are provided as an
 example to those that wish to write modules that use the Apache
 API./p
@@ -41,43 +34,40 @@
 
 ol
   li
-Uncomment the AddModule modules/example/mod_example line
-near the bottom of the codesrc/Configuration/code file.
-If there isn't one, add it; it should look like this: 
-example
- AddModule modules/example/mod_example.o
-/example
-  /li
-
-  liRun the codesrc/Configure/code script
-  (codecdnbsp;src;nbsp;./Configure/code). This will
-  build the Makefile for the server itself, and update the
-  codesrc/modules/Makefile/code for any additional modules
-  you have requested from beneath that subdirectory./li
+Run codeconfigure/code with code--enable-example/code
+option./li
 
-  liMake the server (run codemake/code in the
-  codesrc/code directory)./li
+  liMake the server (run codemake/code)./li
 /ol
 
 pTo add another module of your own:/p
 
 ol type=A
-  licodemkdir src/modules/emmymodule/em/code/li
+  licodecp modules/experimental/mod_example.c
+  modules/experimental/emmod_myexample.c/em/code/li
+
+  liModify the file./li
+
+  liModify modules/experimental/config.m4.
+   ol
+ liCopy APACHE_MODULE line with example in it./li
+ liReplace the first argument example with emmyexample/em./li
+ liReplace the second argument with brief description of your module.
+  It will be used in codeconfigure --help/code./li
+   /ol
+  /li
 
-  licodecp src/modules/example/*
-  src/modules/emmymodule/em/code/li
+  liRun autoconf from the top-level directory./li
 
-  liModify the files in the new directory./li
+  liBuild the server with --enable-myexample/li
 
-  liFollow steps [1] through [3] above, with appropriate
-  changes./li
 /ol
 /section
 
 section id=usingtitleUsing the codemod_example/code Module/title
 
 pTo activate the example module, include a block similar to
-the following in your codesrm.conf/code file:/p
+the following in your codehttpd.conf/code file:/p
 example
lt;Location /example-infogt;br /
SetHandler example-handlerbr /


-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: latex status

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 Yep, it's in the TODO list to figure out how to fix that.  The problem is
 with the hyperref package.  The docs say that no escaping is required for
 #, but, as you note, I can't currently get it to work with or without
 escaping.

Your recent changes eliminated those errors.  Thanks.

 In the end, to get a working version, you need to hit q (for quiet) at
 the errors and just let LaTeX happily ignore them.  I'm working towards
 zero errors, but it might be a while before I get there.

You are probably aware of these errors but I've got errors
from mod/mod_ssl.tex, developer/API.tex and
mod/quickreference.tex.  I'll look latex build more closely
later but I might not be of much help as I'm not very good
at TeX.  I've been using LaTeX for quite some time but I
only use simple directives. ;-)

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review en offline package

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 Apart from the discussion (still thinking about it), I've committed initial
 support for HTML offline packages and built an English sample:
 http://cvs.apache.org/~nd/httpd-docs-2.1.0-dev.en.zip
 
 Please review; I'd like to put a 2.0.x one into dist/httpd to make the
 people happy ;-)

 After some days more or less offline... nobody looked at this?

Well, I only tried a few clicks but it looks good.  I'd say
go for it.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Configuration of /manual in httpd-2.1 httpd-std.conf

[Yoshiki Hayashi]

Yesterday, I installed 2.1 to see how it works w.r.t the
documents.

While I was cut and pasting type-map stuff from new
configuration, I noticed that all configurations for
/usr/local/apache2/manual is enclosed with IfModule
mod_alias.c.  It looks like this (irrelevant part is
omitted):

IfModule mod_alias.c
AliasMatch ^/manual(?:/(?:de|en|fr|ja|ko|ru))?(/.*)?$ @[EMAIL PROTECTED]

Directory @exp_manualdir@
Options Indexes
AllowOverride None
Order allow,deny
Allow from all

AddHandler type-map .html
Files *.html.*
RemoveHandler .html
/Files

SetEnvIf Request_URI ^/manual/(de|en|fr|ja|ko|ru)/ prefer-language=$1
RedirectMatch 301 ^/manual(?:/(de|en|fr|ja|ko|ru)){2,}(/.*)?$ 
/manual/$1$2
/Directory
/IfModule

I think this is not very desirable as you'll be unable to
browse HTTPD manual if your server disabled mod_alias.  If I
understand it correctly, mod_alias is only necessary for
lanuange links to work.  So I'd like to suggest moving out
type-map configuration out of IfModule.

BTW, what is the policy of IfModule usage?  It looks a bit
inconsistent.  There's IfModule mod_setenvif.c later in the
configuration but above SetEnvIf is not enclosed with
IfModule directive.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

What's wrong with 2.1 mod_status documentation?

[Yoshiki Hayashi]

httpd-2.1/docs/STATUS says mod_status should be updated to
2.0.  manual/mod/mod_status.xml itself says

Warning: This document has not been updated to take into
account changes made in the 2.0 version of the Apache
HTTP Server. Some of the information may still be
relevant, but please use it with care.

So I glanced the diff (what I actually did was ediff in
XEmacs) between
apache_1.3.27/src/modules/standard/mod_status.c and
httpd-2.1/modules/generators/mod_status.c

The most notable difference was 2.1 version introduced two
new status flags 'C' and 'I' for Closing and Idle cleanup.
Except that the functionality is almost the same.

It is true that the document itself looks a bit old, though.
There is an obsolete comment mentioning ServerType
directive.  Perhaps 'child' should be changed to 'worker'
since 'child' implies fork/exec.  But other than that,
mod_status file looks fine to me.  Is it OK to change them
(remove note about standalone mode and inet mode and do
s/child/worker/) and remove warning at the top of the
document?

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: latex status

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 - I very much hope that some people are going to give this a try.  I don't
 want to be the only person who knows how to deal with this stuff.  It
 would be helpful if some people would at least go through the build steps
 so that I know if there is anything in my local setup that I haven't taken
 into account.

I tried it and it failed in the middle of
misc/security_tips.tex file.

What I did was:

cd httpd-2.1/docs
cvs up
cd manual/build
cvs up
./build.sh latex
cd ..
pdflatex sitemap.tex

The error is:

[46] (./misc/security_tips.tex
! Illegal parameter number in definition of [EMAIL PROTECTED]
to be read again
   h
l.16 ...tpd.apache.org/lists.html\#http-announce}}
   where you can keep inform...

I manually escaped first occurence of # character and ran
pdflatex again.  It says:

[196]
! Illegal parameter number in definition of [EMAIL PROTECTED]
to be read again
   y
l.81 apache.org/docs/misc/FAQ.html\#year2000}}
   from the Apache Group, th...

So it looks like my pdflatex doesn't like '#' in \href.

Running pdflatex --version says:

pdfTeX (Web2C 7.4.5) 3.14159-1.10b
kpathsea version 3.4.5

Let me know if you need more information about my environment.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: when to add to mime.types

[Yoshiki Hayashi]

Astrid Keßler [EMAIL PROTECTED] writes:

 As I say there, I don't have any problem with making an exception to our
 policy, or even removing the policy entirely.  But the policy does keep us
 from getting a flood of please add our type messages.  (We already get a
 substantial number.)

 Opinions?

 Our policy is really ok. It is not too difficult to add additional types
 to the configuration (whereever they want). It seems a lot of people are
 thinking, it is a bug if they have to configure their server.
 exaggeratedAnd we would not need AddType if we put all and everything
 to the default mime.types./exaggerated

+1.  I don't want to see our config file cluttered with lots
of 'x-' types.  If it is very popular, it should be
registered as non 'x-' types.  We don't have problem with
accepting those official types.  If we accept one 'x-' type,
it would become harder to reject other private types.  It
will eventually lead to conflicts of private types.  I don't
think we should spend time discussing which private types to
keep in our config.  Don't accpet any private MIME type is
really a good policy, I believe.

Just my 2 yen.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: japanese files borked

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 At least http://httpd.apache.org/docs-2.0/mod/directives.html.ja and 
 http://httpd.apache.org/docs-2.0/mod/index.html.ja are broken. Could 
 someone please rebuild them (perhaps update the xslts before)?

Sorry for being relatively inactive lately.
Looks like you already updated them by yourself.  Thanks.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual/vhosts fd-limits.xml.ja fd-limits.html.ja.jis

[Yoshiki Hayashi]

Hiroaki KAWAI [EMAIL PROTECTED] writes:

 The two are different in binary level, but 'visually' the two are the 
 same in Japanese, too. It would do no harm. It's OK.

 # It's a matter of iso-2022-jp encoding, I think, 
 # isn't it, Yoshiki? ;-)

Yes, the former version had bogus escape sequences like ESC
( B ESC $ B which just doesn't mean anything.  I forgot the
details of iso 2022 encoding and its terminologies but what
it does is like: from now on, treat byte sequences as
US-ASCII (ESC ( B) or JIS X 0208 (ESC $ B).  The version
Erik committed does not contain those sequences and is
better.

I don't know why that happens, though.  We use same jars so
my Java VM (1.3.1) might be too old to do better encoding.

We can change output encoding to euc-jp if that suits better
for others.  I don't know any www browser that can handle
iso-2022-jp and cannot handle euc-jp.  I chose iso-2022-jp
only because the other Japanese files used that encoding.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question to non-latin Translators

[Yoshiki Hayashi]

André Malo [EMAIL PROTECTED] writes:

 I'm currently working at a letter bar for the glossary. How will/would
 you translate this page? Does a letter bar make any sense there in your
 language? Should it be dropped? (this could easily be done by leaving a
 note in $lang.xml, for instance messages lang=ja dropletters=yes
 or so)

As for Japanese translation, most translated terms would not
start with latin alphabet so it would better to drop letter
bar.

 If it makes no sense at all: are there alternatives you'd like to see?

Usually Japanese terms are sorted with the pronounciation of
words and indexed with the first sound but I don't think it
would be worth the effort to write such XSLT until glossary
becomes very big.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

quickreference.xsl does not work well with Japanese translation

[Yoshiki Hayashi]

Hiroyuki Kawai translated quickreference.xl into Japanese
and now it is committed to Japanese translsation CVS
repository.

However, I have a problem creating quickrefernce.html.ja.jis
form quickreference.xml.ja.

quickreference.xsl has following code to shorten 'server
config' etc to svdh.  But these phrases in Japanese version
are translated to Japanese so these tests always fail.  It
results in empty context column.

td
  xsl:if test=contextlist/* = 'server config's/xsl:if
  xsl:if test=contextlist/* = 'virtual host'v/xsl:if
  xsl:if test=contextlist/* = 'directory'd/xsl:if
  xsl:if test=contextlist/* = '.htaccess'h/xsl:if
/td

On soultion would be to leave 'server config' and the like
in module docs in English and do translation at the time of
transformation.  I'm not very good at XSLT so there might be
better ways to fix this problem.  Any suggestions?

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] for build.xml

[Yoshiki Hayashi]

Ilia Soldis [EMAIL PROTECTED] writes:

 I've included sections for russian documents. Please, check if I'm correct.

 +style basedir=../
 +   destdir=../
 +   style=../style/manual.ru.xsl
 +mapper type=glob from=*.xml.ru to=*.html.ru /

I suggest you append encoding to the filename if it is not
iso-8859-1.  It will be like 
mapper type=glob from=*.xml.ru to=*.html.ru.koi8-r /
if the encoding is koi8-r.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: About encodings...

[Yoshiki Hayashi]

Ilia Soldis [EMAIL PROTECTED] writes:

 In manual.*.xsl and other files - what encoding should I state? Should I 
 leave ISO-8859-1 or change it to KOI8-R in which I translate all files?

You should change all of them to KOI8-R if they are encoded
in KOI8-R.  Looking the way Japanese translation is done may
be of some help to you.  It also uses non ISO-8859-1
encoding.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual/style/xsl common.xsl directiveindex.xsl manualpage.xsl moduleindex.xsl synopsis.xsl

[Yoshiki Hayashi]

[EMAIL PROTECTED] writes:

 erikabele2002/09/05 16:06:17
 
   Added:   docs/manual/style manual.sv.xsl
docs/manual/style/css manual-loose-100pc-b.css
 manual-loose-100pc.css manual-loose-90pc-b.css
 manual-loose-90pc.css manual-loose-fix13-b.css
 manual-loose-fix13.css manual-loose-fix15-b.css
 manual-loose-fix15.css manual-sbar-left-100pc-b.css
 manual-sbar-left-100pc.css
 manual-sbar-left-90pc-b.css
 manual-sbar-left-90pc.css
 manual-sbar-left-fix13-b.css
 manual-sbar-left-fix13.css
 manual-sbar-left-fix15-b.css
 manual-sbar-left-fix15.css
 manual-sbar-right-100pc-b.css
 manual-sbar-right-100pc.css
 manual-sbar-right-90pc-b.css
 manual-sbar-right-90pc.css
 manual-sbar-right-fix13-b.css
 manual-sbar-right-fix13.css
 manual-sbar-right-fix15-b.css
 manual-sbar-right-fix15.css
docs/manual/style/lang de.xml en.xml ja.xml sv.xml
docs/manual/style/xsl common.xsl directiveindex.xsl
 manualpage.xsl moduleindex.xsl synopsis.xsl

If you rename files in the future, please check in rename
and modification separately.  When the modification and
rename is done at the same time, it is very hard to extract
the change.  To actually get the diff to update Japanese
translation, I had to do cvs log and cvs checkout to get the
last version of style/en.xml and then run diff locally.

If you first moved files and then checked in the
modification, you can see the diff in one step using cvs
diff.  It's a shame that we have to work around the
deficiencies of CVS, but we have to cope with that as long
as we continue to use CVS.  I wish we could switch to
Subversion. *sigh*

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New draft of manual style

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 1. There was one main reason I stopped developing the wacky style: 
 complexity.  If felt it was over-complex both visually and particularly 
 the css and html code.  The css code had the advantage that it was 
 externally developed and maintained at style.tigris.org, but I still 
 didn't like using something that seemed difficult to maintain.

Oh, I didn't know that.  My comment was solely on look and
feel, so I completely agree with your suggestion #2 below.

 2. Let's try to determine exactly what about the original style people 
 like better.  Perhaps we can combine the two in a way that will work. 
 Some suggestions:

 b) Side-menu listing important stuff seperate from text rather than 
 having the menu integrated from the text.  I like this, but I'm not sure 
 how much it is about the cool factor.  It also leads to the obvious 
 disadvantage of having to put the whole darn page in a table, which is 
 annoying but very common for modern sites.

As Michael pointed out, it can be done with only css.  If
implementing it doesn't end up in complex html and css, I'd
like to see it done.  Module docs looks much better if
directives is listed on side-menu.

 c) Smaller font.  As I mentioned in the original discussion, smaller 
 fonts tend to look more modern and professional, since almost all major 
 websites now use a less-than-default font size.  Of course, it is silly 
 to contradict what the user set as their default font, but since almost 
 all sites do it, small can almost be considered the default.

I don't have strong opinion about this.  Either one is fine
with me.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New draft of manual style

[Yoshiki Hayashi]

Finally caught up on this list after coming back from
vacation...

Joshua Slive [EMAIL PROTECTED] writes:

 http://cvs.apache.org/~slive/manual/
 
 Contains a new draft of the proposed new manual style.  This one is 
 fully generated using xslt, so all the xml files should be converted.

Sorry to say this now but I prefer previous wacky one.
That one had more information compactly layed out in first
screen with navigation bar on left side.

This is probably just a matter of taste but I don't like
bluish characters on white background.  To me, black on
white is easier to read.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [STATUS] (httpd-docs-2.0) Wed Jul 31 23:45:29 EDT 2002

[Yoshiki Hayashi]

Carlos Araya [EMAIL PROTECTED] writes:

 - Original Message - 
  - XML
  - Is there a way to get Ant+Xalan to validate the documents
  when 
transforming?
 
 Is it a requirement to use Xalan? I use XSLTproc from within ant and
 it does my validation for me, the other way to do it would be to
 write a task that uses Xerces to do the validation. Please let me
 know

No, Xalan is not a requirement.  What we want to do is to
validate documents only when they are changed.  i.e., when
they are going to be transformed.

We have an Ant target named validate, which uses Xerces, but
that will validate all documents unconditionally.  It would
be nicer to have another target that will only validate
changed documents.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

httpd-docs-lib.tar.gz updated

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 On 29 Jul 2002, Yoshiki Hayashi wrote:
  I don't think we have problem using Ant 1.5 instead of 1.4.1
  so if your improved build.xml requires 1.5, let's replace
  jars in httpd-docs-lib.tar.gz.
 
 Yoshiki, please feel free to go ahead and modify httpd-docs-lib.tar.gz, or
 if you'd like me to do it, let me know.

I updated httpd-docs-lib.tar.gz.  Everyone using old version
please grab it from
http://httpd.apache.org/dev/dist/httpd-docs-lib.tar.gz
again.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML validation and Ant

[Yoshiki Hayashi]

Vincent de Lau [EMAIL PROTECTED] writes:

 For mod_rewrite.xml, here is a patch to fix the title-less section's. It has
 been submitted before, but the patch also contained another patch that is
 comitted already.

 [2 mod_rewrite.patch application/octet-stream (quoted-printable) ...]
 
 [3 buildxml.patch application/octet-stream (quoted-printable) ...]

Committed.  Thanks.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

XML validation and Ant

[Yoshiki Hayashi]

I once again stumbled across Ant's bug.  Using Ant's
xmlvalidate task, validating iso-2022-jp XML files always
fail because XML parser assumes passed file is in UTF-8.

I fixed the bug as in bug #11279.  I re-uploaded jar files
to
http://httpd.apache.org/dev/dist/jakarta-ant-1.5-modified-jar.tar.gz

Can we agree to use that jar instead of current modified
1.4.1 jar and apply xmlvalidate patch from Erik Abele
[EMAIL PROTECTED] below?  It will give us the option to
validate XML documents.

I don't think we should make xslt target depend on validate
because validate target validates all XML files, not just
updated ones.  We can occasionally validate them using
% sh build.sh validate

Index: build.xml
===
RCS file: /home/penny/cvsroot/httpd-2.0/docs/manual/style/build.xml,v
retrieving revision 1.6
diff -u -r1.6 build.xml
--- build.xml   29 Jul 2002 11:43:11 -  1.6
+++ build.xml   30 Jul 2002 11:27:20 -
@@ -48,6 +48,20 @@
   mapper type=glob from=*.xml.ja to=*.html.ja.jis/
   param name=relative-path expression=./
 /style
+  /target
+  target name=validate
+description=Validate the XML source files
 
+!-- Validate the root directory of the manual --
+xmlvalidate lenient=false failonerror=false warn=true
+fileset dir=../
+ includes=*.xml *.xml.ja/
+/xmlvalidate
+
+!-- Validate the mod directory (.en + .ja) --
+xmlvalidate lenient=false failonerror=false warn=true
+fileset dir=../mod/
+ includes=*.xml *.xml.ja/
+/xmlvalidate
   /target
 /project


-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is appendix in stopping.html still correct?

[Yoshiki Hayashi]

Somehow I forgot to reply to this mail...

Justin Erenkrantz [EMAIL PROTECTED] writes:

 On Thu, Jun 13, 2002 at 07:34:39PM +0900, Yoshiki Hayashi wrote:
  At the end of httpd-2.0/docs/manual/stopping.html, there's a
  section titled Appendix: signals and race conditions.
  
  It mentions Apache 1.2b9 and Apache 1.2.  Is this section
  still relevant in 2.0?  Or is it out of date and can be
  simply deleted?
 
 I believe the second paragraph (re: ScoreBoardFile) is still
 relevant.  The fourth paragraph (re: Keep-Alive) might still be
 relevant, but I'm not 100% sure.  -- justin

If fourth paragraph is still relevant, how about removing
the mention of fix which didn't go in 1.2?  The removed
sentence below gives me the impression that it should be
fixed at least in 1.3.

Index: stopping.html.en
===
RCS file: /home/penny/cvsroot/httpd-2.0/docs/manual/stopping.html.en,v
retrieving revision 1.25
diff -u -r1.25 stopping.html.en
--- stopping.html.en25 Jul 2002 21:46:38 -  1.25
+++ stopping.html.en30 Jul 2002 11:58:48 -
@@ -195,8 +195,7 @@
 involving the second and subsequent requests on a persistent
 HTTP connection (KeepAlive). It may exit after reading the
 request line but before reading any of the request headers.
-There is a fix that was discovered too late to make 1.2. In
-theory this isn't an issue because the KeepAlive client has to
+In theory this isn't an issue because the KeepAlive client has to
 expect these events because of network latencies and server
 timeouts. In practice it doesn't seem to affect anything either
 -- in a test case the server was restarted twenty times per


-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: manual/style/build.xml

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 Yoshiki, if you're reading this, could you ping the Ant people again about
 getting that change into their code.

Thanks for reminder.  I searched bugzilla database and to my
surprise I couldn't find my earlier enhancement request.  I
remember I did try to input to bugzilla but I cannot find
auto-reply nor bug number on my disk.  Probably I did some
silly mistake and the request was lost. :-(

I recreated patch for Ant 1.5 and confirmed my request is
really submitted this time.  The bug number is 11249.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: manual/style/build.xml

[Yoshiki Hayashi]

David Shane Holden [EMAIL PROTECTED] writes:

 I should also mention xmlvalidate isn't available in the custom jar file ...

If you need new features in Ant 1.5, I've just uploaded
modified Ant 1.5 to
http://httpd.apache.org/dev/dist/jakarta-ant-1.5-modified-jar.tar.gz

With this, you won't need to change the name of Japanese
files.  That will probably make your patch smaller and
easier to review.

I don't think we have problem using Ant 1.5 instead of 1.4.1
so if your improved build.xml requires 1.5, let's replace
jars in httpd-docs-lib.tar.gz.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Antwort: Re: cvs commit: httpd-2.0/docs/manual/style build.xml

[Yoshiki Hayashi]

Yoshiki Hayashi [EMAIL PROTECTED] writes:

 3. Modify Ant to meet our requirements.  Use that jar
throughout the project by putting it to somewhere like
site-tools.

There are two ways to achieve it:

  1.  Replace xml with supplied extension
  2.  Enhance style rule to allow nested mapper element

I first tried option 1 but I found out that I actulally want
to map .xml.ja to .xml.ja.jis so I went to implement option
2.

Here's a patch.  This one is against Ant 1.4.1.  I'll send a
patch against 1.5 Beta1 to Ant people, probably via
bugzilla.

This patch allows you to put something like

  mapper type=glob from=*.xml.ja to=*.html.ja.jis

and

  mapper type=glob from=*.xml to = *.xml.en

inside style element.

diff -ur 
jakarta-ant-1.4.1.orig/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java 
jakarta-ant-1.4.1/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java
--- 
jakarta-ant-1.4.1.orig/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java  
Thu Oct 11 22:58:29 2001
+++ jakarta-ant-1.4.1/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java   
Wed May 22 18:48:14 2002
@@ -61,9 +61,11 @@
 import java.util.StringTokenizer;
 import java.util.Vector;
 import org.apache.tools.ant.*;
+import org.apache.tools.ant.types.Mapper;
 import org.apache.tools.ant.types.Path;
 import org.apache.tools.ant.types.Reference;
 import org.apache.tools.ant.util.FileUtils;
+import org.apache.tools.ant.util.FileNameMapper;
 
 
 /**
@@ -99,6 +101,7 @@
 private String xslFile = null;
 
 private String targetExtension = .html;
+private Mapper mapperElement = null;
 private Vector params = new Vector();
 
 private File inFile = null;
@@ -311,6 +314,18 @@
 }
 
 /**
+ * Defines the FileNameMapper to use (nested mapper element).
+ */
+public Mapper createMapper() throws BuildException {
+if (mapperElement != null) {
+throw new BuildException(Cannot define more than one mapper,
+ location);
+}
+mapperElement = new Mapper(project);
+return mapperElement;
+}
+
+/**
  * Processes the given input XML file and stores the result
  * in the given resultFile.
  **/
@@ -326,7 +341,15 @@
 long styleSheetLastModified = stylesheet.lastModified();
 inFile = new File(baseDir,xmlFile);
 int dotPos = xmlFile.lastIndexOf('.');
-if(dotPos0){
+if (mapperElement != null) {
+FileNameMapper mapper = mapperElement.getImplementation();
+String[] fileNames = mapper.mapFileName(xmlFile);
+if (fileNames != null) {
+outFile = new File(destDir, fileNames[0]);
+} else {
+outFile = new File(destDir, xmlFile + fileExt);
+}
+} else if(dotPos0){
 outFile = new 
File(destDir,xmlFile.substring(0,xmlFile.lastIndexOf('.'))+fileExt);
 }else{
 outFile = new File(destDir,xmlFile+fileExt);



-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Antwort: Re: cvs commit: httpd-2.0/docs/manual/style build.xml

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 There are lots of potential solutions to this problem, but none is
 particularly nice.  The two closest I see right now:
 
 1. Start enforcing the no extension rule in the apache docs -- ie.,
 refer to files as mod/suexec with no extension.  I don't think this is a
 particularly good idea right now because it would break a ton of links and
 because it would introduce xml/html into the negotiation mix -- we might
 want that at some point, but not until we have properly researched it.
 
 2. Abandon ant and require the use of gnumake.  Here we lose a bunch of
 nice features like style-sheet preloading.  It would perhaps be nice to
 abandon java entirely and go with Xalan-C, but from my limited testing,
 that version won't even touch the japanese encoding, so we'd be stuck
 with a mixed environment.

I'd like to propose another solution.

3. Modify Ant to meet our requirements.  Use that jar
   throughout the project by putting it to somewhere like
   site-tools.

I've got a bit busier this week but I think I can come up
with some working patch soon.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Changes required to support Japanese module docs

[Yoshiki Hayashi]

First, we need some way to change encoding attribute of
xsl:output to support Japanese or any other translation
that can't be encoded in iso-8859-1.

Unfortunately, xsl:output is only allowed as a top level
element so we cannot use conditionals to change encoding.
The only way is to have stylesheet for each language,
e.g. manual.en.xsl for English, manual.ja.xsl for Japanese.
But fortunately, XSLT allows inclusion of other stylesheet.
So I'd like to move all contents except xsl:output from
manual.xsl and move to another file, say base.xsl.  Then the
contents of manual.xx.xsl will be only xsl:output and
xsl:include.

When the above change are made, build.xml should be changed
to use manual.ja.xsl for *.ja.xml.

Second, we need to rename transformed English docs to
something.en.html so that Japanese ones can be
content-negotiated.  Probably this should be done after we
decide the standard XSLT tool.

I'd like to make these changes to support Japanese module
docs.  Any suggestions or objections?

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Japanese Translation

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 As far as the Japanese translation, I am really lost.  It seems to me that
 Xalan won't touch a document with the iso-2202-jp encoding.  I searched
 around a little for more info, but I couldn't find anything.  Yoshiki, is
 it possible for you to find some information in Japanese forums on how
 people are doing XSLT in Japanese?

Actually, I couldn't find many information about using XSLT
in Japanese.  One said that Xalan-J doesn't accept
iso-2022-jp as an input.  The other said that Xalan-C++
accept iso-2022-jp if Xereces is changed to use ICU.
However, I could convert mod_suexec.ja.xml succefully using
style/build.sh with modification of encoding attribute of
xsl:output in manual.xsl.  I've just committed the
transformed version.

What I used was:

  Sun (blackdown) JDK 1.3.1
  Xalan-Java 1.2.2 (that's what Debian version number says)
  Xerces-java 1.4.3
  Ant 1.4.1

If iso-2022-jp encoding is problematic for other people, I
have no problem changing it to UTF-8.  The only requirement
is that XSLT processor can produce iso-2022-jp file until
every web browsers out there support UTF-8.  Although it is
more convenient if it accepts iso-2022-jp input, it
certainly is not a must.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/docs/manual/style ja.xml

[Yoshiki Hayashi]

Patrik Grip-Jansson [EMAIL PROTECTED] writes:

 On 6 May 2002, Yoshiki Hayashi wrote:
 
  OK, I added Japanese translation of mod_suexec.xml but as in
  the log, it can't be transformed to HTML in current setup.
 
 It seems to be working when using xsltproc, but not with xalan.

I haven't tried your new manual.xsl yet, but older one
worked with Xalan-J.  Of course, I need to change
xsl:output method=html encoding=iso-8859-1 indent=no/
to
xsl:output method=html encoding=iso-2022-jp indent=no/
so that specified encoding can correctly encode characters.
Perhaps it depends on the Java runtime?  I used Blackdown
Java 1.3.1.

I presume this setting can be conditionalized like $language
stuff in settings.xml.  Could you add logic to choose
encoding by checking modulesynopsis/language?

  2. Some hard-coded English text in manual.xsl should be
 moved to en.xml, ja.xml etc.
 
 I'm cleaning up manual.xsl right now, while doing this I'm fixing all
 hard-coded strings. I'll probably commit this with in a couple of hours.

I noticed you have already done that.  Thanks.

  3. How can I designate XSLT processor to use ja.xml?  My
 guess from looking at the settings.xsl file was to add
 language=ja to modulesynopsis but it didn't work.
 
 There were some problems using ant and translations. Since I didn't have 
 the time to look into it properly I hard-coded the language to en. As 
 soon as I've finished the clean up, I'll give it another go...

I'll wait for your next commit on this one.  Thanks in advance.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Translated module docs in 2.0?

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 I suggest that you start by committing the jp.xml for the stylesheet
 translations and one module doc in xml format with a name like
 mod_xxx.jp.xml, and then the two of us can play with build.xml and see if
 we can get a good transformation setup.

That sounds like a reasonable approach.  I'll add ja.xml to
the repository soon.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's the recommend version of Xalan and Xerces?

[Yoshiki Hayashi]

Joshua Slive [EMAIL PROTECTED] writes:

 On 23 Apr 2002, Yoshiki Hayashi wrote:
  What is the recommended version of Xalan and Xerces?  I have
  Xalan 1.2.2 and Xerces 1.4.3 installed from Debian unstable
  package.  When I ran styles/build.sh to generate HTML from
  XML docs, the diff was a bit larger than expected namely
  because it reordered attributes like href and class.

 I think that is because I used Xalan-C to generate the docs at one point,
 at it does the ordering differently from Xalan-J.

Thanks for this info.  I feared that I might be missing
something obvious which is not written in
docsformat.html. :-)

 But
 in general, I wouldn't worry about the size of the diffs.  Those are
 generated files; they are only in CVS for the convenience of the release
 manager.

I thought it would make reviewing a bit harder, but it will
be solved by as simple way as doing separate commit of
generated files.  I'll do it that way the next time I touch
module docs.

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Translated module docs in 2.0?

[Yoshiki Hayashi]

As httpd 2.0 is already released as GA, I want to populate
docs with more Japanese translations.  However, I stumbled
at mod directory where HTML files are automatically
generated from XML files.  I know almost nothing about the
softwares used there.

There already exist en.xml and sv.xml so it looks like some
measure was taken to add translated docs.  But guessing from
the content of build.xml, it only handles *.xml to *.html
conversion.  If someone can teach me how to change build
system to add translations, I'll really appreciate it.  If
not, I'll go through the pile of docs and eventually find
out how to do it...

-- 
Yoshiki Hayashi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]