incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Native Language vs l10n
Date Fri, 17 Jun 2011 20:47:42 GMT
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?


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.


On Fri, Jun 17, 2011 at 4:33 PM, Manfred A. Reiter <>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.

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