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