RE: Swedish xml translation
On Fri, 8 Mar 2002, Joshua Slive wrote: The problem with make is that we would need to list each xml file in the makefile. We're trying to reduce that kind of duplication. No, you don't. How about; .SUFFIXES : .html .xml vpath = ../mod/ xmlfiles := ../mod/*.xml htmlfiles := $(patsubst %.xml,%.html,$(xmlfiles)) all: $(htmlfiles) %.html : %.xml XalanTransform $ ./manual.xsl $@ Works great - well, at least as proof-of-concept :-) -- .-. | Patrik Grip-Jansson | | Ringen 4B |.. | 78444 Borlänge .--'' http://gnulix.com/ `-. | Sweden | All views and opinions are my own, | `--| PH:+46(0)24382823 PW:+46(0)707354360 | `--' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
On Wed, 6 Mar 2002, Joshua Slive wrote:
3. Have some funky build process tranlate .en.xml to .html.en while doing
the XSLT. The build process I'm using at the moment is simply:
for file in `ls ../mod/*.xml | sed s|../mod/||g | sed s/.xml//g`
do
echo $file
${JAVA_HOME}/bin/java -classpath $CLASSPATH
org.apache.xalan.xslt.Process \
-IN ../mod/$file.xml -XSL manual.xsl -OUT ../mod/$file.html
done
But this will get more complicated in the future as we add more directories,
etc. I had hoped to use Ant, which has some very fancy automation features,
but as I've said, it is crashing on me at the moment.
Unless you feel like leading the charge on 2 or 3, I suggest that you stick
with 1 for now so that you can get on with your translations.
Number three is very easy to do. Especially if we aren't going to use ant.
It would be easy with ant as well if we allow the usage of
filemapper=regexp, then we could do something like;
mapper type=regexp from=^(.*)\.(.*)\.xml$$ to=\1.xml\2/
But since type=regexp requires extra libs I'm not sure if that's a good
thing.
I've got to the point were ant isn't crashing anymore. It seems that the
problem is resetting the language variable between runs, if you use;
xsl:variable name=languageen/xsl:variable
It works. I haven't had the time to figure out a good, dynamic replacement
that works with ant. So, I haven't made any changes to settings.xsl that I
feel are worthy of putting into the CVS :-)
I guess the question is; should we use ant or not? I think good ol' make
would be a better alternative for now...
--
.-.
| Patrik Grip-Jansson |
| Ringen 4B |..
| 78444 Borlänge .--'' http://gnulix.com/ `-.
| Sweden | All views and opinions are my own, |
`--| PH:+46(0)24382823 PW:+46(0)707354360 |
`--'
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
From: Patrik Grip-Jansson [mailto:[EMAIL PROTECTED] I've got to the point were ant isn't crashing anymore. It seems that the problem is resetting the language variable between runs, if you use; xsl:variable name=languageen/xsl:variable Interesting. I think that jives with my guess about the multi-level stylesheet includes being the problem. I guess the question is; should we use ant or not? I think good ol' make would be a better alternative for now... The problem with make is that we would need to list each xml file in the makefile. We're trying to reduce that kind of duplication. On the other hand, if the new MultiViews processing works, there is no need to reverse the extension ordering. I haven't had a chance to do my own testing to make sure that file.html will match file.en.html in apache 2.0. If you can test and confirm that, then we can go ahead and start using that ordering. As far as the build system, better alternatives are welcome, but I'm not going to put too much time into it myself right now. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: Swedish xml translation
Hi Joshua,
The build process I'm using at the moment is simply:
for file in `ls ../mod/*.xml | sed s|../mod/||g | sed s/.xml//g`
do
echo $file
${JAVA_HOME}/bin/java -classpath $CLASSPATH
org.apache.xalan.xslt.Process \
-IN ../mod/$file.xml -XSL manual.xsl -OUT ../mod/$file.html
done
But this will get more complicated in the future as we add more
directories, etc.
if these directories do reside within the same directory tree, then to me
this looks like replacing the for construction by some find and xargs
constructions might do the trick.
On the other hand, the whole task 'smells' like using Makefiles would be
the
thing to do ... in which case then again the order of filename extensions
would matter.
Regards, Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RE: Swedish xml translation
On Thu, 7 Mar 2002 [EMAIL PROTECTED] wrote: if these directories do reside within the same directory tree, then to me this looks like replacing the for construction by some find and xargs constructions might do the trick. But there might also be variables that we need to pass to the transformer on a per-directory basis in order to get relative URLs to work correctly. On the other hand, the whole task 'smells' like using Makefiles would be the thing to do ... in which case then again the order of filename extensions would matter. And I don't particularly want to have to enumerate every file in the tree in the Makefile. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Antwort: RE: Swedish xml translation
Hi Joshua, On the other hand, the whole task 'smells' like using Makefiles would be the thing to do ... in which case then again the order of filename extensions would matter. And I don't particularly want to have to enumerate every file in the tree in the Makefile. of course I wouldn't suggest doing that. ;-) You might rather do one of the following things: a) write more generic Makefiles, using the much more powerful GNUmake; b) have some tiny Apaci-like tool to generate a Makefile for each docs directory. (Don't be afraid, this would really be a tool as simple as the structure of the rules to be generated; you probably have some cvs add information to be fed into such a tool, or one might just parse the tree for a list of defined filename extension patterns.) c) use the concept of your original shell script loop, just enhance it a bit for handling relative URLs. (For which I would then prefer Perl to shell as it provides better substring handling and the like, and is more platform independent as well.) Regards, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
From: Patrik Grip-Jansson [mailto:[EMAIL PROTECTED] As you notice I've named the file mod_suexec.sv.xml, putting the language before file type. Has anyone got a better idea for naming translated xml versions? I think it should be mod_suexec.xml.sv. I know this is a pain for windows The last extension is the filetype users. But the transformed html MUST look like mod_suexec.html.sv in order for multiviews to work, so it makes sense to parallel that in the xml. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
On Wed, 6 Mar 2002, Joshua Slive wrote: I think it should be mod_suexec.xml.sv. I know this is a pain for windows The last extension is the filetype users. Wish that it was only a problem for Windows users. Since most browsers use the extension for as well, you wouldn't be able to transform the file directly, ie mozilla file://mod_this_or_that.xml. But the transformed html MUST look like mod_suexec.html.sv in order for multiviews to work, so it makes sense to parallel that in the xml. It's a tough choice between uniformity and convenience... -- .-. | Patrik Grip-Jansson | | Ringen 4B |.. | 78444 Borlänge .--'' http://gnulix.com/ `-. | Sweden | All views and opinions are my own, | `--| PH:+46(0)24382823 PW:+46(0)707354360 | `--' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
From: Patrik Grip-Jansson [mailto:[EMAIL PROTECTED] On Wed, 6 Mar 2002, Joshua Slive wrote: I think it should be mod_suexec.xml.sv. I know this is a pain for windows The last extension is the filetype users. Wish that it was only a problem for Windows users. Since most browsers use the extension for as well, you wouldn't be able to transform the file directly, ie mozilla file://mod_this_or_that.xml. I hadn't considered that. H Actually, I think you are wrong in general. If the browser is accessing the file through the webserver, it should be using the Content-Type delivered by the webserver. Accessing through the filesystem is another story. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
On Wed, 6 Mar 2002, Joshua Slive wrote: Wish that it was only a problem for Windows users. Since most browsers use the extension for as well, you wouldn't be able to transform the file directly, ie mozilla file://mod_this_or_that.xml. I hadn't considered that. H Actually, I think you are wrong in general. If the browser is accessing the file through the webserver, it should be using the Content-Type delivered by the webserver. I agree, when accessing through a webserver they should use the mime type, but... Accessing through the filesystem is another story. ...that's what I meant (and hence the example with a file:// URL). I guess I didn't express myself clearly. -- .-. | Patrik Grip-Jansson | | Ringen 4B |.. | 78444 Borlänge .--'' http://gnulix.com/ `-. | Sweden | All views and opinions are my own, | `--| PH:+46(0)24382823 PW:+46(0)707354360 | `--' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Swedish xml translation
From: Patrik Grip-Jansson [mailto:[EMAIL PROTECTED]
Accessing through the filesystem is another story.
...that's what I meant (and hence the example with a file://
URL). I guess
I didn't express myself clearly.
OK. So there are a few ways to handle this:
1. Configure the browsers to associate the language tag with xml. This has
some obvious disadvanatages, like both .xml.en and .html.en would be
interpreted as xml.
2. Change the way we do language negotations. ie., use type maps or change
all the links to point to the base name without .html or .en.
3. Have some funky build process tranlate .en.xml to .html.en while doing
the XSLT. The build process I'm using at the moment is simply:
for file in `ls ../mod/*.xml | sed s|../mod/||g | sed s/.xml//g`
do
echo $file
${JAVA_HOME}/bin/java -classpath $CLASSPATH
org.apache.xalan.xslt.Process \
-IN ../mod/$file.xml -XSL manual.xsl -OUT ../mod/$file.html
done
But this will get more complicated in the future as we add more directories,
etc. I had hoped to use Ant, which has some very fancy automation features,
but as I've said, it is crashing on me at the moment.
Unless you feel like leading the charge on 2 or 3, I suggest that you stick
with 1 for now so that you can get on with your translations.
Joshua.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
