OpenRefine displaying IDs instead of German translation

[CennoxX]

OpenRefine doesn't display the German translation, instead the IDs are shown.

To Reproduce

Steps to reproduce the behavior:

1. Install OpenRefine 3.7.1
2. Open Language Settings
3. Choose Deutsch
4. Look at the top, where core-index/slogan is written instead of the slogan
5. Compare with weblate (https://hosted.weblate.org/translate/openrefine/translations/de/?offset=1&q=+core-index%2Fslogan&sort_by=-priority%2Cposition&checksum=) the slogan is translated since two years

Current Results

I'm seeing translation ids

Expected Behavior

I see the translation

Screenshots

Versions

• Operating System: Windows 10
• Browser Version: Firefox 111.0.1 (64-Bit)
• JRE or JDK Version: 17
• OpenRefine: OpenRefine 3.7.1

[CennoxX]

Could this possibly be related to missing entries at https://github.com/OpenRefine/OpenRefine/tree/master/main/resources/com/google/refine? If I use another language such as Greek ("el") or Filipino ("fil"), both of which have no entries under the above directory, then the same error occurs. In particular, the entries ".../grel/ControlDescription_XY.properties", ".../messages/OpenRefineMessage_XY.properties" and ".../operations/OperationDescription_XY.properties" are missing.

[wetneb]

Those files are only used for localization of the strings produced in the backend, but that's a just a fraction of the text you see in the interface. According to your screenshot the frontend translations are missing and that's the main problem.

I can also reproduce it on my side and I get this log:

08:50:34.397 [                   refine] POST /command/core/load-language (32ms)
08:50:34.398 [                  command] Language file [database:translation-de.json] not found (1ms)
08:50:34.421 [                   refine] POST /command/core/load-language (23ms)
08:50:34.422 [                  command] Language file [phonetic:translation-de.json] not found (1ms)
08:50:34.443 [                   refine] POST /command/core/load-language (21ms)
08:50:34.444 [                  command] Language file [gdata:translation-de.json] not found (1ms)
08:50:34.474 [                   refine] POST /command/core/load-language (30ms)
08:50:34.478 [                  command] Language file [wikidata:translation-de.json] not found (4ms)
08:50:34.637 [                   refine] GET /command/core/get-project-metadata (159ms)

Normally the text should fall back on English if the desired language is not available, but that's not happening in your case. It's a pretty serious bug so I would be keen to fix it and release it in 3.7.2 soon.

[wetneb]

I think I can see the problem: it is indeed caused by extensions not having a German translation file. That should normally not be a problem, but here is what is happening:

• The frontend first requests the translations in German for the core software. We do have them, so they are loaded and the global (!) lang variable is set to de.
• The frontend can start displaying German translations in the UI elements it builds
• Then the frontend requests translations for other modules, such as the database extension. We do not have that, so the server replies with the default English messages, and the frontend switches to lang = 'en'
• After that, whenever we try to build UI elements that belong to the core software, we lookup their translation in the local store, and we do so in English because now lang = 'en'. But because we have not loaded the English strings for the core module, this fails and we just display the identifiers instead.

[thadguidry]

@wetneb why is it normally a problem?

Also on this:

But because we have not loaded the English strings for the core module, this fails and we just display the identifiers instead.

Why can't we load them all the time (as a default) so that English strings can be readily available when needed as a fallback? I thought we did it like that before, no? Did that change or is that a core bug?

[wetneb]

Good catch, I was missing a negation there. Fixed.

[wetneb]

Why can't we load them all the time (as a default) so that English strings can be readily available when needed as a fallback? I thought we did it like that before, no? Did that change or is the core bug?

The backend will insert the English translations as fallback when any other language is requested. The frontend does not know about this so it will treat all returned strings as belonging to the desired language instead. So if the frontend itself looks in its own cache for strings in English, it will not find those. It's quite messy indeed! One could remove the fallback mechanism from the backend and make sure it only happens in the frontend. But then we should make sure we don't create more HTTP requests for that language loading since it's already a pretty lengthy process to load them (and is happening in a synchronous way, so with a significant impact on page loading time).

[thadguidry]

Hmm, we probably need to make the frontend... aware | smarter. And that way the fallback mechanism in backend can stay.