16

Probably this current question has the same root problem as another of my recent reports Already translated strings have lost their translations. However, now the affected strings in Transifex have already been translated (some even a couple of years ago), but are not being used on the site. E.g. on ruSO:

Translated but not used

For instance "Closing" was translated 3 years ago and previously was used on the site.

Is there some issue on the Transifex side?

It would be good if someone could confirm if the same behaviour is happening on other localized sites like SO in Portuguese, Spanish or Japanese. I don't have enough reputation to test closing question on these sites. Probably the other strings might be affected.

Improve this question
5
  • 3
    I don't think it is a bug. We also had this in Stack Overflow en español and the reason is that the original text had minor changes, so when the string was pushed it was seen as something new to Transifex. See screenshot of the current view in SOes, also with closing: i.sstatic.net/gTvwp.png
    – fedorqui 'SO stop harming'
    Commented Jan 26, 2018 at 9:24
  • 2
    So it is probably something that was hardcoded in the codebase and needs to be put available to Transifex
    – fedorqui 'SO stop harming'
    Commented Jan 26, 2018 at 9:33
  • @fedorqui I don't see any reason why the old translatable string now became hardcoded. I'm more inclined to the Transifex bug. Are the votes strings from the bottom of the close dialog also affected on SOes?
    – αλεχολυτ
    Commented Jan 26, 2018 at 9:44
  • 3
    Yep, i.sstatic.net/RlRgG.png I do not have elements to discard a Transifex bug, but I recently learnt how the pipeline SO→Transifex works (in Spanish) and it looks to me that someone just hardcoded something.
    – fedorqui 'SO stop harming'
    Commented Jan 26, 2018 at 9:51
  • 4
    These aren't hardcoded. At a glance, there's nothing obviously wrong here and when Samo and I tried to investigate earlier, we couldn't reproduce the problem either. We'll have to keep an eye out for the next time it breaks and see if that provides any more clues.
    – Adam Lear StaffMod
    Commented Jan 26, 2018 at 18:08

1 Answer 1

Reset to default
4

This was fixed in the suite of changes that went out on Feb 7 as well. This was one of the cases where the string was genuinely flickering, because of the setup of our localization pipeline, which was an unholy messy.

Effectively, the string variant calculations didn't happen at build time, but relied on a dump of all the variants from a previous build. That dump lived on a network share, which grew to be quite substantial (several 100GB of per-dev-build-per-language files with hash+variant combinations, basically everything you have on Transifex, per build), and the sync started to get flaky. This got changed, so that variants get calculated directly, in one place only, and the dumps are only copied to the network share in case we need to do any diagnostics, but are otherwise part of the particular build's artifacts, so that they are copied to all the servers (they still need that file for interaction with Transifex).

Improve this answer

You must log in to answer this question.

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