Re: Web site translation
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]
Re: Web site translation
[bringing this over from docs@ for a dev@ ping] Yoshiki Hayashi wrote: 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. As a person in the 'XSLT camp', I am not against making changes to the current build system for the site to support translations. I just feel that we will end up duplicating large ammounts of work when or if we convert to an XSLT based system. ( Less Wine and more Dew I could apply to my own comments :-/ ) Do other developers have objections to moving the website to XSLT (like the manual) instead of the current Velocity/Anakia? -Paul Querna - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
--On Monday, November 29, 2004 6:33 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: Do other developers have objections to moving the website to XSLT (like the manual) instead of the current Velocity/Anakia? I would recommend that any initial XSLT source transforms be kept as close to the Anakia templates as possible. (i.e. keep section, etc.) Otherwise, we're only going to change it to change it and we shouldn't have to force ourselves to learn something new just because one or two think it's cool - and that's bad. My secondary goal is that we should ensure the build process and file layout is as simple as it is now with httpd-site. If it doesn't work or is confusing, people will tend to ignore the site. IMHO, this is probably why some developers don't touch the docs as they might otherwise. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
* Justin Erenkrantz [EMAIL PROTECTED] wrote: By and large, I think the core developers are the ones who place most of the content on the website - not the documentation group. Perhaps that could change...but I think the httpd docs group as a whole have historically paid little attention to our web content. The most things that are changed, *are* documention pages (not only httpd, of course)... Other things just seem to include the download page, the front page and the contributor's page (I may be wrong). From time to time new project pages. But I don't see any real *maintenance*. That's what the docs team could (and probably happily would) take over. At least this sounds like a great idea of task sharing. Honestly, I'd strongly prefer that any efforts on the website focus on content not style first. Converting it to XSLT bores me as it doesn't solve any real problems we have. I believe our more pressing problem is that we have lots and lots of outdated information on there that we need to clean up and fix. So, IMHO, any effort towards refreshing the look should also focus on updating content. And, not updating the English version *first* makes the translators' job more difficult as they'd be translating useless content that'd be thrown out later as people clean up the English versions. Yes, of course. The point for xslt is, that it's just a well known standard with well known behaviour. Velocity is not. Said that; of course we'll try to keep the process as close as possible to the current one, it's of our all interest ;-). But if we can make things better, we *need* to change stuff. Which is a good thing [TM], simply because the current site is *really* ancient. I take it you either have blocked out what was on there previous to the Anakia version or forgotten. =) *I* think it's rather 'new.' But, I guess I'm starting to be an old greybeard around here. Oh no! (/me recoils from the folks who still consider me a clueless newbie.) -- justin Oh, I was talking about content and layout, i.e. the stuff that site maintainers usually happen to touch. And by the way, the pre-anakia stuff is *still there*. That's what me disturbes ;-) I'm going to make a test system (may need a while, but I'm not starting at zero). If it's at a certain stage, I'll propose it. If it's accepted - good, if not, good, too. I'll have learned a lot either way ;) nd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
Por favor não me mandem mais mensagens. B - Original Message - From: Yoshiki Hayashi [EMAIL PROTECTED] To: docs@httpd.apache.org Cc: dev@httpd.apache.org Sent: Monday, November 29, 2004 7:49 AM Subject: Re: Web site translation 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. Esta mensagem foi verificada pelo E-mail Protegido Terra. Scan engine: McAfee VirusScan / Atualizado em 24/11/2004 / Versão: 4.3.20 (10.21) - Dat 4410 Proteja o seu e-mail Terra: http://www.emailprotegido.terra.com.br/ --- 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;
