What flod said.

Axel

On 8/25/15 9:43 PM, Francesco Lodolo [:flod] wrote:
It brought us to extreme because we need to be caution and there were
cases where non-semantic changes to en-US triggered id changes. Example:

1) Entity <foo "Whats up {{$user}}"> in en-US gets a spelling fixed to
"<foo "What's up {{$user}}"> and a comma added
2) We demand ID update.


To clarify: we do *not* ask to change ID for this kind of modifications.

Typos, internal consistency matters like punctuation or case, minor changes
are explicitly called out as exceptions to that rule.
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Changing_existing_strings

I won't bug developers who do change the ID in these cases (eventually
point out that it wasn't needed), while I'll do it if the string changes
without a new ID and the kind of change is not trivial.


I believe that in L20n paradigm this should *not* warrant entity ID change.


I agree, in the L20n world. The flexibility that l20n brings to the table
comes at a price: localizers can break things in a ton of new creative
ways, and it's up to tools and localizers to be able to deal with that. But
we're not there yet.

In a L20n scenario, the only change that would require a new ID would be
the removal of support for $number.



en-US is becoming one of the languages and we should not bind the social
contract to the en-US copy, but to the semantic meaning and location of the
entity.


We need to agree on "semantic meaning". Sometimes English strings,
especially in Gaia, are so poorly worded that we ask to have a new ID to
make sure localizers are aware of the change (the meaning was there, just
explained terribly), and they can decide if they want to apply similar
changes. I think that's still a valid reason to change the ID.

Francesco


_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n

Reply via email to