"Roy T. Fielding" <[EMAIL PROTECTED]> writes:
Personally, I think that creating a project that consists of people that want to work on other projects is a bit weird. Why don't you just ask for a mailing list? The actual commits will have to be made by the specific projects, not by an uber-i18n-committee, so project formation doesn't make any sense.
I was thinking on the l10n making "doc commits" and "properties commits", ... themselves, and having means to track *both* the source document (in the original project cvs) and the translated documents (???).
i18n is different from l10n - translation. i18n is really a code issue and can only be handled at that level.
Other projects with more successful l10n efforts have, on the other hand, created efforts centralized not on the code, but on bringing together a group of volunteers who are not coders, and who may not even be experts on one particular project outside its documentation, but who are able to provide translations.
This has the advantage of having one stream of documentation queued up for translation, and encourages the growth of a comunity based on translation work, something that is less likely for individual projects.
Debian developer Steve Langasek provides this bit of info on how the FSF works, for comparison:
The GNU TP receives .po files from upstream maintainers, announces them to the translation mailing lists, and then each .po file is assigned out to an individual translator according to interest.
This kind of things was what promtpted myself to suggest top level and bringing the discussion here.
When the original proposal spoke about i18n (and translation in the narrow scope of i18n: button names, etc.) for the whole jakarta, I thought that this (the translation part) was mostly independent of programming language and/or project. I signaled clearly that I was speaking about having a translation infrastructure, and that this infrastructure was not simple to develop.
For instance, I was thinking in how to organise technically a repository so that the translators could be made aware of version and release control, i.e. translating "patches" instead of losing synchrony or re-translating whole property files or docs where only a few lines were added or changed, with the risk of inconsistent translations of old items across releases. I have no solution for this, except noop, i.e. each document maintainer tracks herself the source and translation (bad for replacement of translator and incremental quality of translations).
I think the original proposal was purely about i18n technology for java. But the discussion drifted into translation of docs, web sites, etc. It is unfortunate that I (and other people) mixed two differen issues here and mudded the discussion a bit.
Let's separate the issues back. I changed this thread to be about translation efforts. Please don't bring code back to this thread.
That said, being a native english speaker, I've only really observed this stuff from afar.
Ciao,
Re: the other comment by Roy T. Fielding:
An ASF project exists as an organizational mechanism for releasing software that might otherwise get people sued as individuals. It does not exist for the sake of replacing USENET news or community mailing lists.
This makes worthwhile having either some means to monitor l10n as a whole, cause project people cannot assess the fidelity or quality of translations unless they are plurilingual. Again, it does not look completely off track.
I have more and more the idea that code is about language and expression, and that there is not that much difference between a document and a program.
But, and this is why I asked for the discussion in community, I don't have clear ideas on how to make sense of this.
Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
