On Monday, August 31, 2015 at 6:07:55 AM UTC-7, Axel Hecht wrote: > 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. I am getting confused because I fix a typo in en-US and I'm getting scolded for not updating string ID! :) (wink, wink :flod! ;)) > > 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 agree. > > 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. agree. > 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. agree. I would love us to get back to the conversation about semantic versioning of strings. I still don't know if it should be a docstring, a separate metadata file or a three-way-diff, but I see a huge value in moving from a binary world of "present"/"missing" to the world of full gradient from "you need to translate this string" through "you may want to check this string, but it's ok if you will not" to "that string is totally ok despite comma being fixed in en-US". zb. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
