incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Lynch <ianrly...@gmail.com>
Subject Re: [PROPOSAL] Set up of ooo-dev-ja at incubator.apache.org
Date Mon, 12 Sep 2011 12:01:10 GMT
On 12 September 2011 12:52, Rob Weir <robweir@apache.org> wrote:

> On Mon, Sep 12, 2011 at 5:42 AM, Ross Gardler
> <rgardler@opendirective.com> wrote:
> > On 12 September 2011 10:27, Ian Lynch <ianrlynch@gmail.com> wrote:
> >> On 11 September 2011 23:19, Ross Gardler <rgardler@opendirective.com>
> wrote:
> >>
> >>> With my mentor hat on I have no objection as long as it is clear that
> no
> >>> decisions about the project in general can be made on this list. All
> >>> decisions must be made here.
> >>>
> >>
> >> Hi Ross, just to clarify what you mean by project in general. I assume
> you
> >> mean things like direction of the code development and intellectual
> >> property, rather than things like language translations, localisation
> and
> >> marketing?
> >
> > Yes, that is correct.
> >
> >> So eg they could make a decision to have a marketing conference
> >> in Japan or to correct say a translation error in a dictionary. In the
> >> latter case it would still require a committer to commit and have
> accepted
> >> the revision submitted to the main project. I'm just trying to
> understand
> >> the scope to the types of restrictions that are likely to apply.
> >
> > There is no fixed rule here. In practice no other ASF project has a
> > "dev" list in any language other than English as the accepted
> > guideline is that only English is allowed. Personally I don't think
> > this is workable in OOo.
> >
> > What we need to do is, as you say "understand the scope to the types
> > of restrictions that are likely to apply". As a starting point I would
> > say that if a decision on the jp list affects those in other countries
> > (any other country) then that decision needs to be made on the core
> > English language list. Therefore the jp list would bring a proposal
> > here.
>
> <snip>
>
> I'd like to challenge the concept that there are decisions that might
> be made that effect "only" interests in a single country.


Distinction between country and language? US English and UK English have
some differences and the countries are very distinct but in OOo there was
never a separation in terms of native languages.


> I don't
> think there is such thing.  Certainly there might be some members of
> this project who are interested in only the Japanese version, or only
> the English version or only the French version of AOOo.  But there are
> also many others -- and I count myself as one of them -- who are
> interested in creating a localized office suite that can be deployed
> to larger multinational corporations and other institutions.  So my
> interests cut across all languages. I wouldn't assume that just
> because I don't speak Japanese that I don't have a strong interest in
> the success of the Japanese version of AOOo, or that I cannot tap into
> Japanese language expertise to help evaluate a proposal.
>

This is partly my reason for posting to the other thread Ross started. Let's
try and work out some sort of agreed code of practice that is generic rather
than this specifically Japanese issue.  If the NL projects agreed that
builds always get made and released through the ASF central infrastructure
would that solve most of the issues? Is it practically feasible?

In other words the stakeholders for AOOo are more than just individual
> end-users who download and install the product.  The stakeholders also
> include downstream consumers, distributors, hardware vendors who
> bundle, etc.  Some of these interests are represented on the PPMC.
> And their interests often transcend a single language.
>
>
> -Rob
>



-- 
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message