You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Santiago Gala <sg...@hisitech.com> on 2003/07/08 18:32:18 UTC
Re: [i18n] Internationalization subproject sponsor?
Robert Simpson escribió:
> I also fear that if I go back to simply continuing the development of
> the code myself, that eventually the need in Jakarta will be
> recognized, but I will be too far along at that point to convert
> everything to it. Or worse yet, the need will be recognized at
> different times within each Jakarta subproject, resulting in each
> subproject doing internationalization their own way.
>
Jetspeed is already using i18n (or is it l10n?) for most of its strings.
We use the Turbine 2.2 localization service for client specific
ResourceBundles lookup and caching.
I think Tomcat has also some effort already done.
The main problem I see in your proposal is not coding it, but getting
any/some/most of the jakarta projects to use the code, and agree in ways
to handle the files back and forth as the development process
progresses. Also, I think this is not a pure java issue, and looking at
it from the whole Apache might help (as the web sites and the project
documents would also need translation effort).
I think a project which would take care of document and/or Resource
bundle translation, coordinated with each Apache project requiring so
would be a great thing in terms of infrastructure.
I cc: community for insight, since there is much more in Apache than
jakarta (even in the java world, there is a lot of XML people working
in java)
Regards
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by "David N. Welton" <da...@dedasys.com>.
Being a native english speaker, I can't contribute directly to
translations, but I think it would be great to have a coordinated,
apache-wide effort to seek volunteers to translate documentation, and
should projects so desire, messages.
The FSF and Debian, for instance, have been very successful in their
efforts to coordinate translators.
Ciao,
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by Tetsuya Kitahata <te...@apache.org>.
I'll put the original proposal from Robert Simpson below:
I suggested him to come here and to say what he wants to
do in this community@ mail list.
Personally, I do think that the i18n issue is not only related to java
but also to all the *language*s. So, I suggested to him, "you do not
have to adhere to jakarta, IMHO".
Sincerely,
-- Tetsuya (tetsuya@apache.org)
---------------------------------------------------------------------
On 3 Jul 2003 15:23:10 -0000
(Subject: [i18n] Internationalization subproject sponsor?)
Robert Simpson <Ro...@iToolSet.com> wrote:
> To current members of the Jakarta project:
>
> Is there any current member of the Jakarta project who would be interested in
> sponsoring the entry of the Internationalization subproject into the
> incubator?
>
> The Internationalization subproject would be somewhat different than the
> other Jakarta projects in that there would be two types of contributors:
>
> 1. the (traditional) code contributors
> 2. the language translation contributors
>
> So far, the reponses I have received regarding people would would be interested
> in contributing have all been outside Jakarta - mostly language translators.
> Since the Internationalization subproject would most likely fit into the
> Jakarta project, it would help to have a sponsor from within Jakarta, per the
> "Incubation Process" documentation.
>
> The subproject proposal and initial code contribution can be found earlier in
> the Jakarta General mailing list, or here:
> http://www.itoolset.com/i18n/PROPOSAL.html
>
> Without a sponsor, I will probably move the code that was extracted in
> preparation for submission to Apache back into the iToolSet package hierarchy
> and let it pass as an Apache contribution until there is more interest in a
> common Internationalization architecture within Apache itself.
>
> Thanks in advance.
> Robert Simpson
---------------------------------------------------------------------
On Tue, 08 Jul 2003 18:32:18 +0200
(Subject: Re: [i18n] Internationalization subproject sponsor?)
Santiago Gala <sg...@hisitech.com> wrote:
> Robert Simpson escribió:
>
> > I also fear that if I go back to simply continuing the development of
> > the code myself, that eventually the need in Jakarta will be
> > recognized, but I will be too far along at that point to convert
> > everything to it. Or worse yet, the need will be recognized at
> > different times within each Jakarta subproject, resulting in each
> > subproject doing internationalization their own way.
> >
>
> Jetspeed is already using i18n (or is it l10n?) for most of its strings.
> We use the Turbine 2.2 localization service for client specific
> ResourceBundles lookup and caching.
>
> I think Tomcat has also some effort already done.
>
> The main problem I see in your proposal is not coding it, but getting
> any/some/most of the jakarta projects to use the code, and agree in ways
> to handle the files back and forth as the development process
> progresses. Also, I think this is not a pure java issue, and looking at
> it from the whole Apache might help (as the web sites and the project
> documents would also need translation effort).
>
> I think a project which would take care of document and/or Resource
> bundle translation, coordinated with each Apache project requiring so
> would be a great thing in terms of infrastructure.
>
> I cc: community for insight, since there is much more in Apache than
> jakarta (even in the java world, there is a lot of XML people working
> in java)
>
> Regards
> --
> Santiago Gala
> High Sierra Technology, S.L. (http://hisitech.com)
> http://memojo.com?page=SantiagoGalaBlog
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
-----------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: kitahata@bb.mbn.or.jp : tetsuya@apache.org
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject
Posted by Tetsuya Kitahata <te...@apache.org>.
On Mon, 14 Jul 2003 00:46:27 +0100
(Subject: Re: [i18n] Internationalization subproject)
"David Reid" <da...@jetnet.co.uk> wrote:
> FWIW I think that an ASF wide i18n project is a good idea but I think that
> to be a success it must focus on being platform independent from the get-go,
> not do as others have done and start with Java then try to adapt to other
> languages...
Sure.
The precursor is HTTPD-DOCS project, i think.
cf. http://httpd.apache.org/docs-project/
If possible, i want this project to come to i18n (TLP) first...
Reorganization.
> Also it should probably go via the incubator as I doubt it'll stand a chance
> of going straight in as a top level project.
IMO, i18n issue should be the ASF-wide, and no need for incubator
project. I am afraid there are few veteran about 18n issue in incubator
members.
And, to tell the truth, the Robert Simpson's initial proposal (codebase)
will directly go to i18n TLP or be incubated **after** the i18n TLP
launch out.
> Why do you think we don't welcome people from all over the world presently?
Nice question. Very very nice.
I, personally, do not think the ASF do not welcome people from all over
the world relatively. However, there might be more *rooms* of the ASF to
give the *sign* that the ASF is welcoming people from all over the world.
--
1.
Imagine that there are few *language specific* mailing list in
apache.org. i18n TLP can (I think) arrange the language specific
mailing list properly.
... How about jakarta-ja@i18n.apache.org ?? .. where I can talk
the general issues on jakarta in my native language (japanese)
2.
Of course, I know that there are many people who claim, "Hey,
my patch was ignored!", without the esteem for the committers.
However, I also know many patches, which are worthy, from the people
in Asian country had been ignored and they'd come to shut up
their mouths.
In Asia, especially Korea, China and Japan, there are a lot of jakarta
(and other products under ASL) users, however, there seem few feedback
to the ASF from them, even though we take account of the *english
barrier*. Why? .. They feel that it is easier to contribute to
*ASF mirrored sites* (users/dev communities in their native languages)
than *ASF itself*. Or, *just thank to the ASF and use for themselves*
syndrome.
3.
As for language specific mailing list goes, Brian once said,
"I think it would bring non-English-speaking communities closer to the
ASF, rather than encourage them to set up their own islands.",
when I proposed the creation of [japan]-ML *in* apache.org
If i18n TLP launched out, I think these kind of
'language-specific-mailnglist' can reside inside the i18n TLP.
4.
Today, the ASF can not evaluate the activities outside of the ASF
(ASF mirrored) because we can not understand foreign languages.
But, I think ASF mirrored contribution should be evaluated properly by
the ASF and we should appraise their activities.
i18n TLP can provide the ROOMs for us to evaluate the *right*/*active*
persons.
--
Sincerely,
-- Tetsuya (tetsuya@apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject
Posted by David Reid <da...@jetnet.co.uk>.
FWIW I think that an ASF wide i18n project is a good idea but I think that
to be a success it must focus on being platform independent from the get-go,
not do as others have done and start with Java then try to adapt to other
languages...
Also it should probably go via the incubator as I doubt it'll stand a chance
of going straight in as a top level project.
Why do you think we don't welcome people from all over the world presently?
david
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject
Posted by Tetsuya Kitahata <te...@apache.org>.
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 (tetsuya@apache.org)
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 <rs...@verizon.net> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
-----------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: kitahata@bb.mbn.or.jp : tetsuya@apache.org
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [i18n] Internationalization subproject
Posted by Tetsuya Kitahata <te...@apache.org>.
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 (tetsuya@apache.org)
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 <rs...@verizon.net> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
-----------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: kitahata@bb.mbn.or.jp : tetsuya@apache.org
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject
Posted by Robert Simpson <rs...@verizon.net>.
(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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
On 7/11/03 12:36 PM, "Santiago Gala" <sg...@hisitech.com> wrote:
> Robert Simpson escribió:
>>
>
> 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.
>
Now you're talking!
> 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.)
>
+1
> 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.
>
We're trying to do this on POI, we just have a shortage of people. We've
already got the source organization. Anyone who wants to help translate
will be given commit access pretty quickly.
> Any ideas?
>
> Regards
-Andy
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by Santiago Gala <sg...@hisitech.com>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by Robert Simpson <rs...@verizon.net>.
David,
The one-liner you sent (it's a static method rather than a static reference) would not change, but within the Localization class, the localization could be implemented using [i18n]:
private static final ResourceBundleFamily rbf = ResourceBundleFamilyFactory.getForClass/Package(someClass);
I've just started using Velocity, thanks for the tip - looks like a nice feature....
Robert Simpson
David Sean Taylor wrote:
> On Wednesday, July 9, 2003, at 05:17 AM, Robert Simpson wrote:
>
> > Santiago Gala,
> >
> > I haven't seen the Turbine localization service code, but maybe that
> > could be separated out and used as the initial code for the
> > Internationalization project (pretty much what I have done to date
> > with it). Turbine might also provide some of the language
> > translations.... A couple things I like about the code I've
> > provided, is that it's pretty much a one-liner to include resources in
> > a class or package, and that it's a static reference. Is the Turbine
> > approach similar?
> >
> Turbine Localization has been decoupled from Turbine and is now
> available in the Fulcrum subproject.
> Its not a static reference:
>
> String value = Localization.getString(key);
> or
> getString(locale, key);
>
> there are other variations, see
>
> http://jakarta.apache.org/turbine/fulcrum/apidocs/org/apache/fulcrum/
> localization/package-summary.html
>
> The localization service can be accessed from within a Velocity tool,
> nice to look up a localized key named LOCALIZED_NAME from Velocity for
> ex
>
> $localization.LOCALIZED_NAME
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Wednesday, July 9, 2003, at 05:17 AM, Robert Simpson wrote:
> Santiago Gala,
>
> I haven't seen the Turbine localization service code, but maybe that
> could be separated out and used as the initial code for the
> Internationalization project (pretty much what I have done to date
> with it). Turbine might also provide some of the language
> translations.... A couple things I like about the code I've
> provided, is that it's pretty much a one-liner to include resources in
> a class or package, and that it's a static reference. Is the Turbine
> approach similar?
>
Turbine Localization has been decoupled from Turbine and is now
available in the Fulcrum subproject.
Its not a static reference:
String value = Localization.getString(key);
or
getString(locale, key);
there are other variations, see
http://jakarta.apache.org/turbine/fulcrum/apidocs/org/apache/fulcrum/
localization/package-summary.html
The localization service can be accessed from within a Velocity tool,
nice to look up a localized key named LOCALIZED_NAME from Velocity for
ex
$localization.LOCALIZED_NAME
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [i18n] Internationalization subproject sponsor?
Posted by Robert Simpson <rs...@verizon.net>.
Santiago Gala,
I haven't seen the Turbine localization service code, but maybe that could be separated out and used as the initial code for the Internationalization project (pretty much what I have done to date with it). Turbine might also provide some of the language translations.... A couple things I like about the code I've provided, is that it's pretty much a one-liner to include resources in a class or package, and that it's a static reference. Is the Turbine approach similar?
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.
As opposed to something that needs to be "coordinated with each Apache project", the Internationalization subproject should simply provide a common means for Apache projects to provide for internationalization. However, because the language translations for an Apache subproject should probably be distributed with those other subprojects, the InternationalizationLibrary for those subprojects would be included with those subprojects themselves, not the i18n subproject. I think the relationship between the other subprojects and i18n should be loose and unidirectional.
OTOH, the InternationalizationLibrary's included with i18n would be more general application- or industry-specific (security, accounting, medical, etc). Things that would get re-used fairly often.
Robert Simpson
Santiago Gala wrote:
> Robert Simpson escribió:
>
> > I also fear that if I go back to simply continuing the development of
> > the code myself, that eventually the need in Jakarta will be
> > recognized, but I will be too far along at that point to convert
> > everything to it. Or worse yet, the need will be recognized at
> > different times within each Jakarta subproject, resulting in each
> > subproject doing internationalization their own way.
> >
>
> Jetspeed is already using i18n (or is it l10n?) for most of its strings.
> We use the Turbine 2.2 localization service for client specific
> ResourceBundles lookup and caching.
>
> I think Tomcat has also some effort already done.
>
> The main problem I see in your proposal is not coding it, but getting
> any/some/most of the jakarta projects to use the code, and agree in ways
> to handle the files back and forth as the development process
> progresses. Also, I think this is not a pure java issue, and looking at
> it from the whole Apache might help (as the web sites and the project
> documents would also need translation effort).
>
> I think a project which would take care of document and/or Resource
> bundle translation, coordinated with each Apache project requiring so
> would be a great thing in terms of infrastructure.
>
> I cc: community for insight, since there is much more in Apache than
> jakarta (even in the java world, there is a lot of XML people working
> in java)
>
> Regards
> --
> Santiago Gala
> High Sierra Technology, S.L. (http://hisitech.com)
> http://memojo.com?page=SantiagoGalaBlog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org