Raw message IDs visible instead of messages/translations

[jnthn]

Username:

TITLE

Raw message IDs visible instead of messages/translations

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.81 Update #6
CentOS Linux 7.9.2009 (Core)

Plesk Obsidian 18.0.82 Update #1
AlmaLinux 10.2 (Lavender Lion)

PROBLEM DESCRIPTION

Often when I open Plesk, the dashboard shows raw message IDs instead of the correct messages/translations. This happens on two of my Plesk servers (both versions mentioned). Often it can be resolved by refreshing the page.

STEPS TO REPRODUCE

1. Open Plesk panel URL
2. Log in

ACTUAL RESULT

Dashboard showing many components.Pages.Home.*** texts

EXPECTED RESULT

Dashboard showing regular texts

ANY ADDITIONAL INFORMATION

Current browser: Safari 27.2 (22625.2.8.11.9)

It happens regardless of the translations (one of my servers is set to English, the other to Dutch)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[tessa67]

Hi, @jnthn

Could you check whether this also happens in another browser (Chrome/Firefox) or in a private window with a cleared cache? Since it affects two different servers, versions and languages, and a reload fixes it, a client-side caching/loading issue (e.g. Safari-specific) seems possible. If it still occurs, please check the Network tab in the browser dev tools for a failing or slow request to the translation/locale resource and post the status code or a screenshot. Also, is a reverse proxy or CDN (e.g. Cloudflare) in front of the panel?

Regards
Tessa

 

[jnthn]

Could you check whether this also happens in another browser (Chrome/Firefox) or in a private window with a cleared cache?

It doesn't happen in Chrome, Firefox, or a private Safari window. It still happens in Safari (regular window) after clearing my cache.

Since it affects two different servers, versions and languages, and a reload fixes it, a client-side caching/loading issue (e.g. Safari-specific) seems possible.

Clarification: a reload doesn't always fix it. If it doesn't fix it immediately, it usually gets fixed when I go browse to some other pages and later return to the dashboard.

If it still occurs, please check the Network tab in the browser dev tools for a failing or slow request to the translation/locale resource and post the status code or a screenshot.

The locale endpoints visible in the network tab and works fine (fast and proper response). I don't see a "translation" endpoint.

Also, is a reverse proxy or CDN (e.g. Cloudflare) in front of the panel?

No, both panels are accessed directly.

 

[tessa67]

Hey @jnthn,

Thanks for the detailed follow-up, that rules out quite a lot.

Since it's Safari-only (regular window, persists after cache clear) and the locale endpoints look fine in the Network tab, this smells like a Safari-specific issue with how the dashboard lazy-loads the translation bundles. A few things I'd try next:

1. Check the Console tab in Safari's dev tools when it happens — any JS errors or failed module imports? Safari sometimes chokes on cached JS modules in a weird state.
2. In the Network tab, filter by "JS" and reload. Look for a request that returns 304 or gets served from cache (disk/memory) but has a stale/empty body — Safari is known for this with ES modules.
3. Try disabling "Preload the most frequently visited websites" in Safari settings, or test in a completely fresh Safari profile (not just private window) to rule out profile-level caching.
4. Web Inspector > Storage tab — clear "Website Data" specifically for the panel host, not just the general cache.

The fact that navigating to other pages and coming back fixes it also points to a module/state caching thing rather than the locale API itself.

Might still be worth opening a bug report with Plesk support with the Safari version and a Console/Network screenshot when it happens — even if it's client-side, they should be able to make the dashboard more resilient to it.

Regards
Tessa