Workflow between dev, UX and l10n teams

projects
#1

Hi all,

[Please follow-up the discussion on projects@ list to keep the history
of the thread there and ease the discussion, thanks :-)]

I would like to open a discussion about the way developers team, UX team
and l10n team should interact and work together.

There has been a heavy discussion [see this thread 1] during this round
of translation. The l10n team was a bit frustrated that there were again
so many changes in the en_US version that does not concern the l10n
versions (like adding colon at the end or capitals in the middle of the
strings).

Each time, it seems part of this could be automated or a reflection
on how to avoid messing the l10n work should have been introduced before
those changes are committed. For example, if I decide to change FR
localization to have sentence capitalization in the menu entries, none
of the 100 other localizations won't and shouldn't be affected. It
should be the same for en_US version or if really impossible, try to
find a solution that lower the impact on all localizations.

None of the l10n teams is against changing or correcting the UI of the
en_US version and none is against the natural evolution of the suite.
What is not bearable is when you have 100 000 changes in en_US and only
a 1/3 concerns all the other languages and it is repeated over the
branches.

We are trying to change our workflow to work on master instead of
branches. That will allow us to review the strings earlier (to leverage
heavy unneeded changes if possible) and have more time to localize. But
that will work only if each taking part of the changes take care of the
others.

To conclude, what l10n team would like to see is:
- a review process of the strings before they are committed and make
sure they respect the en_US standards (capitals, grammar, punctuation,
typography). Maybe adding the Gnome HIG book to our pages [like 2] if
not already.

- if there is a way to script changes, script them otherwise wait until
there is a script available to commit them

- any time there are heavy changes that pop up in someone's mind (like
changing ... for …) discuss it with the l10n team before committing
those changes.

I know it may lower the enthusiasm of some contributors, but it will
regain the one of our l10n teams for sure :slight_smile:

[1]
http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
[2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en

Cheers
Sophie

#2

Hi,

Resending as there was no answer to the proposals :slight_smile:
Cheers
Sophie

#3

Not sure what can we add here?

You summed it up nicely in those 3 points.
As far as I'm concerned, en_us can be changed/improved as much as anyone wants... only if they provide script for automatic update for all other affected languages.

New strings - OK
Edited strings with changed meaning, fixed typos - OK
Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages
Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us

Mihovil

26.01.2015 u 09:33, Sophie je napisao/la:

#4

Hi Sophie and everybody else,

Well I didn't answer as I didn't feel like finding out what the "projects@
list" was and joining that list to be able to join the discussion there.

I will answer here.

I did not read the whole previous discussion but did anyone suggest to add
a new en-us translation language in Pootle and let that be the place where
all non-semantic changes to the en-us strings happen? That way the current
strings in the source code will turn into mere translation keys written in
en-us. The final en-us polishing will then happen in the translation files
just like any other language and will of course not affect any of the other
languages.

Any semantic change should of course still happen in the "keys", i.e. the
source code, but non-semantic changes should be prohibited there and
instead made in the en-us translation in Pootle.

This might be something obvious that you already talked a lot about, but I
just want to make sure this option isn't overlooked.

Jesper

#5

Hi Sophie,

OK for me to work on master translation.

To conclude, what l10n team would like to see is:
- a review process of the strings before they are committed and make
sure they respect the en_US standards (capitals, grammar, punctuation,
typography). Maybe adding the Gnome HIG book to our pages [like 2] if
not already.

That will require a revisor with en_US skills.

- if there is a way to script changes, script them otherwise wait until
there is a script available to commit them

- any time there are heavy changes that pop up in someone's mind (like
changing ... for …) discuss it with the l10n team before committing
those changes.

Right.

The issue is raised (IMHO) because a great deal of developers are not
english native speakers, as well as their focus is no C++ language
rather than English.

The thing is: if we can catch the modification upfront, it will make it
easy for all of us.

If I may also suggest, I'll ask all developers and within ESC recurrent
revision, to check/review/flag for any major issues with respect to
l10n. This can be implemented as

One: create a meta-bug about l10n en_US string revision.

Two: then on each commit that involves some form of l10n activity, the
developer should open a new bug with his commit number/reference and
link to the l10n meta-bug. The subject line should be "L10n revision
requested".

Three: the same developer, if implementing or modifying a feature,
should also open a similar bug with subject "[LOCALHELP] feature XYZ
changed/created; help page missing" and link to bug 80430.

Note that we don't ask to the developers to fix english mistakes nor
write help pages, tasks that we can offload from them provided we get
noticed.

Fixing English mistakes/linguistics and writting help pages is a task
the community can do continuously.

Kind regards

#6

About how much work (read: time) would this review process entail?

Thanks,
--R

#7

Hi :slight_smile:
Yeh i think Sophie did such a brilliant job of summarising all the
points that no-one had anything to argue against.

My main concern was about automating the bits that could be automated
in some sensible way - preferably some way that each language could
select to opt into or out of. In wiki-editing people are encouraged
to write a summary, like a subject-line in an email, for changes
beyond just a couple of characters. Something like that might help
with the automation.

I really liked the point about having some way of identifying trivial
but frequent changes and minor grammer corrections that most
translators will already have dealt with in order to make sense in
their own language(s).

There was a lot of other interesting things in Sophie's post but i
just agree with all of them and that makes it difficult to discuss ;(
It seems like just about everyone here feels the same way.

Regards from
Tom :slight_smile:

#8

Hi :slight_smile:

Hi Tom!

Yes that suggestion was put forwards in the previous thread

Good! And thank you for telling me that.

and i still think it is an excellent idea - or at least has a lot of merit.

I absolutely agree ;-).

I seem to remember there were excellent reasons why it might be
unworkable

I am curious to see those reasons. Guess I will have to browse through the
discussion to find it. But it is rather long, so I might not do that right
now.

but i'm not sure if they really are total blockers.

I can't see how they could be total blockers. LibreOffice comes in hundreds
of languages, so this would just be a new language like any other, and
adding new languages has never seemed to be a big problem before.

There could even still be a language-simplistic version of LibreOffice with
only the unpolished source code keys used and no translation to polished
en-us (if anybody prefer such a version?), but people that want the
language to be polished and correct would just pick up the en-us
translation like everybody else picks up the translation for their own
local language. Why should en-us have any special status in the
construction of the final product?

It doesn't solve the problems with adding colons etc. to existing strings –
changes like that should of course still be automated. But it would solve
problems resulting from changes in style, correction of non-semantic typos,
etc.

And everybody working in Pootle could still add the polished and correct
en-us translation as one of their "alternative source languages" (you can
do that in the settings [1]) and we could all therefore still use the
polished, correct en-us translation as the basis of our translations if we
prefer that over the more coarse, non-polished key strings from the source
code.

Of course I might be repeating arguments that have already been stated in
the earlier discussion. If anyone can find the right part of the original
discussion (perhaps because they know what to search for because they
remember the discussion) they are more than welcome to point it out to me.

[1]: https://translations.documentfoundation.org/accounts/edit/

Regards from
Jesper

Regards from

#9

Hi Sophie, Mihovil,

Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:

Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
different quote styles I don't even have on my keyboard) and anything
similliar - NOT OK if you don't script it for all languages
Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
change just for en_us, don't change my strings and don't even notify me
you did it in en_us

I see 2 problems here:

1) There is no tool that would detect these trivial changes, and would
   act accordingly.

2) The texts for translations are updated in big 'code' drops, without
   possibility for translators to affect the process in any way - for
   them it is too late.

Regarding 1) - I thought that Pootle is detecting the trivial changes
some way, and offering the original translation. Is it not? What can
be done to improve that, so that for translators it is just a matter of
checking; not a matter of translating? [Or even what you suggest - that
it would just update the source strings without touching the
translations?]

Regarding 2) - I'm glad that you say that the strings will be now
getting to Pootle immediately after the code / string changes in master.
I think it is important that the translators will be able to deal with
the changes immediately, not several months later, so that they can
cooperate, and not only react.

In general, I don't think that setting extremely strict rules works,
unless you have means how to enforce them - like via a commit hook or so
(and it is extremely unpopular way to do things).

It is always much better to communicate - if you see a developer who
commits a change that causes you grief, please _do_ tell _him/her_
immediately, and - if possible - in a friendly way. I'm sure he/she
will do much better the next time.

Unfortunately I did not see any signs of notice that this or that change
was problematic for localization on the development mailing list - were
there such warnings there? Like "commit XY caused AB - please don't do
such things, unless we agree how to do that effectively / without pain"?
Or was it impossible so far because the strings in Pootle were not
synced with master?

Also - should we have a 'Localization' recurring topic in the ESC? Who
would be the right representative there, please?

All the best,
Kendy

#10

Hi Kendy,

Hi Sophie, Mihovil,

Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:

Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
different quote styles I don't even have on my keyboard) and anything
similliar - NOT OK if you don't script it for all languages
Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
change just for en_us, don't change my strings and don't even notify me
you did it in en_us

I see 2 problems here:

1) There is no tool that would detect these trivial changes, and would
   act accordingly.

2) The texts for translations are updated in big 'code' drops, without
   possibility for translators to affect the process in any way - for
   them it is too late.

Regarding 1) - I thought that Pootle is detecting the trivial changes
some way, and offering the original translation. Is it not? What can
be done to improve that, so that for translators it is just a matter of
checking; not a matter of translating? [Or even what you suggest - that
it would just update the source strings without touching the
translations?]

Pootle will show you a modified string, even if it doesn't affect your
translation you will have to validate the string again to have it on a
translated state. Also we don't all work on Pootle, several of us are
working off line and Pootle is only a repository for our files.

That's why we were thinking of a en_US version as a real language and
different from the sources and also about scripting changes when
possible (like the substitution of ~ by _)

Regarding 2) - I'm glad that you say that the strings will be now
getting to Pootle immediately after the code / string changes in master.
I think it is important that the translators will be able to deal with
the changes immediately, not several months later, so that they can
cooperate, and not only react.

yes, that's much better, even if we have to be cautious about the workflow.

In general, I don't think that setting extremely strict rules works,
unless you have means how to enforce them - like via a commit hook or so
(and it is extremely unpopular way to do things).

It is always much better to communicate - if you see a developer who
commits a change that causes you grief, please _do_ tell _him/her_
immediately, and - if possible - in a friendly way. I'm sure he/she
will do much better the next time.

Translators are for most of them non technical people and will not see a
commit, but only the result on Pootle, sometimes months later. In the
same way the developer who is doing tons of changes for en_US is invited
to discuss them with the l10n team :slight_smile:

Unfortunately I did not see any signs of notice that this or that change
was problematic for localization on the development mailing list - were
there such warnings there? Like "commit XY caused AB - please don't do
such things, unless we agree how to do that effectively / without pain"?
Or was it impossible so far because the strings in Pootle were not
synced with master?

Yes, I think it was too late and when the l10n team is at work, it's the
rush i.e RC time for developers, so not the best period to discuss hot
topics :wink: That's why I've waited to open this discussion.
Also, even if I've discussed as much as possible about l10n on issues
concerning UI changes, it's a lot of work to follow each commit that
could have an effect. Sharing the effort between developers/UX/l10n
teams should be possible. As we follow Gnome HIG, adding it as
pre-requisite for UI changes/adds may prevent to have to rewrite dialogs
for example.

Also - should we have a 'Localization' recurring topic in the ESC? Who
would be the right representative there, please?

Maybe not as a recurring topic, but something that should be in mind of
UX team and developers when they commit or check for commits that have a
huge impact on l10n.

Cheers
Sophie

#11

Hi Kendy,

Hi Sophie,

Sophie píše v Po 26. 01. 2015 v 16:19 +0100:

Pootle will show you a modified string, even if it doesn't affect your
translation you will have to validate the string again to have it on a
translated state. Also we don't all work on Pootle, several of us are
working off line and Pootle is only a repository for our files.

But the offline files are taken from Pootle too - right? So if fixes
are done at the time of uploading to Pootle, everybody gets them -
correct?

yes, I'll have a meeting with Dwayne (Pootle developer) during Fosdem
and will discuss with him about that.

That's why we were thinking of a en_US version as a real language and
different from the sources and

But at some stage this will have to apply to the sources - and at that
time, it will be even worse than now :frowning: I'm afraid having en_US as a
separate language will make the situation worse, not better.

Yes, I'm not sure either

also about scripting changes when
possible (like the substitution of ~ by _)

Sure - so I think this was something that could have been automatized
with a trivial script; when this was noticed for the first time, please?
Pity that it was not brought to the ESC as a problem...

It was brought on the dev list, but when the l10n team discovered it, it
was too late. Cloph has already scripted several changes, but he can't
do it all.

Translators are for most of them non technical people and will not see a
commit, but only the result on Pootle, sometimes months later.

The "months later" is the problem, not the non-technicality :slight_smile: It is
enough to send "something happened yesterday - please check what's up";
similarly to how people are checking the daily builds.

that will be possible now that some of us are translating on master

Also - should we have a 'Localization' recurring topic in the ESC? Who
would be the right representative there, please?

Maybe not as a recurring topic, but something that should be in mind of
UX team and developers when they commit or check for commits that have a
huge impact on l10n.

Well - if it's not recurring, it's easy to forget :wink: Also I think it
will be more effective to discuss this there - are you able to join this
Thursday?

Thanks for the invitation and yes, let me know the time and I'll join.

Cheers
Sophie

#12

Hi Sophie,

Sophie píše v Po 26. 01. 2015 v 16:19 +0100:

Pootle will show you a modified string, even if it doesn't affect your
translation you will have to validate the string again to have it on a
translated state. Also we don't all work on Pootle, several of us are
working off line and Pootle is only a repository for our files.

But the offline files are taken from Pootle too - right? So if fixes
are done at the time of uploading to Pootle, everybody gets them -
correct?

That's why we were thinking of a en_US version as a real language and
different from the sources and

But at some stage this will have to apply to the sources - and at that
time, it will be even worse than now :frowning: I'm afraid having en_US as a
separate language will make the situation worse, not better.

also about scripting changes when
possible (like the substitution of ~ by _)

Sure - so I think this was something that could have been automatized
with a trivial script; when this was noticed for the first time, please?
Pity that it was not brought to the ESC as a problem...

Translators are for most of them non technical people and will not see a
commit, but only the result on Pootle, sometimes months later.

The "months later" is the problem, not the non-technicality :slight_smile: It is
enough to send "something happened yesterday - please check what's up";
similarly to how people are checking the daily builds.

> Also - should we have a 'Localization' recurring topic in the ESC? Who
> would be the right representative there, please?

Maybe not as a recurring topic, but something that should be in mind of
UX team and developers when they commit or check for commits that have a
huge impact on l10n.

Well - if it's not recurring, it's easy to forget :wink: Also I think it
will be more effective to discuss this there - are you able to join this
Thursday?

All the best,
Kendy

#13

Why?

#14

Hi Robinson

To conclude, what l10n team would like to see is:
- a review process of the strings before they are committed and make
sure they respect the en_US standards (capitals, grammar, punctuation,
typography). Maybe adding the Gnome HIG book to our pages [like 2] if
not already.

That will require a revisor with en_US skills.

About how much work (read: time) would this review process entail?

Thanks,
--R

If you need to review *all* help & UI, I think it maps to an equivalent
of a 500 or more page handbook.

#15

A person who cannot decide if a string change is semantic or cosmetic to en-US should not be messing around with the string names in the first place, if you ask me.

Ok so maybe occasionally they might get it wrong. That still produces a lot LESS workload to fix that landing 2000 cosmetic en-US changes on 50 locales.

Not a good reason for opposing this approach.

Michael

Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16:

#16

PS the current setup is not foolproof either as we sometimes get really bad strings, linguistically bad that is.

If this is such a concern, then why don't we set up a panel of experiences localizers who are willing to help developers judge if a change is semantic or cosmetic before we land them on l10n in general?

Michael

Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16:

#17

Hi,

2015.01.26 17:40, Jan Holesovsky rašė:

Sophie píše v Po 26. 01. 2015 v 16:19 +0100:

That's why we were thinking of a en_US version as a real language and
different from the sources and

But at some stage this will have to apply to the sources - and at that
time, it will be even worse than now :frowning: I'm afraid having en_US as a
separate language will make the situation worse, not better.

also about scripting changes when
possible (like the substitution of ~ by _)

Sure - so I think this was something that could have been automatized
with a trivial script; when this was noticed for the first time, please?
Pity that it was not brought to the ESC as a problem...

I just wanted to say that I'm fully with Jan on these two statements: I
believe that the right thing to do is automation of massive trivial
changes, not a separate pseudo-locale where strings with developer
mistakes and/or without enough clarity would be carved in stone. Having
that pseudo-locale would not help us solve half of cosmetic issues, such
as added colons or changed access keys, these would require scripting
anyway. The issues it would solve are either also scriptable
(typographical or letter case changes) or should be rare by their nature
(typo fixes or sentence improvements; now that some teams work on
master, these should occur in branches even less frequently). On the
other hand, having that source locale would introduce a yet another
level of complexity by forcing each developer to decide where each
string change should go, and if you are thinking about making a single
person or two accountable for these decisions, then why not ask them to
instead review strings that are about to be landed into en-US?

In general, I think it's kind of sloppy (sorry, can't think of a right
word right now) to leave miss-worded strings in the source as they are,
and fix them in a separate locale instead. I don't know how many fixes
like that (specifically excluding typography, colons and similar massive
replacements) end up in each release, but assuming there aren't many
(e.g. a dozen or two), I really don't think they deserve all this fuss.

Regards,
Rimas

#18

Hi Jan,

2015.01.26 16:43, Jan Holesovsky rašė:

Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:

Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
different quote styles I don't even have on my keyboard) and anything
similliar - NOT OK if you don't script it for all languages
Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
change just for en_us, don't change my strings and don't even notify me
you did it in en_us

I see 2 problems here:

1) There is no tool that would detect these trivial changes, and would
   act accordingly.

Regarding 1) - I thought that Pootle is detecting the trivial changes
some way, and offering the original translation. Is it not? What can
be done to improve that, so that for translators it is just a matter of
checking; not a matter of translating? [Or even what you suggest - that
it would just update the source strings without touching the
translations?]

Pootle does offer the original translation, but the localizer still has
to approve it.

Furthermore, Pootle does not apply any automatic changes. If you had
e.g. "Some ~string", and you change it to "Some _string", Pootle will
show the original translation as a hint, but the user will still have to
port this trivial change to the translation manually.

Needless to say, sometimes these minor differences avoid being noticed
by the localizers, which results in errors in the locale (I've seen
incorrect access key identifiers in the menus at least once).

However, while you are correct that there is no tool to detect these
changes, I don't think there has to be. The person who implements the
change knows better than anyone whether or not it can be automated,
perhaps they even automated it themselves. For example, I seriously
doubt that somebody went over all L10n files and changed triple dots to
ellipses manually, this was most likely a scripted change. Same, or very
similar, script would have probably worked with all other locales, but I
guess that person simply didn't think about it.

Similarly, changes in used quote characters most likely could have been
isolated and transplanted to locales.

Adding colons to certain strings only would probably have been slightly
more difficult, but still scriptable.

And none of that requires any "tool to detect trivial changes"... :wink:

2) The texts for translations are updated in big 'code' drops, without
   possibility for translators to affect the process in any way - for
   them it is too late.

Regarding 2) - I'm glad that you say that the strings will be now
getting to Pootle immediately after the code / string changes in master.
I think it is important that the translators will be able to deal with
the changes immediately, not several months later, so that they can
cooperate, and not only react.

In general, I don't think that setting extremely strict rules works,
unless you have means how to enforce them - like via a commit hook or so
(and it is extremely unpopular way to do things).

It is always much better to communicate - if you see a developer who
commits a change that causes you grief, please _do_ tell _him/her_
immediately, and - if possible - in a friendly way. I'm sure he/she
will do much better the next time.

Unfortunately I did not see any signs of notice that this or that change
was problematic for localization on the development mailing list - were
there such warnings there? Like "commit XY caused AB - please don't do
such things, unless we agree how to do that effectively / without pain"?
Or was it impossible so far because the strings in Pootle were not
synced with master?

I fully agree with you here, and yes, so far communicating these issues
was really difficult because these massive changes appeared in front of
the localizers' eyes way too late in the process.

Regards,
Rimas

#19

Hi,

2015.01.27 15:39, Olivier Hallot rašė:

To conclude, what l10n team would like to see is:
- a review process of the strings before they are committed and make
sure they respect the en_US standards (capitals, grammar, punctuation,
typography). Maybe adding the Gnome HIG book to our pages [like 2] if
not already.

That will require a revisor with en_US skills.

About how much work (read: time) would this review process entail?

Thanks,
--R

If you need to review *all* help & UI, I think it maps to an equivalent
of a 500 or more page handbook.

But you don't. L10n only are only asking for review of strings when they
are being changed.

Rimas

#20

Hi Rimas, all

Hi Jan,

2015.01.26 16:43, Jan Holesovsky rašė:
> Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:
>
>> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
>> different quote styles I don't even have on my keyboard) and anything
>> similliar - NOT OK if you don't script it for all languages
>> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
>> change just for en_us, don't change my strings and don't even notify me
>> you did it in en_us
> I see 2 problems here:
>
> 1) There is no tool that would detect these trivial changes, and would
> act accordingly.
>
>
> Regarding 1) - I thought that Pootle is detecting the trivial changes
> some way, and offering the original translation. Is it not? What can
> be done to improve that, so that for translators it is just a matter of
> checking; not a matter of translating? [Or even what you suggest - that
> it would just update the source strings without touching the
> translations?]

Pootle does offer the original translation, but the localizer still has
to approve it.

Furthermore, Pootle does not apply any automatic changes. If you had
e.g. "Some ~string", and you change it to "Some _string", Pootle will
show the original translation as a hint, but the user will still have to
port this trivial change to the translation manually.

Needless to say, sometimes these minor differences avoid being noticed
by the localizers, which results in errors in the locale (I've seen
incorrect access key identifiers in the menus at least once).

However, while you are correct that there is no tool to detect these
changes, I don't think there has to be. The person who implements the
change knows better than anyone whether or not it can be automated,
perhaps they even automated it themselves. For example, I seriously
doubt that somebody went over all L10n files and changed triple dots to
ellipses manually, this was most likely a scripted change. Same, or very
similar, script would have probably worked with all other locales, but I
guess that person simply didn't think about it.

Similarly, changes in used quote characters most likely could have been
isolated and transplanted to locales.

Adding colons to certain strings only would probably have been slightly
more difficult, but still scriptable.

And none of that requires any "tool to detect trivial changes"... :wink:

That's the point of this discussion, thanks Rimas to make it :slight_smile:
L10n team can always react, and earlier now, but making the scripting part
of the commit or part of the 'one making the change' is more natural in the
workflow. In other words, our product is not en_US only.

> 2) The texts for translations are updated in big 'code' drops, without
> possibility for translators to affect the process in any way - for
> them it is too late.
>
>
> Regarding 2) - I'm glad that you say that the strings will be now
> getting to Pootle immediately after the code / string changes in master.
> I think it is important that the translators will be able to deal with
> the changes immediately, not several months later, so that they can
> cooperate, and not only react.
>
> In general, I don't think that setting extremely strict rules works,
> unless you have means how to enforce them - like via a commit hook or so
> (and it is extremely unpopular way to do things).
>
> It is always much better to communicate - if you see a developer who
> commits a change that causes you grief, please _do_ tell _him/her_
> immediately, and - if possible - in a friendly way. I'm sure he/she
> will do much better the next time.
>
> Unfortunately I did not see any signs of notice that this or that change
> was problematic for localization on the development mailing list - were
> there such warnings there? Like "commit XY caused AB - please don't do
> such things, unless we agree how to do that effectively / without pain"?
> Or was it impossible so far because the strings in Pootle were not
> synced with master?

I fully agree with you here, and yes, so far communicating these issues
was really difficult because these massive changes appeared in front of
the localizers' eyes way too late in the process.

What we should take care though is to not over complicate the work of l10n
team by relying on this fact. So as I already said, it should be a shared
work and vigilance by the concerned teams.
Cheers
Sophie

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.