incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Dealing with a large and diverse project - Native Languages and project teams
Date Fri, 18 May 2012 23:52:21 GMT

On May 18, 2012, at 8:44 AM, Donald Whytock wrote:

> On Fri, May 18, 2012 at 11:38 AM, drew <> wrote:
>> On Fri, 2012-05-18 at 11:29 -0400, Donald Whytock wrote:
>>> On Fri, May 18, 2012 at 11:20 AM, drew <> wrote:
>>>> On Fri, 2012-05-18 at 11:08 -0400, Rob Weir wrote:
>>>>> On Fri, May 18, 2012 at 10:55 AM, drew jensen
>>>>> <> wrote:
>>>>>> Hi,
>>>>>> Recently there has been some discussion on the projects private ML
>>>>>> regarding issues about native language groups and how best to support
>>>>>> work groups which will by definition be somewhat circumscribed from
>>>>>> whole by virtue of language without losing the cohesion of a single
>>>>>> project focus.
>>>>>> I invite others pick that up here:
>>>>> What we do currently:
>>>>> 1) One big ooo-dev list
>>>>> 2) Some NL-specific lists.  I don't subscribe to them at all, so
>>>>> others would need to say how they are currently being used.
>>>>> 3) We have some emerging procedures for how volunteers can contribute
>>>>> to product and website translations, but this information is scattered
>>>>> in old ooo-dev posts and not easy to find.
>>>>> I wonder whether a good step forward might be to document on our
>>>>> project website ( the
>>>>> procedures from #3 above.  Then when we have a new volunteer on the
>>>>> list we can point them to this information.  This could expand to
>>>>> other NL topics such as local marketing/events, trademark usage,  NL
>>>>> mailing lists, etc.
>>>> hmm I would say, eventually yes, but if you mean - one giant dev list is
>>>> already the decided outcome and so just document it as such, then I'd
>>>> say no, not yet.
>>>> I do not think this project is such that one can just say 'the Apache
>>>> way' and be done with it - there is about to be a new Apache way me
>>>> thinks.
>>>> For instance I wonder how much experience there is in the Apache Way
>>>> with a project which will need to look local in certain places around
>>>> the world (China, Vietnam, Brasil, Venzuela and Bolivia come to mind
>>>> quickly) as without this the local government support goes away and
>>>> without that so does the local project - or at least that is my
>>>> understanding of the situation in those places. I use that only to say
>>>> that IMO this needs some real thought as to how this project is going to
>>>> build itself.
>>> Has any thought been given to reaching out to language-teaching
>>> communities at colleges for translation assistance?  This would do
>>> dual duty of getting help with translation of top-level site
>>> information and spreading the word about AOO.  There may be teachers
>>> who would consider translation of NL pages extra-credit work for
>>> students.
>> Sounds like a great idea, if, the reason for this project is simply to
>> scratch an itch - in other words if the goal here is to build the
>> software and then not really concern ourselves with who uses it, because
>> that is outside of the scope of this project and left to others to do
>> (and a valid position, perhaps) then I'd say sure, that sounds like one
>> good avenue to work on. In that scenario of the reason for the project
>> we don't care really about building local teams, only in the work
>> product.
>> //drew
> I was thinking of a bootstrap.  At the moment, if all the policies and
> procedures and process descriptions are in English, then all your NL
> communities must start with a person who's capable in both English and
> the target language.  If, on the other hand, you mass-produce
> translations of those policies and procedures and process descriptions
> into multiple languages and put them on NL root pages, you've widened
> your community-founding pool.
> Yes, scratching an itch.  And prying open a door.

I like your idea here. It can be done. If the translation is bad then a Native Language speaker
might scratch their itch for better language.


> Don

View raw message