On 8/29/15 5:35 AM, Zibi Braniecki wrote:
On Wednesday, August 26, 2015 at 12:18:46 PM UTC-7, Robert Kaiser wrote:
Now, either we have tools that alert localizers of changes that may be
interesting to them to react to (if en-US makes the "zero" case better,
a number of other localizations might want to do the same) or we
probably still need to follow a similar rule set.
That's precisely the trap that I'm trying to avoid. "Maybe locales will want to
improve their translations when they see that en-US improves" is a fallacy in the
world where we break 1-1 matching.
The string has one meaning. en-US can work on it the way they want and as long
as the meaning and the variables and the placement stays the same, other
locales should work on their independently.
It's almost like saying "we should alert localizers when german version of that
string changes, because maybe german localizers fine tuned it in a way that others might
want to copy".
I believe we should not. Neither for de, nor for en-US. I asking to
deprioritize en-US and stop assuming that every typo en-US has will be followed
to the letter by localizers, because it shouldn't.
zb.
I think it's important to clarify that you're wrong.
Typos in en-US do not warrant ID changes, and we need to make sure to
not say that. People get even more confused.
That said.
In theory, we need semantic versioning per string. The semantics of
these need to be defined in two contexts:
- programs, or other localized assets
- tools to localize
Programs:
The localized asset has basically two choices: Use the localized string,
or use something else.
In the old world, that question has to be answered strictly at build time.
In the l20n world, that question can be answered at run time, but also
optimized at build time.
Tools:
IIRC, pootle does mark strings fuzzy if English copy changes. As it has
the text in there verbatim, that's one way of "versioning".
For the source-code guys, depending on how they do it, they might also
get "fuzzy" notifications. I.e., if you step through patches affecting
locales/en-US, you will hit copy diffs, which you can examine via diff.
I see one main reason to change IDs:
- previously existing translations break, in particular in ways that
compare-locales doesn't catch.
That's "yeah, we just word this completely differently now", too.
And "completely differently" is just a human decision, I'm afraid.
Fixing English grammar on the hand, shouldn't trigger a change in
localizer's heads at all, and it's kinda unfortunate that po-based
workflows probably do.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
