Sostituzione della traduzione obsoleta che causa la mancanza di traduzione

[Kumandan]

Hi all.
With the update I made about 1 week ago, a button display problem appeared on the user profile page as follows. I thought it could be fixed with the update to be made in the following days, and although I made the ongoing updates, it did not improve.

[Moin]

Does the text work on your profile here at Meta?

Have you customized the string in the past?

I also found this topic Turkish translation issue with share dialog so maybe try a rebuild.

[Kumandan]

There doesn’t seem to be any problem in meta. But the problem persists on my own site. I didn’t do any customization/localization.
I also tried the solution in the link you gave and rebuilt the Discourse. Unfortunately it didn’t work.

[Moin]

Have you tried a different browser or a private browsing / incognito tab?

[Kumandan]

Thank you for your concern.
I tried it in 4 different browsers and mobile. I can clearly say that it doesn’t work.

[Moin]

Then you have probably also tried safe mode already.

[Kumandan]

The problem persists in Safe Mode unfortunately. . .

[sam (Sam Saffron)]

Moved this to support:

Seeing the text properly here… are you sure you updated to absolute latest?

[Kumandan]

When I check, I can see that it is up to date.
I can’t understand what caused this.

[Moin]

I think this is related to

Admin -> Customize -> Text behaving badly

This happens when there’s a translation override for a key that previously was a translatable string, but was converted into a Hash at a later time. That’s exactly what happened with chatbot.prompt.system. This seems like a regression. I’m pretty sure this used to work in the past. I can easily reproduce this with a locale file like this: en: foo: "this is foo" Go to Customize → Text and override “foo” with a different value. Then, change the locale file to look like this: en: foo: …

I was able to reproduce the issue that the string for preferences in Turkish was broken. I customized js.user.preferences before updating and after the update the new js.user.preferences.title was broken.
Then I ran

TranslationOverride.where(translation_key: "js.user.preferences").delete_all
TranslationOverride.send(:reload_locale!)

and this fixed it

But I would wait for confirmation from someone with more knowledge before I would try to do this myself on a production site

[Kumandan]

When I check, the text value appears correct.

I changed the default text but it still didn’t work and the same problem persists.

[Muhammed_EKİCİ (mekici)]

Is it safe to do this in a production environment? Can someone guide?
No text customization works on the forum. It doesn’t just apply to this area.

[Lhc_fl (Linca)]

TL;DR: The existing translation override rudely overrides the outdated custom translation with the new translation, causing type issues. Or, here, failed to update the outdated translation override to “outdated”

The issue

The forum I manage has an override for the translation js.user.preferences. Before this commit, it was a string, so the translation override worked fine.

After this commit, the key becomes an object. However, the translation override does not detect the key type, but directly overrides it to the old defined string. This causes the translation of the key to be missing in the interface.

How to reproduce

For latest forums, this seems to require manually inserting an outdated record to trigger

INSERT INTO translation_overrides
  (locale, translation_key, value, created_at, updated_at)
VALUES 
  ('en', 'js.user.preferences', 'test', current_timestamp, current_timestamp);

Then modify a site text at random to trigger the update

It seems that somehow, the status of this override was not updated to “outdated”

[5] pry(main)> TranslationOverride.last
  TranslationOverride Load (1.2ms)  SELECT "translation_overrides".* FROM "translation_overrides" ORDER BY "translation_overrides"."id" DESC LIMIT 1
=> #<TranslationOverride:0x00007f0b20a31e20
 id: 18,
 locale: "en",
 translation_key: "js.user.preferences",
 value: "test",
 created_at: Tue, 23 Jul 2024 17:08:17.317404000 UTC +00:00,
 updated_at: Tue, 23 Jul 2024 17:08:17.317404000 UTC +00:00,
 compiled_js: nil,
 original_translation: nil,
 status: "up_to_date">

[JammyDodger]

I’ve slipped your repro over to the previous reports to keep them grouped together.

[Lhc_fl (Linca)]

Wow, I didn’t see there was a same bug report here ()

I’m already tracking it down, but it’s weird, I think this should work fine… I don’t know what’s going on here

[JammyDodger]

@Muhammed_EKİCİ

Is it safe to do this in a production environment? Can someone guide?
No text customization works on the forum. It doesn’t just apply to this area.

This should be safe to do on a production site. (though please take a backup before attempting changes in the rails console, as accidents can happen)

Though if no text customisations are working, are you sure this is the same issue?

[Muhammed_EKİCİ (mekici)]

This issue has been resolved with the latest update. (3.4.0.beta1-dev)

[Kumandan]

Yes, I also confirm that the issue has been resolved with the current update.

[JammyDodger]

Just to round this out, here’s the PR for the fix:

FIX: Ensure JsLocaleHelper to not output deprecated translations