incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Lange <marcus.m...@wtnet.de>
Subject Re: Native Language vs l10n
Date Fri, 17 Jun 2011 21:47:57 GMT
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.reiter@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.

Mime
View raw message