Bug 113851 - Scenarios which shouldn't trigger retranslation of strings
Summary: Scenarios which shouldn't trigger retranslation of strings
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
(earliest affected)
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Depends on:
Blocks: l10n-Optimization
  Show dependency treegraph
Reported: 2017-11-15 12:47 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-11-22 13:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2017-11-15 12:47:54 UTC
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.
Comment 1 Yousuf Philips (jay) (retired) 2017-11-15 13:15:09 UTC
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)."
Comment 2 Martin Srebotnjak 2017-11-16 13:12:36 UTC
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 ...
Comment 3 Yousuf Philips (jay) (retired) 2017-11-16 15:35:57 UTC
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.
Comment 4 Yousuf Philips (jay) (retired) 2017-11-22 13:19:44 UTC
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."