I completely agree with the Santiago's view. As I said before, The i18n sub/project can also attract many contributors who are interested in the internationalization issues in general. The effort of the i18n project can influence all the Apache related products. Maybe it can be a nice *community* which focuses on the internationalization issues related to the opensource communities. It would be very sad if the *know-hows*/*knowledge database* for the i18n/l10n issue will not be gathered in one appropriate place in apache/jakarta. The i18n sub/project might be able to become a *symbol* of the ASF's i18n, and this gives a good *SIGN* that ASF is welcoming all sorts of the users, developers and communities from all over the world. I think it would be very nice if any committers in a specific sub/project can easily ask to the community concerning with i18n issue, "I am lacking the know-hows on the i18n/l10n issue. Are there anyone who can support me/us here??".
Also, I think [i18n] is better to be proposed as TLP (Top Level Project), and (is possible) the http-docs project can join to it. cf. http://httpd.apache.org/docs-project/ Gather the wisdom from all over the world! Sincerely, -- Tetsuya ([EMAIL PROTECTED]) P.S. cross-posted to community@, too.. This matter is better to be discussed at community@ , I think. --------------------------------------------------------------------- On Sat, 12 Jul 2003 08:55:00 -0400 (Subject: Re: [i18n] Internationalization subproject) Robert Simpson <[EMAIL PROTECTED]> wrote: > (If you skip reading any of the following paragraphs, please do read the last > part, re: responding A through F.) > > I'm now seeing two distinct aspects to the "Internationalization" sub/project: > > 1) the internationalization of the user interface in code > 2) the internationalization of documents, including project/subproject > documentation, and other documents > > The main difference is that (1) will primarily be words and shorter phrases > used for prompts, etc, while (2) will be complete documents. They also would > have some things in common, such as: > > a) Some of the same people might do the language translations for both (1) > and (2), and therefore have commit authority for the translation sections for > both. > b) I would suggest that the primary storage format for both (1) and (2) would > be XML. The resources for specific languages (such as ".properties" for > Java) for (1) and various document formats (HTML, PDF, etc) for (2) could be > generated from the XML files. > +) among other things.... > > WRT Santiago's point about keeping the different translations in sync, the > solution is to have each word/phrase in (1) or each section in (2) identified > in the XML with a version number. Then it would be a simple matter to have a > program compare the two documents, and indicate where the translation needs > to be updated (the program could even provide an initial translation of the > section via machine translation, to be refined by the human translator). The > XML should also indicate who made each change and whether a change was > prompted by a need to change the document (additions to content, for example) > or as a translation of another version. That way, no particular translation > would have to be the "primary" document, and any conflicts could be > identified and handled. For example, a Spanish-speaking person could add a > missing section to the Spanish translation of a document, and that section > could then be translated back into the original and other translations. This > arrangement could also handle "proposed" additions (the XML equivalent of "I, > a Spanish translator, propose to add a new section here"), which could be > commented on (ex: "that section would be better placed over there") and/or > voted on by translators of other languages, etc.... > > Am I getting the feeling right that the Internationalization project would be > ultimately targeted for a top level, multiple-programming-language Apache > project? If so, I think the best approach would be to get the Java support > done first, to demonstrate its viability and usefulness. But still, from the > start, the intent should be to design with language-independence as the > ultimate goal. > > So, in summary, the organization of the project would be: > > 1. code common to both (1) and (2) > 1.1 code > This would include any code that supports both (2) and (3), such as the > code to do comparisons between translations > 1.1.1 any programming-language-neutral stuff (configuration files, XML, etc) > 1.1.2 Java > 1.1.2.1 source code > 1.1.2.1.1 source code contributors (committers) > 1.1.3+ other programming languages, similarly > > 2. user interface internationalization (words and phrases) > 2.1 code > This would include the code to generate programming-language-specific > resources, and provide access to those resources > 2.1.1 any programming-language-neutral stuff (configuration files, XML, etc) > 2.1.2 Java > 2.1.2.1 source code > 2.1.2.1.1 source code contributors (committers) > 2.1.2.2 resources (translations, generated from XML) > 2.1.3+ other programming languages, similarly > 2.1.3+.1 source code for other programming languages > 2.1.3+.2 resources for other programming languages (translations, generated > from XML) > 2.2 language translations (programming-language-neutral) > 2.2.1 any spoken-language-neutral stuff (all-language distribution files, > JUnit tests for file verification, etc) > 2.2.2 English language translations (initial "source" translations) > 2.2.2.1 XML format > 2.2.2.1.1 English language translators (committers) > 2.2.2.2 English user references > 2.2.2.2.1 XML formatted user reference (generated, XSL-FO?) > 2.2.2.2.2 HTML formatted user reference (generated, possibly with a doclet) > 2.2.2.2.3 PDF formatted user reference (generated, possibly from XML user > reference using Apache XML-FOP) > 2.2.3+ other spoken languages, similarly > > 3. internationalization of complete documents > 3.1 code > This would include code or tools (possibly making use of other Apache > code) to generate specific document file formats > 3.1.1 any programming-language-neutral stuff (configuration files, XML, etc) > 3.1.2 Java > 3.1.2.1 source code > 3.1.2.1.1 source code contributors (committers) > 3.1.3+ other programming languages, similarly > 3.1.3+.1 source code for other programming languages > 3.2 language translations (programming-language-neutral) > 3.2.1 any spoken-language-neutral stuff (all-language distribution files, > JUnit tests for file verification, etc) > 3.2.2 English language translations (initial "source" translations) > 3.2.2.1 XML format (based on XSL-FO?) > 3.2.2.1.1 English language translators (committers) > 3.2.2.2 HTML format (generated) > 3.2.2.3 PDF format (generated, possibly using Apache XML-FOP) > 3.2.2.4+ other document file formats (generated) > 3.2.3+ other spoken languages, similarly > > The main difference between sections (2) and (3) is that (2) is organized > primarily by programming language, with the programming-language-specific > resources as part of the first subsection (2.1) keeping the second section > (2.2) programming-language-neutral, while (3) is organized primarily by > spoken language, with the programming-language-independent file formats as > part of the second subsection (3.2), keeping them separate from the > programming-language-specific stuff in the first subsection (3.1). > > I'd be willing to work on the common code and user interface code, and it > looks like there is a good starting list for the language translators. Is > there anyone willing to drive the second part, the internationalization of > complete documents? > > I can also be update the proposal as indicated above, and then let it be > reviewed/modified here, or in CVS somewhere. In your replies to the mailing > list, please indicate in which of the following ways you might be willing to > contribute: > > A) committer for code for internationalization of user interface and possibly > common code > B) committer for code for internationalization of complete documents and > possibly common code > C) language translation (either or both UI or documents) > D) sponsor entry of Java version of Internationalization subproject into > Jakarta > E) incorporate internationalization into another Apache/Jakarta sub/project > (please specify) > F) none of the above > > Robert Simpson > > Santiago Gala wrote: > > > Robert Simpson escribió: > > > Santiago Gala, > > > > > > As far a document and resource translation, I'm not sure if you are > > > referring to machine translation, or human translation. My focus has > > > been on human translation, mainly because machine translation is > > > still pretty far from perfect. There could be APIs for interfaces to > > > various machine translation tools, such as Systransoft, but I think > > > that should be a later, secondary priority. Even if there was > > > support for machine translation, I would prefer that it could be > > > augmented by human proofreading and revision. So it's probably just > > > as easy to let the language translator use whatever machine > > > translation tool s/he prefers. > > > > > > > David Taylor has already anwered WRT code. > > > > I was thinking mostly about having a "pool" of people who can translate > > and are more or less "cross project". For instance, I can translate > > English to Spanish, and I'm a committer in Jetspeed, but I could also > > translate, say, parts of the tomcat documents that I'm reading, or some > > XML stuff I'm interested into. Or even docs for Apache modules. > > > > The good part is that it would help the whole community, both WRT > > translation efforts and WRT crosspollination, as these kind of people > > will "see" beyond their small project(s). Also, it oculd bring new kinds > > of developers (Today I heard in the radio, coming home, that 72% od > > people in Spain cannot speak *any* foreign language. We are a bad sample > > but in most of Europe, less than 50% people speaks English.) > > > > The problem is that I can't see clearly how to implement such a > > crosscutting service/project, in ways that would not be difficult to > > impossible to manage. Specially since we should keep source control on > > both the original doc and the translations in sync. > > > > Any ideas? > > > > 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] ----------------------------------------------------- Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
