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<[email protected]>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.
