You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Louis Suarez-Potts <ls...@gmail.com> on 2011/06/17 20:21:38 UTC
Native Language vs l10n
In going over the archives, it occurred to me that a small clarification would be useful.
In OOo-land, we had two sorts of language projects. We had the classic l10n/i18n, which dealt with localization and internationalization. We also had "native-language" projects.
This second sort set up heterotopias where discussions related to joining, contributing, using OpenOffice.org could take place in the person's native language. The idea was to expedite the learning processes and to promote OOo among these linguistic groups, as well as in the regions where the language dominated.
The NL projects (which were later named, "native language confederation") were immensely successful and operated as one of the best marketing and promotion efforts ever. :-)
I see compelling reasons to retain this structure, therefore, as the enduser (of varying degrees of sophistication) benefits immensely from these projects. What's more, the contributor who may later become a developer, also benefits, as the native-language projects lower the bar and make it easier to join the community.
Given the codebase, and given our hopes here, to have a vibrant and sustainable community within Apache, I think the inclusion of these sorts of native language projects is important, and I urge their establishment.
-louis
Re: Native Language vs l10n
Posted by Dave Fisher <da...@comcast.net>.
On Jun 17, 2011, at 12:08 PM, Ian Lynch wrote:
> On 17 June 2011 19:55, Manfred A. Reiter <ma...@gmail.com> wrote:
>
>> Hi Joe, all
>>
>> Am 17.06.2011 20:26, schrieb Joe Schaefer:
>>
>> Whatever ultimately gets created at Apache will require
>>> active oversight by the (P)PMC.
>>>
>>
>
>> 1. does it have to be that way... or are the rules made by man
>>
>
> Maybe delegation is the key. If one PMC member was responsible for the NL
> lists and each list had someone answerable to that person it means there is
> manageable delegation. Those lists are effectively autonomous unless there
> is some real problem which was rare I believe with the old OOo system. Then
> the PMC member steps in.
Ian, Manfred, and Luis - you are all on the proposal and on the PPMC (assuming the paperwork is done.) and you sign up for the private list.
Joe is a project Mentor.
If a group of you and others wants to work on the project by supporting the different language communities then please start. Just keep the ooodev list informed. This page is a little old, but the Jakatra/ASF story might illuminate: http://incubator.apache.org/learn/theapacheway.html
The OOOUSER wiki should be coming soon and it will be there for you to use.
AFAIK that wiki can allow contributions and certainly comments by the user community. That will also need moderation.
In addition, Gavin McDonald in Infrastructure stepped forward while I was querying Infra about Bugzilla vs. JIRA and asked about migrating the user forums.
Everyone has their own special "itch", if user support is yours please "scratch."
Regards,
Dave
>
> --
> Ian
>
> Ofqual Accredited IT Qualifications (The Schools ITQ)
>
> www.theINGOTs.org +44 (0)1827 305940
>
> The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
> Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
> Wales.
Re: Native Language vs l10n
Posted by Joe Schaefer <jo...@yahoo.com>.
Yes, delegation is a very important aspect of Apache
governance. All that's needed is a way for the PMC
to ensure that any resources created for it will continue
to be used properly. It doesn't mean someone has
to actively police the lists, but it does mean someone
on the PMC can distinguish between "a typical conversation"
and say "trading porn links".
----- Original Message ----
> From: Ian Lynch <ia...@gmail.com>
> To: ooo-dev@incubator.apache.org
> Sent: Fri, June 17, 2011 3:08:03 PM
> Subject: Re: Native Language vs l10n
>
> On 17 June 2011 19:55, Manfred A. Reiter <ma...@gmail.com> wrote:
>
> > Hi Joe, all
> >
> > Am 17.06.2011 20:26, schrieb Joe Schaefer:
> >
> > Whatever ultimately gets created at Apache will require
> >> active oversight by the (P)PMC.
> >>
> >
>
> > 1. does it have to be that way... or are the rules made by man
> >
>
> Maybe delegation is the key. If one PMC member was responsible for the NL
> lists and each list had someone answerable to that person it means there is
> manageable delegation. Those lists are effectively autonomous unless there
> is some real problem which was rare I believe with the old OOo system. Then
> the PMC member steps in.
>
> --
> Ian
>
> Ofqual Accredited IT Qualifications (The Schools ITQ)
>
> www.theINGOTs.org +44 (0)1827 305940
>
> The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
> Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
> Wales.
>
Re: Native Language vs l10n
Posted by Ian Lynch <ia...@gmail.com>.
On 17 June 2011 19:55, Manfred A. Reiter <ma...@gmail.com> wrote:
> Hi Joe, all
>
> Am 17.06.2011 20:26, schrieb Joe Schaefer:
>
> Whatever ultimately gets created at Apache will require
>> active oversight by the (P)PMC.
>>
>
> 1. does it have to be that way... or are the rules made by man
>
Maybe delegation is the key. If one PMC member was responsible for the NL
lists and each list had someone answerable to that person it means there is
manageable delegation. Those lists are effectively autonomous unless there
is some real problem which was rare I believe with the old OOo system. Then
the PMC member steps in.
--
Ian
Ofqual Accredited IT Qualifications (The Schools ITQ)
www.theINGOTs.org +44 (0)1827 305940
The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.
Re: Native Language vs l10n
Posted by "Manfred A. Reiter" <ma...@gmail.com>.
Hi Rob,
I don't know how the technical workflow looks like.
I was never involved in creating rollout packages.
Here on the list are a lot of hackers from Hamburg.
They have a lot of experience ;-)
I must refer you to them.
greetings
M.
Am 17.06.2011 22:47, schrieb Rob Weir:
> It will be interesting to see how this works in practice. For example, I
> know that translation will often result in strings that are longer than they
> were in English. This happens when translating to German, for example.
> This might require that a UI be modified to fit the expanded strings.
>
> How would we handle that kind of interaction?
>
> 1) Language project modifies the UI directly and rebuilds the product?
>
> or
>
> 2) Language project is involved, with their liaison, with the Apache project
> throughout the release cycle, and is testing its translations at major
> milestones, beta, etc. And then they are filing defect reports where the UI
> must be updated to accommodate the translation.
>
> There are other possible bugs that can break translations, such as
> hard-coded strings, buffer overflows, number formatting errors, etc. If we
> can do #2, I think that would be best, to find these errors earlier. So
> collaboration with language projects, like with any other stakeholder, will
> work best if we're co-testing at beta milestones or even more frequently.
>
> -Rob
Re: Native Language vs l10n
Posted by Andre Schnabel <An...@gmx.net>.
Hi,
-------- Original-Nachricht --------
> Datum: Fri, 17 Jun 2011 16:47:42 -0400
> Von: Rob Weir <ap...@robweir.com>
> It will be interesting to see how this works in practice. For example, I
> know that translation will often result in strings that are longer than
> they
> were in English. This happens when translating to German, for example.
> This might require that a UI be modified to fit the expanded strings.
Quite easy (that's what we do at TDF).
Supposed a native lang project has trouble with UI, as translated string
is cut in UI, one of the project members should:
- notify general l10n list and ask if other teams have the same problem
or if anyone objects to modify UI
- modify UI and commit the modification (supposed there is someone in the
native lang team with commit rights)
- and/or file a bug, requesting the UI change. Such changes are trivial
and picked up quite fast
see https://bugs.freedesktop.org/show_bug.cgi?id=38007 as example
>
> 2) Language project is involved, with their liaison, with the Apache
> project
> throughout the release cycle, and is testing its translations at major
> milestones, beta, etc. And then they are filing defect reports where the
> UI
> must be updated to accommodate the translation.
what I would be concerned about here is that (as far as I understand)
there might be a dozend people contributing to the translation of a
given language (and this is really a lot of work, as OOo has many many
strings with many many problems) - but as only one or two liason members
are eligible as PMC members (as only those are visible at Apache lists).
I'll answer about the need of native lang (non-english) mailing lists
at some other point in the thread.
André
Re: Native Language vs l10n
Posted by Marcus Lange <ma...@wtnet.de>.
Am 06/17/2011 10:47 PM, schrieb Rob Weir:
> It will be interesting to see how this works in practice. For example, I
> know that translation will often result in strings that are longer than they
> were in English. This happens when translating to German, for example.
> This might require that a UI be modified to fit the expanded strings.
In the past we followed this kind of release schedule. As example for
OOo 3.4:
http://wiki.services.openoffice.org/wiki/OOoRelease34
> How would we handle that kind of interaction?
>
> 1) Language project modifies the UI directly and rebuilds the product?
That would result in a way that every language group has to fix their
language bugs themselves. Either we have to wait for every L10N groups
untilthey are finished, so that we can release all builds at the same
time. Or we release the en-US builds and some weeks later maybe the last
L10N group.
Regardless how it will be done, I don't think that this is what we want,
isn't it?.
> or
>
> 2) Language project is involved, with their liaison, with the Apache project
> throughout the release cycle, and is testing its translations at major
> milestones, beta, etc. And then they are filing defect reports where the UI
> must be updated to accommodate the translation.
Yes, IMHO that should be our way.
However, at the end we had translations for some dozends of languages.
Which of course would result now in dozends of people that are acting as
gateway between the Apache project and the (maybe separated, independent
?) L10N groups.
BTW:
In the very end within the OOO340 release schedule we had implemented a
"continous L10N integration", so that the groups were able to translate
strings and give it back for integration into master at any time. So,
when we had a new feature/UI/string freeze, then only a few strings had
been left to be translated and not the whole bunch of the new features.
This saves time and frustration and was very appreciated by all L10N groups.
> There are other possible bugs that can break translations, such as
> hard-coded strings, buffer overflows, number formatting errors, etc. If we
> can do #2, I think that would be best, to find these errors earlier. So
> collaboration with language projects, like with any other stakeholder, will
> work best if we're co-testing at beta milestones or even more frequently.
For this we had our "L10N CWS builds" testing phase. This means after
the localized strings were handed back, they were integrated into a
special CWS and builds were created from here for testing. Fixes were
done in the CWS and at the end this CWS was integrated into master to
create localized release builds.
Marcus
> On Fri, Jun 17, 2011 at 4:33 PM, Manfred A. Reiter<ma...@gmail.com>wrote:
>
>> Hi Danese,
>>
>> Am 17.06.2011 21:57, schrieb Danese Cooper:
>>
>> +1
>>>
>>> This proposal sounds workable to me. Of course part of Manfred's point
>>> was
>>> that there are also "core" l10n/i18n activities that would presumably now
>>> happen at Apache within the core project. IMHO, the language projects
>>> will
>>> find Apache a much more open "upstream" than were Sun/Oracle. Should make
>>> things very nice once we actually get up and running.
>>>
>>> OOo will be a different project to most everything else at Apache today
>>> (including huge and already well-organized contributor communities who
>>> need
>>> to continue to move forward as we re-rig things). Hopefully someday we'll
>>> have enough in place to offer services to some of them that would make
>>> sense
>>> and more of them will find their way in.
>>>
>>> D
>>>
>>
>> happy to see that you got my point ;-)
>>
>> M.
Re: Native Language vs l10n
Posted by Donald Whytock <dw...@gmail.com>.
How about language-spanning yet language-specific features such as
right-to-left characters, multi-key characters, etc? Would this sort
of requirement or issue area potentially start in a language group,
get bumped to dev, and then propogated out to the language groups to
test and feedback on?
Don
On Fri, Jun 17, 2011 at 4:47 PM, Rob Weir <ap...@robweir.com> wrote:
> It will be interesting to see how this works in practice. For example, I
> know that translation will often result in strings that are longer than they
> were in English. This happens when translating to German, for example.
> This might require that a UI be modified to fit the expanded strings.
>
> How would we handle that kind of interaction?
>
> 1) Language project modifies the UI directly and rebuilds the product?
>
> or
>
> 2) Language project is involved, with their liaison, with the Apache project
> throughout the release cycle, and is testing its translations at major
> milestones, beta, etc. And then they are filing defect reports where the UI
> must be updated to accommodate the translation.
>
> There are other possible bugs that can break translations, such as
> hard-coded strings, buffer overflows, number formatting errors, etc. If we
> can do #2, I think that would be best, to find these errors earlier. So
> collaboration with language projects, like with any other stakeholder, will
> work best if we're co-testing at beta milestones or even more frequently.
>
> -Rob
>
> On Fri, Jun 17, 2011 at 4:33 PM, Manfred A. Reiter <ma...@gmail.com>wrote:
>
>> Hi Danese,
>>
>> Am 17.06.2011 21:57, schrieb Danese Cooper:
>>
>> +1
>>>
>>> This proposal sounds workable to me. Of course part of Manfred's point
>>> was
>>> that there are also "core" l10n/i18n activities that would presumably now
>>> happen at Apache within the core project. IMHO, the language projects
>>> will
>>> find Apache a much more open "upstream" than were Sun/Oracle. Should make
>>> things very nice once we actually get up and running.
>>>
>>> OOo will be a different project to most everything else at Apache today
>>> (including huge and already well-organized contributor communities who
>>> need
>>> to continue to move forward as we re-rig things). Hopefully someday we'll
>>> have enough in place to offer services to some of them that would make
>>> sense
>>> and more of them will find their way in.
>>>
>>> D
>>>
>>
>> happy to see that you got my point ;-)
>>
>> M.
>>
>
Re: Native Language vs l10n
Posted by Rob Weir <ap...@robweir.com>.
It will be interesting to see how this works in practice. For example, I
know that translation will often result in strings that are longer than they
were in English. This happens when translating to German, for example.
This might require that a UI be modified to fit the expanded strings.
How would we handle that kind of interaction?
1) Language project modifies the UI directly and rebuilds the product?
or
2) Language project is involved, with their liaison, with the Apache project
throughout the release cycle, and is testing its translations at major
milestones, beta, etc. And then they are filing defect reports where the UI
must be updated to accommodate the translation.
There are other possible bugs that can break translations, such as
hard-coded strings, buffer overflows, number formatting errors, etc. If we
can do #2, I think that would be best, to find these errors earlier. So
collaboration with language projects, like with any other stakeholder, will
work best if we're co-testing at beta milestones or even more frequently.
-Rob
On Fri, Jun 17, 2011 at 4:33 PM, Manfred A. Reiter <ma...@gmail.com>wrote:
> Hi Danese,
>
> Am 17.06.2011 21:57, schrieb Danese Cooper:
>
> +1
>>
>> This proposal sounds workable to me. Of course part of Manfred's point
>> was
>> that there are also "core" l10n/i18n activities that would presumably now
>> happen at Apache within the core project. IMHO, the language projects
>> will
>> find Apache a much more open "upstream" than were Sun/Oracle. Should make
>> things very nice once we actually get up and running.
>>
>> OOo will be a different project to most everything else at Apache today
>> (including huge and already well-organized contributor communities who
>> need
>> to continue to move forward as we re-rig things). Hopefully someday we'll
>> have enough in place to offer services to some of them that would make
>> sense
>> and more of them will find their way in.
>>
>> D
>>
>
> happy to see that you got my point ;-)
>
> M.
>
Re: Native Language vs l10n
Posted by "Manfred A. Reiter" <ma...@gmail.com>.
Hi Danese,
Am 17.06.2011 21:57, schrieb Danese Cooper:
> +1
>
> This proposal sounds workable to me. Of course part of Manfred's point was
> that there are also "core" l10n/i18n activities that would presumably now
> happen at Apache within the core project. IMHO, the language projects will
> find Apache a much more open "upstream" than were Sun/Oracle. Should make
> things very nice once we actually get up and running.
>
> OOo will be a different project to most everything else at Apache today
> (including huge and already well-organized contributor communities who need
> to continue to move forward as we re-rig things). Hopefully someday we'll
> have enough in place to offer services to some of them that would make sense
> and more of them will find their way in.
>
> D
happy to see that you got my point ;-)
M.
Re: Native Language vs l10n
Posted by Danese Cooper <da...@gmail.com>.
+1
This proposal sounds workable to me. Of course part of Manfred's point was
that there are also "core" l10n/i18n activities that would presumably now
happen at Apache within the core project. IMHO, the language projects will
find Apache a much more open "upstream" than were Sun/Oracle. Should make
things very nice once we actually get up and running.
OOo will be a different project to most everything else at Apache today
(including huge and already well-organized contributor communities who need
to continue to move forward as we re-rig things). Hopefully someday we'll
have enough in place to offer services to some of them that would make sense
and more of them will find their way in.
D
On Fri, Jun 17, 2011 at 12:49 PM, Rob Weir <ap...@robweir.com> wrote:
> On Fri, Jun 17, 2011 at 2:55 PM, Manfred A. Reiter <ma.reiter@gmail.com
> >wrote:
>
> 1) Strong existing language projects continue to operate independently,
> according to their own rules.
>
> 2) They ensure that their work is all done under Apache 2.0 license so it
> is
> usable by Apache OpenOffice as well as by LibreOffice
>
> 3) Language projects each appoint at least one member to join the Apache
> OpenOffice project as a liaison.
>
>
> -Rob
>
Re: Native Language vs l10n
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 17, 2011 at 16:28, Manfred A. Reiter <ma...@gmail.com> wrote:
>...
> IF a spelling mistake and a correction of the same in <Klingon - or your
> favorite language> is actually core development, that needs to be covered by
> a full blown PMC
> then you probably need a round of refactoring in the core ;-).
If it ends up in an Apache release, then yes: it needs to be overseen
by an Apache PMC. That isn't hard, nor is it a big deal... we're "the
PMC". So if we make the commit, then we're basically done.
>...
Cheers,
-g
Re: Native Language vs l10n
Posted by "Manfred A. Reiter" <ma...@gmail.com>.
Am 18.06.2011 11:23, schrieb Andrea Pescetti:
> Manfred A. Reiter wrote:
>> I would also avoid to deny those language projects to be
>> seperated from Apache.org ... in other words /home should
>> be at lang-klingon.ooo.apache.org and not oooinklingon.org
> Right (the example; the wording above seems to say the opposite): the
> native-lang projects are part of openoffice.org.
ok, sorry for misunderstandig ... (I thought it is a double negation)
but it's fine that the example is unambiguous
<http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=unambiguous&trestr=0x8004>
> The Italian N-L project, for example, takes care of:
> - Translating OOo into Italian (a few liaison persons keep contacts
> with the global l10n project, and coordinate volunteers on the
> Italian N-L mailing list)
> - Releasing OOo in Italian by means of QA approval (same structure)
> - Mutual support between users in Italian (mailing list and forum
> in Italian on the OOo infrastructure)
> - A web site it.openoffice.org with product information in Italian.
>
> I think there should be a place for this in the new infrastructure.
>
> About other activities:
> - Maintaining the Italian writing aids is done by me and PLIO, the
> Italian association, and could continue like this.
> - Italian developers interested in core work write in English on the
> English mailing lists.
> - Media relations, events and fund-raising are managed through PLIO and
> this, again, could continue like this.
>
> So we are basically using the OOo infrastructure for activities related
> to the language and (besides writing aids) we use the PLIO
> infrastructure for the rest.
>
> Regards,
> Andrea.
>
Yes to all above.
M.
Re: Native Language vs l10n
Posted by Andrea Pescetti <pe...@openoffice.org>.
Manfred A. Reiter wrote:
> I would also avoid to deny those language projects to be
> seperated from Apache.org ... in other words /home should
> be at lang-klingon.ooo.apache.org and not oooinklingon.org
Right (the example; the wording above seems to say the opposite): the
native-lang projects are part of openoffice.org.
The Italian N-L project, for example, takes care of:
- Translating OOo into Italian (a few liaison persons keep contacts
with the global l10n project, and coordinate volunteers on the
Italian N-L mailing list)
- Releasing OOo in Italian by means of QA approval (same structure)
- Mutual support between users in Italian (mailing list and forum
in Italian on the OOo infrastructure)
- A web site it.openoffice.org with product information in Italian.
I think there should be a place for this in the new infrastructure.
About other activities:
- Maintaining the Italian writing aids is done by me and PLIO, the
Italian association, and could continue like this.
- Italian developers interested in core work write in English on the
English mailing lists.
- Media relations, events and fund-raising are managed through PLIO and
this, again, could continue like this.
So we are basically using the OOo infrastructure for activities related
to the language and (besides writing aids) we use the PLIO
infrastructure for the rest.
Regards,
Andrea.
Re: Native Language vs l10n
Posted by IngridvdM <In...@gmx-topmail.de>.
Am 17.06.2011 23:15, schrieb Dave Fisher:
[...]
>
> I like Rob's very direct 3 points. I would edit the language slightly.
>
> Strike the words "Strong existing" from 1) - the language project should not need to think about how strong they are - strong has differing cultural interpretations.
>
> For 3) "as a liaison" ought to be dropped. Everyone joins as an individual. Many of us might consider that we came here as liaisons, but that is not always the case.
>
> Language projects
> - continue to operate independently according to their own rules.
> - ensure their work is done under the Apache 2.0 license so that it is usable by Apache OpenOffice as well as LibreOffice.
> - appoint at least one member to join the Apache OpenOffice project.
>
> There are a couple of implicit "musts" on 1 or 2 that might be culturally insensitive... This needs to be a well nuanced message IIRC Sally Khudairi's marketing 101 from Apachecon. Mentors - should we get Sally involved in the nuance, or not?
>
> The language needs to be as healing as possible. Language projects shouldn't feel abandoned either. I'm feeling like I'm working here for a second: http://gawker.com/5812622/working-at-the-apple-store-tales-from-the-inside
>
Good points. I feel the same need for care here.
Especially when we start voting I would like to step a big step back. I
think the different ideas of working together need to be offered to each
language community as suggestions. Then it needs to be discussed there.
And they will decide each on their own what they want to do.
I think it is fine to vote here one what we think could be a possible or
a preferred cooperation.
Ingrid
Re: Native Language vs l10n
Posted by Dave Fisher <da...@comcast.net>.
On Jun 17, 2011, at 1:28 PM, Manfred A. Reiter wrote:
> Dear Rob,
>
> Am 17.06.2011 21:49, schrieb Rob Weir:
>> On Fri, Jun 17, 2011 at 2:55 PM, Manfred A. Reiter<ma...@gmail.com>wrote:
>>> Can you understand, that due to the nature of OOo it always
>>> had very strong language specific communities, wich significantly
>>> contributed to the huge success of OOo?
>>>
>>> Interfering with the habits and cultures established within these
>>> communties will in fact not take you any further than somebody
>>> can say "we obeyed the Apache standard rules".
>>>
>>> The power of local communites which can act independently,
>>> has proven to be especially usefull in these areas were competing
>>> products simply couldn't offer a "consumer focused" localised solution.
>>>
>>> I'm just worried that you will alienate some very active contributors
>>> by enforcing PMC rules just ... "because ..."
>>>
>> For things that impact the product release, things like code contributions,
>> documentation, translations, etc., things that actually could make the bits
>> and bytes of the release different, I think it is very important that these
>> pieces are done in Apache. And by being in the Apache project, they are
>> covered by the Apache 2.0 license and by our consensus decision making
>> process.
> never questioned that.
>
> IF a spelling mistake and a correction of the same in <Klingon - or your favorite language> is actually core development, that needs to be covered by a full blown PMC
> then you probably need a round of refactoring in the core ;-).
>
>> For the activities that do not impact the actual contents of the release,
>> things like user support, country- or language-specific marketing activities
>> and so on, for these I could see other models working as well.
>
> you got it!
>
>> Remember,
>> with any Apache project, anyone is free to take the project's source code,
>> translate it, build it and market it or even sell it. This could be done
>> with modifications and enhancements. This is all possible under the Apache
>> 2.0 license, whether you participate in the project or not.
>>
> ack
>> So if there are existing groups that do such activities under Sun/Oracle
>> OpenOffice.org, then they can continue to do so, by using Apache OpenOffice.
>> But when we start talking about the Apache project, then we are not talking
>> about "groups" joining. We're talking about individuals joining.
> got that during last discussions ;-)
>
>> I don't
>> think we want to have independent, autonomous groups within an Apache
>> project.
>>
> neither do I
>
>> But I wonder whether one solution is this:
>>
>> 1) Strong existing language projects continue to operate independently,
>> according to their own rules.
> exactly my point
>
>> 2) They ensure that their work is all done under Apache 2.0 license so it is
>> usable by Apache OpenOffice as well as by LibreOffice
>>
>> 3) Language projects each appoint at least one member to join the Apache
>> OpenOffice project as a liaison.
(deleting 3 drafts to earlier messages in this thread.)
I like Rob's very direct 3 points. I would edit the language slightly.
Strike the words "Strong existing" from 1) - the language project should not need to think about how strong they are - strong has differing cultural interpretations.
For 3) "as a liaison" ought to be dropped. Everyone joins as an individual. Many of us might consider that we came here as liaisons, but that is not always the case.
Language projects
- continue to operate independently according to their own rules.
- ensure their work is done under the Apache 2.0 license so that it is usable by Apache OpenOffice as well as LibreOffice.
- appoint at least one member to join the Apache OpenOffice project.
There are a couple of implicit "musts" on 1 or 2 that might be culturally insensitive... This needs to be a well nuanced message IIRC Sally Khudairi's marketing 101 from Apachecon. Mentors - should we get Sally involved in the nuance, or not?
The language needs to be as healing as possible. Language projects shouldn't feel abandoned either. I'm feeling like I'm working here for a second: http://gawker.com/5812622/working-at-the-apple-store-tales-from-the-inside
:-)
+1 if the message is spun up and nuanced.
There are more pieces to an announcement, I think we owe the community some message by late next week.
> that could do the trick ...
>
> but I would avoid to force grown and working communities
> under a gonvernance process they don't need.
>
> I would also avoid to deny those language projects to be
> seperated from Apache.org ... in other words /home should
> be at lang-klingon.ooo.apache.org and not oooinklingon.org
> that will cause confusion, and is not very smart marketingwise.
On the project website we can keep a roster of known Language projects with a registration form.
Happy Friday everyone :-)
Best Regards,
Dave
>
>
>
> cheers
>
> Manfred
Re: Native Language vs l10n
Posted by "Manfred A. Reiter" <ma...@gmail.com>.
Dear Rob,
Am 17.06.2011 21:49, schrieb Rob Weir:
> On Fri, Jun 17, 2011 at 2:55 PM, Manfred A. Reiter<ma...@gmail.com>wrote:
>> Can you understand, that due to the nature of OOo it always
>> had very strong language specific communities, wich significantly
>> contributed to the huge success of OOo?
>>
>> Interfering with the habits and cultures established within these
>> communties will in fact not take you any further than somebody
>> can say "we obeyed the Apache standard rules".
>>
>> The power of local communites which can act independently,
>> has proven to be especially usefull in these areas were competing
>> products simply couldn't offer a "consumer focused" localised solution.
>>
>> I'm just worried that you will alienate some very active contributors
>> by enforcing PMC rules just ... "because ..."
>>
> For things that impact the product release, things like code contributions,
> documentation, translations, etc., things that actually could make the bits
> and bytes of the release different, I think it is very important that these
> pieces are done in Apache. And by being in the Apache project, they are
> covered by the Apache 2.0 license and by our consensus decision making
> process.
never questioned that.
IF a spelling mistake and a correction of the same in <Klingon - or your
favorite language> is actually core development, that needs to be
covered by a full blown PMC
then you probably need a round of refactoring in the core ;-).
> For the activities that do not impact the actual contents of the release,
> things like user support, country- or language-specific marketing activities
> and so on, for these I could see other models working as well.
you got it!
> Remember,
> with any Apache project, anyone is free to take the project's source code,
> translate it, build it and market it or even sell it. This could be done
> with modifications and enhancements. This is all possible under the Apache
> 2.0 license, whether you participate in the project or not.
>
ack
> So if there are existing groups that do such activities under Sun/Oracle
> OpenOffice.org, then they can continue to do so, by using Apache OpenOffice.
> But when we start talking about the Apache project, then we are not talking
> about "groups" joining. We're talking about individuals joining.
got that during last discussions ;-)
> I don't
> think we want to have independent, autonomous groups within an Apache
> project.
>
neither do I
> But I wonder whether one solution is this:
>
> 1) Strong existing language projects continue to operate independently,
> according to their own rules.
exactly my point
> 2) They ensure that their work is all done under Apache 2.0 license so it is
> usable by Apache OpenOffice as well as by LibreOffice
>
> 3) Language projects each appoint at least one member to join the Apache
> OpenOffice project as a liaison.
that could do the trick ...
but I would avoid to force grown and working communities
under a gonvernance process they don't need.
I would also avoid to deny those language projects to be
seperated from Apache.org ... in other words /home should
be at lang-klingon.ooo.apache.org and not oooinklingon.org
that will cause confusion, and is not very smart marketingwise.
cheers
Manfred
Re: Native Language vs l10n
Posted by Louis Suarez-Potts <ls...@gmail.com>.
Hi
On 2011-06-17, at 15:49 , Rob Weir wrote:
> 3) Language projects each appoint at least one member to join the Apache
> OpenOffice project as a liaison.
Let's see. The reason we didn't opt for this solution with OOo is because we had a conceivably *huge* number, and as it is, have probably something like about 100, not all of which are still current. Rob's suggestion of criteria put in play is therefore crucial. At OOo, we opted for representatives to body the NLC. Other solutions are obviously possible. Really, my interest lies in promoting a) contribution, b) development, c) market expansion, all with a minimum of fuss and max. of fun.
-louis
Re: Native Language vs l10n
Posted by Maho NAKATA <ch...@mac.com>.
From: Kazunari Hirano <kh...@gmail.com>
Subject: Re: Native Language vs l10n
Date: Sun, 19 Jun 2011 10:20:06 +0900
> Hi Dennis and all,
>
> On Sun, Jun 19, 2011 at 7:08 AM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Hello, Khirano-san (that OK with nickname/UserID?),
> OK :) See the bottom of this mail.
>
>> I was wondering if SVN and Bugzilla infrastructure could be in separate Internet site
>> from Japanese Language Project (or vice versa).
> I see. But I can not answer this question immediately.
> I would like to discuss the question with Maho Nakata, Japanese
> Language Project Lead.
> Please give me time.
Hi Dennis,
I am the project lead of ja.openoffice.org and qa.openoffice.org.
JA used "cvs" instead of "svn", anyway they are the same meaning in this case.
We (or over 100 of every native language project) managed our web page
using SVN. These are projects within OpenOffice.org, so we should not work
separately. English speaking community cannot handle everything, especially
translation, quality assurance, documentation and marketing.
I think Bugzilla can be worked separately. In JA project, if someone found an issue
to that project, then fill the Bugzilla. However, these were rarely filed, or mistakingly
filed. If I remember correctly, ES community make use of Bugzilla for assigning
task to community members to see what is the status. This is a good/correct use of Bugzilla.
I think such use of Bugzilla is not popular, as there are relatively small numbers of
people who can commit, and when casual participants find errors on the web page etc,
these committers have fix these errors ASAP.
thanks
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt
Re: Native Language vs l10n
Posted by Kazunari Hirano <kh...@gmail.com>.
Hi Dennis and all,
On Sun, Jun 19, 2011 at 7:08 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Hello, Khirano-san (that OK with nickname/UserID?),
OK :) See the bottom of this mail.
> I was wondering if SVN and Bugzilla infrastructure could be in separate Internet site
> from Japanese Language Project (or vice versa).
I see. But I can not answer this question immediately.
I would like to discuss the question with Maho Nakata, Japanese
Language Project Lead.
Please give me time.
Thanks,
khirano
[OT] === Japanese "-san" usage ===
"-san" is written "さん" in Japanese Hiragana.
If you read Japanese emails, you will see "さん" in almost every mail.
"-san" is very useful postfix to a name in Japanese society, in
Japanese communication, among or between Japanese persons.
You can show politeness, friendship and respect to a person you are
talking to by calling his/her name with "-san."
In Japan when you meet someone for the first time, it is "safe" to
call him/her "Last name + san." And you can keep using it all the time
when you talk to him/her. You also can use "-san" the same way in
business communication.
"Last name + san" is very useful in Japan.
Suppose I meet for the first time a Japanese whose last name is
"Fujisawa" and first name is "Shuhei."
My last name is "Hirano" and my first name is "Kazunari."
When I introduce myself to him, I say "I am Hirano Kazunari."
I don't say "I am Kazunari Hirano."
He may introduce himself "I am Fujisawa Shuhei."
Then I may say "Nice to see you, Fujisawa Shuhei san, where are you from?"
You see, "-san" is a very flexible postfix.
My neighbors call me, "Hirano-san."
If they call me, "Hirano Kazunari san" or "Kazunari san," it's ok, no
problem, I am fine with it.
My mother calls me "Kazunari!"
I say "Yes, Mom! I'll be right over there very quick!"
:)
My aunts call me "Kaz."
My old friends call me "Nari."
My friends from school call me "Hirano."
"Khirano" is my nickname/UserID/account name for Internet, email or
online community world like here.
It's OK that you call me "Hi Khirano" or "Hi Khirano san" in "writing."
But in real-life conversation it may be difficult to pronounce "Khirano."
Even me don't know how to pronounce "Khirano."
:)
Can you pronounce "orcmid," Dennis san?
I find your id and full name here.
http://people.apache.org/committer-index.html
orcmid, Dennis E. Hamilton.
I may write emails to you starting with:
"Hi orcmid san"
"Hi Dennis san"
"Hi E. san"
"HI Hamilton san"
:)
But you see, "orcmid" doesn't sound to me, I think, or does it sound?
How about "E.", does it sound, "ee period"?
:)
"Dennis san" and "Hamilton san" sound good, don't they?
:)
I thought I can call you in writing "Hi Dennis" since we are working
together in this incubator project and getting to know each other, and
we can be frank.
If I meet you somewhere on the earth, I greet you "Hi Dennis," is it OK?
:)
Thanks,
khirano
RE: Native Language vs l10n
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Hello, Khirano-san (that OK with nickname/UserID?),
> I see ja project issues in the combined Bugzilla issue tracker.
> The SVN and Bugzilla infrastructure seems to be in English.
> Could this work separately?
Sorry but I don't see what "this work" is. Which work? :)
I was wondering if SVN and Bugzilla infrastructure could be in separate Internet site from Japanese Language Project (or vice versa). I think you answered well with later question.
Thank you for your detailed response. It is very helpful.
Regards,
- Dennis
-----Original Message-----
From: Kazunari Hirano [mailto:khirano@gmail.com]
Sent: Saturday, June 18, 2011 13:50
To: ooo-dev@incubator.apache.org
Subject: Re: Native Language vs l10n
Hi Dennis and all,
I would like to answer Dennis' questions :)
On Sat, Jun 18, 2011 at 5:30 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> On ooo-dev we are talking now about how to support language communities.
Thanks!
> Please help my understanding. I am ignorant. I have too many questions. Answer in parts may be good.
I am happy to answer your questions.
> Does the Japanese Language Project do any work to prepare distributions for the Japanese Language community? Could it do so?
Yes, we do, and Yes, we could if we have enough resources to do it.
As you may know, "distributions" doesn't mean just building
OpenOffice.org installsets and langpacks and uploading them to the
server.
and say "Use it!" :)
I am proud of ja members maintaining this page :)
http://wiki.services.openoffice.org/wiki/Product_Release/builds_uploaded
The most recent entry is 13-Apr-2011, OOo 3.4 beta, OOO340_m0, as you see.
The most recent stable version 3.3.0 was released on 27-Jan-2011.
Now can you find when 3.3.0 beta1 was released?
It was on 10-Aug-2010, OOo-Dev 3.3.0 beta1, OOO330_m3, as you see.
Between the 3.3.0 beta1 (27-Jan-2011) and the 3.3.0 release
(10-Aug-2010), how many RCs do you count?
RC is Release Candidate :) Did you count RC10? Good. You are correct :)
RC10! During RC time we did QA (Quality Assurance) tests.
http://wiki.services.openoffice.org/wiki/JA/QA/Release/3.3.0#.E6.8B.85.E5.BD.93.E8.80.85
We made clear when who does and did what (excerpt):
1. Ja QA manager appointed, 2009/8/3
2. 3.3.0 QA wiki page created, 2010/10/19
3. 3.3.0 QA forum set up, 2010/10/19
4. Release stopper issue noticed, 2010/10/18
5. Release candidate builds noticed, 2010/10/20, 10/26
6. Submit builds to QATrack, 2010/10/23
7. Call for QA testers (volunteers), 2010/10/27
8. QA IRC meeting
9. QA test started
10, QA test results reported, 2011/1/30
11. Distribution request issue filed, 2011/1/30
12. Announce the end of QA test at the forum
13. Announce the end of QA test to the ja announce list
14. 3.3.0 release announcement draft, 2011/1/30
15. Translate 3.3.0 English PR and announce it, 2011/2/1
16. Update the Ja download page, 2011/2/2 http://ja.openoffice.org/download/
17. Update the Ja top page, 2011/2/2 http://ja.openoffice.org/
18. Confirm the download page and the top page work well, 2011/2/2
19. Annouce 3.3.0 ja release at announce@ja.openoffice.org, 2011/2/2
http://wiki.services.openoffice.org/wiki/PressReleases
20. Confirm the ja update page at http://update.services.openoffice.org/ooo/
21. Add the 3.3.0 QA to Ja QA history on http://ja.openoffice.org/qa/
We used many tools such as Issue Tracker, Mailing lists, Forum,
QATrack, QUASTe, WIKI, TCM to have QA works done and release quality
OpenOffice.org 3.3.0 Japanese builds, installsets and langpacks.
If you want to learn about tools above, go to http://qa.openoffice.org/
And 3.3.0 ja QA test matrix here.
http://wiki.services.openoffice.org/wiki/JA/QA/Release/3.3.0/Issues#.E3.83.AA.E3.83.AA.E3.83.BC.E3.82.B9.E5.93.81.E8.B3.AA.E4.BF.9D.E8.A8.BC.E3.83.9E.E3.83.88.E3.83.AA.E3.83.83.E3.82.AF.E3.82.B9
We were lucky when we did 3.3.0 QA because we had many testers
(volunteers) and we had a vigorous QA manager.
:)
The Japanese Language Project can do some work to prepare
distributions for the Japanese Language community if we have tools on
a stable infrastructure and we are lucky enough to get resources
(volunteers).
> Does it provide the translation work for the distribution?
Yes, we do.
http://wiki.services.openoffice.org/wiki/JA/translation/3.3
We provided the translation for OpenOffice.org 3.3.0
We couldn't provide the translation for OpenOffice.org 3.4.0 because
we had no resource.
> Is all of the release internationalization done in the language pack?
If you mean localization of User Interface and Online Help, yes they
are in the language pack.
We translate them into our native language on Pootle.
http://wiki.services.openoffice.org/wiki/Pootle_User_Guide
> I see http://ja.openoffice.org
> http://ja.openoffice.org/howtoparticipate.html
> I see openoffice.org SVN subtree for the JA language project.
> I see ja project issues in the combined Bugzilla issue tracker.
> The SVN and Bugzilla infrastructure seems to be in English.
> Could this work separately?
Sorry but I don't see what "this work" is. Which work? :)
> I also see
> http://ftp-srv2.kddilabs.jp/office/openoffice/localized/ja/3.3.0/
> I think this is mirror of
> ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/
> Yes?
I think ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/ is
also one of mirror sites.
http://distribution.openoffice.org/mirrors/#mirrors
:)
> What is your thinking about parts of Japanese language project working separate from Apache development? About coordination of language pack and Apache release and QA? About ways to avoid delays in release to users in language communities?
I don't know the separation works :)
If you take a look at the directory in the mirror, you will find the
following builds.
ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/
OOo_3.3.0_Linux_x86-64_install-deb_ja.tar.gz
OOo_3.3.0_Linux_x86-64_install-rpm-wJRE_ja.tar.gz
OOo_3.3.0_Linux_x86-64_langpack-rpm_ja.tar.gz
OOo_3.3.0_Linux_x86_install-deb_ja.tar.gz
OOo_3.3.0_Linux_x86_install-rpm-wJRE_ja.tar.gz
OOo_3.3.0_Linux_x86_install-rpm_ja.tar.gz
OOo_3.3.0_Linux_x86_langpack-deb_ja.tar.gz
OOo_3.3.0_Linux_x86_langpack-rpm_ja.tar.gz
OOo_3.3.0_MacOS_PPC_install_ja.dmg
OOo_3.3.0_MacOS_x86_install_ja.dmg
OOo_3.3.0_MacOS_x86_langpack_ja.dmg
OOo_3.3.0_Solaris_Sparc_install-wJRE_ja.tar.gz
OOo_3.3.0_Solaris_Sparc_langpack_ja.tar.gz
OOo_3.3.0_Solaris_x86_install-wJRE_ja.tar.gz
OOo_3.3.0_Solaris_x86_langpack_ja.tar.gz
OOo_3.3.0_Win_x86_install-wJRE_ja.exe
OOo_3.3.0_Win_x86_install_ja.exe
OOo_3.3.0_Win_x86_langpack_ja.exe
We QA-tested them and approved them to be released and uploaded to the server.
You see three kinds of builds for each platform.
_install-wJRE_ja, _install_ja and _langpack_ja.
_langpack_ja is integrated in _install-wJRE_ja and _install_ja.
I think a "language project" as a whole should get involved in Apache
release and QA.
Thanks,
khirano
Re: Native Language vs l10n
Posted by Kazunari Hirano <kh...@gmail.com>.
Hi Dennis and all,
I would like to answer Dennis' questions :)
On Sat, Jun 18, 2011 at 5:30 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> On ooo-dev we are talking now about how to support language communities.
Thanks!
> Please help my understanding. I am ignorant. I have too many questions. Answer in parts may be good.
I am happy to answer your questions.
> Does the Japanese Language Project do any work to prepare distributions for the Japanese Language community? Could it do so?
Yes, we do, and Yes, we could if we have enough resources to do it.
As you may know, "distributions" doesn't mean just building
OpenOffice.org installsets and langpacks and uploading them to the
server.
and say "Use it!" :)
I am proud of ja members maintaining this page :)
http://wiki.services.openoffice.org/wiki/Product_Release/builds_uploaded
The most recent entry is 13-Apr-2011, OOo 3.4 beta, OOO340_m0, as you see.
The most recent stable version 3.3.0 was released on 27-Jan-2011.
Now can you find when 3.3.0 beta1 was released?
It was on 10-Aug-2010, OOo-Dev 3.3.0 beta1, OOO330_m3, as you see.
Between the 3.3.0 beta1 (27-Jan-2011) and the 3.3.0 release
(10-Aug-2010), how many RCs do you count?
RC is Release Candidate :) Did you count RC10? Good. You are correct :)
RC10! During RC time we did QA (Quality Assurance) tests.
http://wiki.services.openoffice.org/wiki/JA/QA/Release/3.3.0#.E6.8B.85.E5.BD.93.E8.80.85
We made clear when who does and did what (excerpt):
1. Ja QA manager appointed, 2009/8/3
2. 3.3.0 QA wiki page created, 2010/10/19
3. 3.3.0 QA forum set up, 2010/10/19
4. Release stopper issue noticed, 2010/10/18
5. Release candidate builds noticed, 2010/10/20, 10/26
6. Submit builds to QATrack, 2010/10/23
7. Call for QA testers (volunteers), 2010/10/27
8. QA IRC meeting
9. QA test started
10, QA test results reported, 2011/1/30
11. Distribution request issue filed, 2011/1/30
12. Announce the end of QA test at the forum
13. Announce the end of QA test to the ja announce list
14. 3.3.0 release announcement draft, 2011/1/30
15. Translate 3.3.0 English PR and announce it, 2011/2/1
16. Update the Ja download page, 2011/2/2 http://ja.openoffice.org/download/
17. Update the Ja top page, 2011/2/2 http://ja.openoffice.org/
18. Confirm the download page and the top page work well, 2011/2/2
19. Annouce 3.3.0 ja release at announce@ja.openoffice.org, 2011/2/2
http://wiki.services.openoffice.org/wiki/PressReleases
20. Confirm the ja update page at http://update.services.openoffice.org/ooo/
21. Add the 3.3.0 QA to Ja QA history on http://ja.openoffice.org/qa/
We used many tools such as Issue Tracker, Mailing lists, Forum,
QATrack, QUASTe, WIKI, TCM to have QA works done and release quality
OpenOffice.org 3.3.0 Japanese builds, installsets and langpacks.
If you want to learn about tools above, go to http://qa.openoffice.org/
And 3.3.0 ja QA test matrix here.
http://wiki.services.openoffice.org/wiki/JA/QA/Release/3.3.0/Issues#.E3.83.AA.E3.83.AA.E3.83.BC.E3.82.B9.E5.93.81.E8.B3.AA.E4.BF.9D.E8.A8.BC.E3.83.9E.E3.83.88.E3.83.AA.E3.83.83.E3.82.AF.E3.82.B9
We were lucky when we did 3.3.0 QA because we had many testers
(volunteers) and we had a vigorous QA manager.
:)
The Japanese Language Project can do some work to prepare
distributions for the Japanese Language community if we have tools on
a stable infrastructure and we are lucky enough to get resources
(volunteers).
> Does it provide the translation work for the distribution?
Yes, we do.
http://wiki.services.openoffice.org/wiki/JA/translation/3.3
We provided the translation for OpenOffice.org 3.3.0
We couldn't provide the translation for OpenOffice.org 3.4.0 because
we had no resource.
> Is all of the release internationalization done in the language pack?
If you mean localization of User Interface and Online Help, yes they
are in the language pack.
We translate them into our native language on Pootle.
http://wiki.services.openoffice.org/wiki/Pootle_User_Guide
> I see http://ja.openoffice.org
> http://ja.openoffice.org/howtoparticipate.html
> I see openoffice.org SVN subtree for the JA language project.
> I see ja project issues in the combined Bugzilla issue tracker.
> The SVN and Bugzilla infrastructure seems to be in English.
> Could this work separately?
Sorry but I don't see what "this work" is. Which work? :)
> I also see
> http://ftp-srv2.kddilabs.jp/office/openoffice/localized/ja/3.3.0/
> I think this is mirror of
> ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/
> Yes?
I think ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/ is
also one of mirror sites.
http://distribution.openoffice.org/mirrors/#mirrors
:)
> What is your thinking about parts of Japanese language project working separate from Apache development? About coordination of language pack and Apache release and QA? About ways to avoid delays in release to users in language communities?
I don't know the separation works :)
If you take a look at the directory in the mirror, you will find the
following builds.
ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/
OOo_3.3.0_Linux_x86-64_install-deb_ja.tar.gz
OOo_3.3.0_Linux_x86-64_install-rpm-wJRE_ja.tar.gz
OOo_3.3.0_Linux_x86-64_langpack-rpm_ja.tar.gz
OOo_3.3.0_Linux_x86_install-deb_ja.tar.gz
OOo_3.3.0_Linux_x86_install-rpm-wJRE_ja.tar.gz
OOo_3.3.0_Linux_x86_install-rpm_ja.tar.gz
OOo_3.3.0_Linux_x86_langpack-deb_ja.tar.gz
OOo_3.3.0_Linux_x86_langpack-rpm_ja.tar.gz
OOo_3.3.0_MacOS_PPC_install_ja.dmg
OOo_3.3.0_MacOS_x86_install_ja.dmg
OOo_3.3.0_MacOS_x86_langpack_ja.dmg
OOo_3.3.0_Solaris_Sparc_install-wJRE_ja.tar.gz
OOo_3.3.0_Solaris_Sparc_langpack_ja.tar.gz
OOo_3.3.0_Solaris_x86_install-wJRE_ja.tar.gz
OOo_3.3.0_Solaris_x86_langpack_ja.tar.gz
OOo_3.3.0_Win_x86_install-wJRE_ja.exe
OOo_3.3.0_Win_x86_install_ja.exe
OOo_3.3.0_Win_x86_langpack_ja.exe
We QA-tested them and approved them to be released and uploaded to the server.
You see three kinds of builds for each platform.
_install-wJRE_ja, _install_ja and _langpack_ja.
_langpack_ja is integrated in _install-wJRE_ja and _install_ja.
I think a "language project" as a whole should get involved in Apache
release and QA.
Thanks,
khirano
RE: Native Language vs l10n
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Khirano san,
On ooo-dev we are talking now about how to support language communities.
Please help my understanding. I am ignorant. I have too many questions. Answer in parts may be good.
- Dennis
QUESTIONS
Does the Japanese Language Project do any work to prepare distributions for the Japanese Language community? Could it do so?
Does it provide the translation work for the distribution?
Is all of the release internationalization done in the language pack?
I see http://ja.openoffice.org
http://ja.openoffice.org/howtoparticipate.html
I see openoffice.org SVN subtree for the JA language project. I see ja project issues in the combined Bugzilla issue tracker. The SVN and Bugzilla infrastructure seems to be in English. Could this work separately?
I also see
http://ftp-srv2.kddilabs.jp/office/openoffice/localized/ja/3.3.0/
I think this is mirror of
ftp://ftp.osuosl.org/pub/openoffice/localized/ja/3.3.0/
Yes?
What is your thinking about parts of Japanese language project working separate from Apache development? About coordination of language pack and Apache release and QA? About ways to avoid delays in release to users in language communities?
-----Original Message-----
From: Rob Weir [mailto:apache@robweir.com]
Sent: Friday, June 17, 2011 12:50
To: ooo-dev@incubator.apache.org
Subject: Re: Native Language vs l10n
[ ... ]
For things that impact the product release, things like code contributions,
documentation, translations, etc., things that actually could make the bits
and bytes of the release different, I think it is very important that these
pieces are done in Apache. And by being in the Apache project, they are
covered by the Apache 2.0 license and by our consensus decision making
process.
For the activities that do not impact the actual contents of the release,
things like user support, country- or language-specific marketing activities
and so on, for these I could see other models working as well. Remember,
with any Apache project, anyone is free to take the project's source code,
translate it, build it and market it or even sell it. This could be done
with modifications and enhancements. This is all possible under the Apache
2.0 license, whether you participate in the project or not.
So if there are existing groups that do such activities under Sun/Oracle
OpenOffice.org, then they can continue to do so, by using Apache OpenOffice.
But when we start talking about the Apache project, then we are not talking
about "groups" joining. We're talking about individuals joining. I don't
think we want to have independent, autonomous groups within an Apache
project.
But I wonder whether one solution is this:
1) Strong existing language projects continue to operate independently,
according to their own rules.
2) They ensure that their work is all done under Apache 2.0 license so it is
usable by Apache OpenOffice as well as by LibreOffice
3) Language projects each appoint at least one member to join the Apache
OpenOffice project as a liaison.
-Rob
Re: Native Language vs l10n
Posted by Jomar Silva <ho...@gmail.com>.
On Fri, Jun 17, 2011 at 4:49 PM, Rob Weir <ap...@robweir.com> wrote:
> But I wonder whether one solution is this:
>
> 1) Strong existing language projects continue to operate independently,
> according to their own rules.
>
> 2) They ensure that their work is all done under Apache 2.0 license so it is
> usable by Apache OpenOffice as well as by LibreOffice
>
> 3) Language projects each appoint at least one member to join the Apache
> OpenOffice project as a liaison.
+1
-Jomar
Re: Native Language vs l10n
Posted by Rob Weir <ap...@robweir.com>.
On Fri, Jun 17, 2011 at 2:55 PM, Manfred A. Reiter <ma...@gmail.com>wrote:
> Can you understand, that due to the nature of OOo it always
> had very strong language specific communities, wich significantly
> contributed to the huge success of OOo?
>
> Interfering with the habits and cultures established within these
> communties will in fact not take you any further than somebody
> can say "we obeyed the Apache standard rules".
>
> The power of local communites which can act independently,
> has proven to be especially usefull in these areas were competing
> products simply couldn't offer a "consumer focused" localised solution.
>
> I'm just worried that you will alienate some very active contributors
> by enforcing PMC rules just ... "because ..."
>
>
For things that impact the product release, things like code contributions,
documentation, translations, etc., things that actually could make the bits
and bytes of the release different, I think it is very important that these
pieces are done in Apache. And by being in the Apache project, they are
covered by the Apache 2.0 license and by our consensus decision making
process.
For the activities that do not impact the actual contents of the release,
things like user support, country- or language-specific marketing activities
and so on, for these I could see other models working as well. Remember,
with any Apache project, anyone is free to take the project's source code,
translate it, build it and market it or even sell it. This could be done
with modifications and enhancements. This is all possible under the Apache
2.0 license, whether you participate in the project or not.
So if there are existing groups that do such activities under Sun/Oracle
OpenOffice.org, then they can continue to do so, by using Apache OpenOffice.
But when we start talking about the Apache project, then we are not talking
about "groups" joining. We're talking about individuals joining. I don't
think we want to have independent, autonomous groups within an Apache
project.
But I wonder whether one solution is this:
1) Strong existing language projects continue to operate independently,
according to their own rules.
2) They ensure that their work is all done under Apache 2.0 license so it is
usable by Apache OpenOffice as well as by LibreOffice
3) Language projects each appoint at least one member to join the Apache
OpenOffice project as a liaison.
-Rob
Re: Native Language vs l10n
Posted by "Manfred A. Reiter" <ma...@gmail.com>.
Hi Joe, all
Am 17.06.2011 20:26, schrieb Joe Schaefer:
> Whatever ultimately gets created at Apache will require
> active oversight by the (P)PMC.
1. does it have to be that way... or are the rules made by man
2. do you think that OOo at Apache is comparable with all the other
projects?
> We do have a small handful
> of language-specific user mailing lists, but there are people
> on the PMC responsible to see that the lists aren't being
> abused or misused or subject to spam.
Can you understand, that due to the nature of OOo it always
had very strong language specific communities, wich significantly
contributed to the huge success of OOo?
Interfering with the habits and cultures established within these
communties will in fact not take you any further than somebody
can say "we obeyed the Apache standard rules".
The power of local communites which can act independently,
has proven to be especially usefull in these areas were competing
products simply couldn't offer a "consumer focused" localised solution.
I'm just worried that you will alienate some very active contributors
by enforcing PMC rules just ... "because ..."
just my 0,02 eurocent
M.
please excuse BSE
Re: Native Language vs l10n
Posted by Joe Schaefer <jo...@yahoo.com>.
Whatever ultimately gets created at Apache will require
active oversight by the (P)PMC. We do have a small handful
of language-specific user mailing lists, but there are people
on the PMC responsible to see that the lists aren't being
abused or misused or subject to spam.
----- Original Message ----
> From: Louis Suarez-Potts <ls...@gmail.com>
> To: ooo-dev@incubator.apache.org
> Sent: Fri, June 17, 2011 2:21:38 PM
> Subject: Native Language vs l10n
>
> In going over the archives, it occurred to me that a small clarification would
>be useful.
>
> In OOo-land, we had two sorts of language projects. We had the classic
>l10n/i18n, which dealt with localization and internationalization. We also had
>"native-language" projects.
>
>
> This second sort set up heterotopias where discussions related to joining,
>contributing, using OpenOffice.org could take place in the person's native
>language. The idea was to expedite the learning processes and to promote OOo
>among these linguistic groups, as well as in the regions where the language
>dominated.
>
>
> The NL projects (which were later named, "native language confederation") were
>immensely successful and operated as one of the best marketing and promotion
>efforts ever. :-)
>
> I see compelling reasons to retain this structure, therefore, as the enduser
>(of varying degrees of sophistication) benefits immensely from these projects.
>What's more, the contributor who may later become a developer, also benefits,
>as the native-language projects lower the bar and make it easier to join the
>community.
>
> Given the codebase, and given our hopes here, to have a vibrant and
>sustainable community within Apache, I think the inclusion of these sorts of
>native language projects is important, and I urge their establishment.
>
> -louis
>
>
>