When the alphanumeric characters of a english string arent changed in the code but various other characters are added or removed, retranslation (aka fuzzy) shouldnt added to the changed. Below are some scenarios which shouldnt trigger retranslation. 1. the accelerator character '~' or '_' is moved within a string 2. a colon is added to or removed from the end of a string 3. a '...' or '…' as added or removed from the end of a string In scenario 1, the change should be ignored. In scenario 2 and 3, the character added or removed from the end of the string should be added or removed from the end of translation strings.
What Noel mentioned on irc "maybe you can tweak the change-detection code?" What Caolan mentioned on irc "maybe just ask on dev mailing list if its possible to mass append ":" to translations in pootle if the source one has it already and maybe cloph can answer on his return, and at least we can document what's going on" What Sophie mentioned on telegram "this was already discussed on the dev list, ... and you should add cloph to the list, he is writing the scripts to avoid that usually" What Adolfo mentioned in bug 113777 comment 2 "L10n pushed back vigorously against mass-changing strings, and to this day we can’t make the consistent without affecting millions of translations (Mozilla’s tools, on the contrary, allow for these changes)."
AD1 - this seems OK, as long as there would be some tool/script to check all accelerators in given contexts - i.e. if every l10n team could get a printout or run a script somewhere on a site (Pootle or else) to see, if there are any duplicate accelerators in the same place (in the same menu, submenu, dialog, bar ...); AD2 - there is probably a difference in the case of LTR languages etc. But also: sometimes this is not the same string as already localized: most of the times the command in a menu is a verb, whereas content before a colon is usually a noun; there are a lot of these same in English, but not so in a lot of languages; so in this case probably a colon should be added, but the string should then be marked as a fuzzy to be checked in the specific context; AD3 - for Slovenian, unlike English, there should be a space before a "..."; also, because of that we prefer "..." instead of "…"; so there should be language specific rules here as well ...
Another scenario that shouldnt trigger retranslation (atleast definitely not for languages that dont have capitalizations like CJK and RTL) is if the capitalization changes in english (e.g. 'First/Last _name/Initials' to 'First/last _name/initials') which did cause alot of retranslations in dialogs in 4.4.
cloph mentioned the following in irc "I disagree - if a translation project doesn't care about those, they should individually merge the old strings, for such I wouln't like to ignore the changes, as it might indicate restructuring of menus or similar. Furthermore: for those cases the translation memory should be enough, as they are not mass-changes affecting hundreds of strings."