n’t → n't

[igaidhlig]

I like Oliver's idea. That way, en-US can change its caps, commas, typos,
formatted vs non-formatted typography on a daily basis to their heart's content
without kicking the rest of the planet into the neolithic, l10n-wise.

If I may point out the commercial angle on this - I charge $35 an hour for
Gaelic proofreading. Perhaps it's a little cheaper for more common languages but
even so, every time the developers kick 4000 (linguistically) pointless string
changes at all other locales because the feeling is they're needed in en-US,
that amounts to (gut estimate) 12 hours work, so multiply that by 115 locales,
it's causing the rough equivalent of a $40.000 translation bill.

Yes, we're translating pro bono publico but it's still a callous way of treating
donated lifetime.

Michael

[Yury_Tarasievich]

...

Yes, we're translating pro bono publico but it's still a callous way of treating
donated lifetime.

...

Did you notice how I've left out that angle?
And 'callous' is the right word here (incorrect apostrophes!).

Yury

[Yury_Tarasievich]

In fact, this is a good idea, not in sarcastic way whatsoever. Point the translation origin to the uncorrcted, un-nicefied English (updated only if the semantics change). Make production en_US a 'translation' of this.

Yury

...

I suggest to create a new entry in Pootle, named en-US so that we get a
translation from Liboish to English. Other languages translates directly
from Liboish and we are all happy not to redo our work.

...

[Rimas_Kudelis]

Hi,

2014.11.30 19:13, Olivier Hallot wrote:

Lets invent a new language in the world named Liboish - LibreOffice
language - that in fact is often confused with en_US, but it is not the
same.

I suggest to create a new entry in Pootle, named en-US so that we get a
translation from Liboish to English. Other languages translates directly
from Liboish and we are all happy not to redo our work.

(Apologizes for the inapropriate sense of humour, but I saw this extra
work comming months ago. 99% of my 4.4 UI was rework)

I can't understand whether or not you're joking, but others are already
voicing their support to this idea, so I'll voice my 'unsupport' as well.

I don't really think this would be viable solution in the long run.
Somebody would have to maintain that "translation" for years just
because in 2014 localizers made a fuss out of a one-time problem that
could (and should) have been automated not to bother them in the first
place. Furthermore, in my opinion, there would be constant risk of
either doing too much or not doing enough in this front.

Let's not forget that massive changes like these don't happen every
month. Yes, we had migration to different accesskey characters, and
manually updating all locales to reflect that must have been painful to
localizers. Yes, this current situation is somewhat similar because
again no real translation would is involved in this massive change. But:
I still believe this migration can be automated and made painless (at
least for the most part), so why not aim for making that automation a
prerequisite of the change that is threatening our well-being? LibO
developers don't live in another planet, and they can be reasoned and
negotiated with, right?

Rimas

[ohallot]

Hi Rimas

Hi,

2014.11.30 19:13, Olivier Hallot wrote:

Lets invent a new language in the world named Liboish - LibreOffice
language - that in fact is often confused with en_US, but it is not the
same.

I suggest to create a new entry in Pootle, named en-US so that we get a
translation from Liboish to English. Other languages translates directly
from Liboish and we are all happy not to redo our work.

(Apologizes for the inapropriate sense of humour, but I saw this extra
work comming months ago. 99% of my 4.4 UI was rework)

I can't understand whether or not you're joking, but others are already
voicing their support to this idea, so I'll voice my 'unsupport' as well.

I am joking and also provocative. Sorry for that. Of course there is no
such thing like "Liboish" nor it make any sense.

I don't really think this would be viable solution in the long run.
Somebody would have to maintain that "translation" for years just
because in 2014 localizers made a fuss out of a one-time problem that
could (and should) have been automated not to bother them in the first
place. Furthermore, in my opinion, there would be constant risk of
either doing too much or not doing enough in this front.

Let's not forget that massive changes like these don't happen every
month. Yes, we had migration to different accesskey characters, and
manually updating all locales to reflect that must have been painful to
localizers. Yes, this current situation is somewhat similar because
again no real translation would is involved in this massive change. But:
I still believe this migration can be automated and made painless (at
least for the most part), so why not aim for making that automation a
prerequisite of the change that is threatening our well-being? LibO
developers don't live in another planet, and they can be reasoned and
negotiated with, right?

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.

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.

[Christian_Lohmaier]

Hi Olivier, *,

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

it's different with one-to-one changes that can easily
(=automatically) be undone to look for the string as it was before the
cosmetic change.

The auto-translations of the help strings with changed help-ID works
that way (although there is quite a bit of manual work involved to
create the mapping). But once you have a mapping "old-helpid" →
"new-helpid", you can easily apply the old translation.

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

ciao
Christian

[Yury_Tarasievich]

...

I don't really think this would be viable solution in the long run.
Somebody would have to maintain that "translation" for years just
because in 2014 localizers made a fuss out of a one-time problem that
could (and should) have been automated not to bother them in the first

...

Not condescending, surely? Just browsing a thousand strings is a hit on translator's time and eyes. Proofing costs more.

Translators are on a receiving end of one-way work creation pipeline, and should have no say in the matter?

Let's not forget that massive changes like these don't happen every
month. Yes, we had migration to different accesskey characters, and

Massive changes like that would and will happen in an open source world, when complex software package is involved; specifically, they'll happen in LibO. For two good reasons: because they cost practically nothing to initiator, and because in Open Source nobody can or wants put a veto on such changes.

And why is not anyone (besides me) discussing automation, of that same problem, too?

Yury

[Christian_Lohmaier]

Probably because there is nothing to discuss as it has already been
explained that it can be done/to what extend it can be done/how it can
be done.

ciao
Christian

[sophi]

Hi all,

Hi Olivier, *,

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

it's different with one-to-one changes that can easily
(=automatically) be undone to look for the string as it was before the
cosmetic change.

The auto-translations of the help strings with changed help-ID works
that way (although there is quite a bit of manual work involved to
create the mapping). But once you have a mapping "old-helpid" →
"new-helpid", you can easily apply the old translation.

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.

Agreed

But that doesn't mean the workflow as a whole cannot be improved.
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...)

Something we should discuss then.
For information, I've discussed with the Design team about their changes
and asked them to take care of the work load it causes to the l10n team.
I asked them also to open an issue each time they make a change in the
UI that is not reflected in the help files so we can track them.
Cheers
Sophie

[Yury_Tarasievich]

Excepting whether anything actually would be done, and by whom.

Right now the issue is being gracefully shoveled off into the translators' hands.

Yury

[Rimas_Kudelis]

Hi Christian,

2014.12.01 00:32, Christian Lohmaier 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

[Mihkel]

I for one -- i.e. the Estonian team -- would very much like to work on
master branch.

Br
Mihkel