11

Recently I noticed that some strings in Transifex have lost their translations. E.g. this one:

You've earned the "$badgeName$" badge ($badgeDescription$) for "$postTitle$".

I know that same string was already translated and used on ruSO for the long time. Now translation is lost, but even Transifex says that there is 100% match string in suggestions (acquired from the translation history). This means that new string is the same as the old one and should not be reset as happens if original string is slightly modified (even with one symbol).

Transifex

Why did this happen? Did you change the string's key generation (hash) function? Could this be prevented in the future updates to minimize losing of translations?

Improve this question
4
  • Might be Transifex bug, time to add a tag for this. :)
    – Shadow The GPT Wizard
    Jan 23, 2018 at 9:15
  • @ShadowtheHedgehogWizard whoa new tag! Need to retag many of my old questions!
    – αλεχολυτ
    Jan 23, 2018 at 9:18
  • Hold your horses... give it a day or so, other high rep user might disagree with me and remove the tag, in which case better start discussion if we need the tag or not. With all due self respect, I do mistakes sometimes, and don't want to do big changes on my own. If the tag "pass", then we can safely start retagging other questions. :)
    – Shadow The GPT Wizard
    Jan 23, 2018 at 9:20
  • meta.stackexchange.com/questions/306656/…
    – m0sa StaffMod
    Feb 19, 2018 at 10:15

1 Answer 1

Reset to default
7

On February 7th fixes went out to address this "flaky localization strings" issue.

The main issue for the flaky strings was an unstable ordering of the variant parameters which caused the trailing part of the string id (after the hash, countA=one,countB=many) to differ between builds.

The parameters are now sorted in the order of appearance, which is a sort that affected the least strings.

Strings with following hashes were affected:

03da42a58795142f23ede4b02efbedd8
0b81d744f1eb1787b016126b6d5d6b34
0e868a8fa494c895de3090e7c8ac428d
0f1028b04314c54113c9382356dabd6c
26459b8c977c85b8e8a6493dd094154a
2e65f1bbce231476e732eb6e3ebc0e56
36604f58571398c045eaa41285efad68
6a7a9d6f3b959c3ec5b6e61fefbed68f
6b0d6ca383ca42c04a7dbc18231d80bb
796138fbac2cc1045a49351cfcf876d7
8be4b5404852718568fadc1ad5672a6a
930bf60fabb24d48556af3936c0aa41d
a96bdb65d7fd5c798bf0347cba2ee68d
ad5615f677f0ff088f4f03301806c757
b6475232202bb96802a83f457ea79900
c1ab4e949cd1853ae3ddc2d21ce42afd
e39b362eccc2425b04d9ef53ad0a9c27
ec0919a19b1ef27f2da6f9f088966e7c

Additionaly some strings that were flaky, did loose their translation on Transifex, but they still remain localized in our canonical DB, and on the website.

Improve this answer
3
  • 1
    But the string that mentioned in the question doesn't have variant parameters.
    – αλεχολυτ
    Feb 19, 2018 at 12:58
  • Thank you @m0sa for fixing this bug! I wonder, is there any way to get a list of the additional "flaky strings"?.. I understand those strings are correct on the database and will render just fine on the site. However, all variants are picking only one of the translations as suggestion, which may lead a reviewer to approve the wrong variant, hence overwriting the string in the database
    – Mariano
    Feb 19, 2018 at 16:26
  • we could coordinate a freeze (because it would override all unreviewed changes) and push to get everything (translated strings) from our canonical DB up on Transifex (we only push "new" English strings during our regular builds)
    – m0sa StaffMod
    Feb 19, 2018 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .