Re: [libreoffice-l10n] Re: [libreoffice-l10n] n’t → n't

Hi Christian,

2014.12.01 00:32, Christian Lohmaier wrote:
> On Sun, Nov 30, 2014 at 10:16 PM, Olivier Hallot
> <olivier.hallot@libreoffice.org> 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
> here.

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.

Regards,
Rimas



-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted