Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi Christian,

2014.12.01 00:32, Christian Lohmaier wrote:
On Sun, Nov 30, 2014 at 10:16 PM, Olivier Hallot
<> wrote:
On 30/11/2014 18:52, Rimas Kudelis wrote:
2014.11.30 19:13, Olivier Hallot wrote:
painless migration was my hope when I raised the issue, but saddly it
didn't show up in time. Such Changes In Capital Letters And Semicolons
Are Suitebale in EN But Does Not Affect Other Languages Where This Rule
Does Not Apply.
It's impossible to automatically decide which of those changes are
purely cosmetic and which not.

I'm not sure what you mean here. It can't be hard to distinguish such
lines where only straight apostrophes, straight quotes or
three-dots-as-an-ellipsis are being replaced with their fancier
equivalents. And with these changes filtered out, I don't think it would
be impossible to propagate them to localized files by changing msgid's
in them to reflect these cosmetic updates.

And there likely won't be anyone who
manually goes through all the changes and manually creates mapping
from old to new so that old translations can be pulled in. And with
changes like changing casing and adding colons it is more likely that
the translation will also want to apply the change, so just staying
silent and not flagging the string as changed is not really an option

I believe we could have cheated even with colons by adding them to the
translations automatically (probably on an opt-out or opt-in basis).  As
for case changes, I guess it depends on their nature: if en-US would
decide to make a massive change between say Title Case and Sentence
case, I guess most locales would find it very much acceptable to just
keep what they already have. On the other hand, if the change was to or
from lowecase, the expectations might differ.

Nevertheless, it may be time to create a T/LSC Translation/Linguistic
Steering Commitee to address the issues raised here. LiBO does not have
a linguistic revision of terms used in the UI.
Not progressing just for the sake of not causing work for anybody is
the wrong approach.
But that doesn't mean the workflow as a whole cannot be improved.

Fully agreed.

It would for example also be possible to have "master" project in
pootle (instead of just for the release-branches), so that the amount
of changes are incremental, and not all one or two months before a new
major release.
(but that of course means applying a translation to multiple projects,
so not sure whether that really reduces the work and not causing more
work for translators...)

For at least a few years, I performed most of my Mozilla localization
work on their master branch. When branches were cut and repositories
migrated, I would migrate my repos too. I can imagine a scenario where
at least some teams would want to work on LibO master as well. There
even is potential that such process could help avoid some problems by
signaling them early enough so that they can be fixed or undone.

Obviously though, this should not be required from all teams. And if we
have at least two simultaneously active release branches, this might not
be the best approach.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.