incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: Native Language vs l10n
Date Fri, 17 Jun 2011 20:55:36 GMT
How about language-spanning yet language-specific features such as
right-to-left characters, multi-key characters, etc?  Would this sort
of requirement or issue area potentially start in a language group,
get bumped to dev, and then propogated out to the language groups to
test and feedback on?


On Fri, Jun 17, 2011 at 4:47 PM, Rob Weir <> wrote:
> 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 <>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.

View raw message