> I set up the translated mirror site in my company's host > (jakarta.terra-intl.com), but if there is *completely > consistent infrastracture* in apache.org, I am willing > to put the contents on it.
You are asking, I believe, about support for MultiViews. For any given page, P, there could be P.<language>, e.g., index.html.en, index.html.jp, etc. Translation would be very much a cross-ASF project that would influence other projects, but it wouldn't "own" much. For example, many ASF sites use xdocs. Tools like Anakia, Forrest, and Maven are used to generate the final output. It seems to me that with respect to web site publishing, you want to promote a use standard such that for all P.xml, currently in English, there should be P.xml.<language>. Our site publishing tools and scripts should then build all of the html pages in the various available languages. That's the $0.02 version. Details would need to be worked out. > I imagined how wonderful it would be to set up maling lists > of (non-technical)language-specific mailing list in apache.org?? > i18n/l10n ASF TLP can cover mentioned above i imagined. I think that there seems to be agreement on a mailing list. It is when you talk about it as a TLP that you encounter obstacles. I am not a lawyer, but I'll try to explain to the best of my understanding. A TLP has a particular legal role within the ASF. The TLP is provides oversight over ASF property, which ties into the legal authority by which ASF is able to protect individual contributors in the event of a lawsuit. I think that many people think of the TLP as an honor earned, and aren't aware of the legal ramifications. In any event, based upon the preceding, I think you will see that while localization should be an ASF-wide effort, it isn't a TLP. For each web site (let's consider localizing applications separately), there would have to be some tweaking of the site building process, and there would need to be parallel sets of pages maintained as the site evolved, but the TLP responsible is the site's TLP, e.g., the Jakarta TLP, the James TLP, etc. You might have policies, procedures, best practices, etc., but those documents could go into an existing repository of shared documents. Likewise, localizing applications would involve some code change and localization resources, and those, too, would belong to that application's TLP. *IF* there were some shared code developed for application localization, then it might go into Apache Commons if there weren't a better place. But that's a bridge to cross when it happens. [And, yes, "Commons will be language-agnostic" refers to programming language] I suggest that external documentation, such as the web sites, represents the easiest initial target for translation efforts. It requires no code change to the applications, relatively little involvement from developers, and has a visible impact. If there are no objections from the infrastructure team, if you wanted to come over to site-dev@james.apache.org, I'm sure that we'd be happy to talk to you about seeing if the content from http://james.terra-intl.com/ could be integrated into the James site using MultiViews. A couple of issues that come to mind from what I see of the Jakarta and James translations are: (a) keeping translations up-to-date, and (b) ensuring that translations say what they are supposed to say. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
