> 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
