Bug Description
Public sharing pages (e.g., file/folder share links) do not load core translations, causing strings like "Set public name", "Change public name", "You are currently not identified.", and "User menu" to always appear in English, regardless of the configured language.
Steps to Reproduce
- Set
default_language and force_language to any non-English language (e.g., tr) in config/config.php
- Create a public share link for a file or folder
- Open the public share link in an incognito/private browser window
- Observe that "Set public name" and "You are currently not identified." appear in English
Expected Behavior
All UI strings on public sharing pages should respect the configured language and display translated text.
Actual Behavior
Core translation strings remain in English on public sharing pages. The translations exist in core/l10n/<lang>.json and core/l10n/<lang>.js but are never loaded.
Root Cause Analysis
The issue is in lib/public/AppFramework/Http/Template/PublicTemplateResponse.php. The constructor calls:
\OCP\Util::addScript('core', 'public-page-menu');
\OCP\Util::addScript('core', 'public-page-user-menu');
However, it never calls \OCP\Util::addTranslations('core').
Additionally, in lib/public/Util.php, the addScript() method (around line 159-161) skips the addTranslations() call when $application === 'core'. For non-core apps, addScript() automatically calls addTranslations(), but core is explicitly excluded.
The JavaScript bundle dist/core-public-page-user-menu.js uses runtime t("core", ...) calls for translation, which depend on core/l10n/<lang>.js being loaded. Since neither PublicTemplateResponse nor Util::addScript() loads core translations, the t() calls fall back to the original English strings.
Proposed Fix
Add \OCP\Util::addTranslations('core') in PublicTemplateResponse.php before the addScript calls:
\OCP\Util::addTranslations('core');
\OCP\Util::addScript('core', 'public-page-menu');
\OCP\Util::addScript('core', 'public-page-user-menu');
This is a one-line fix that ensures core/l10n/<lang>.js is loaded on public pages, making all t("core", ...) calls in the public page JavaScript bundles work correctly.
Environment
- Nextcloud version: 33.0.2
- PHP version: 8.x
- Affected languages: All non-English languages
- Affected pages: All public sharing pages (files, folders)
Bug Description
Public sharing pages (e.g., file/folder share links) do not load core translations, causing strings like "Set public name", "Change public name", "You are currently not identified.", and "User menu" to always appear in English, regardless of the configured language.
Steps to Reproduce
default_languageandforce_languageto any non-English language (e.g.,tr) inconfig/config.phpExpected Behavior
All UI strings on public sharing pages should respect the configured language and display translated text.
Actual Behavior
Core translation strings remain in English on public sharing pages. The translations exist in
core/l10n/<lang>.jsonandcore/l10n/<lang>.jsbut are never loaded.Root Cause Analysis
The issue is in
lib/public/AppFramework/Http/Template/PublicTemplateResponse.php. The constructor calls:However, it never calls
\OCP\Util::addTranslations('core').Additionally, in
lib/public/Util.php, theaddScript()method (around line 159-161) skips theaddTranslations()call when$application === 'core'. For non-core apps,addScript()automatically callsaddTranslations(), but core is explicitly excluded.The JavaScript bundle
dist/core-public-page-user-menu.jsuses runtimet("core", ...)calls for translation, which depend oncore/l10n/<lang>.jsbeing loaded. Since neitherPublicTemplateResponsenorUtil::addScript()loads core translations, thet()calls fall back to the original English strings.Proposed Fix
Add
\OCP\Util::addTranslations('core')inPublicTemplateResponse.phpbefore theaddScriptcalls:This is a one-line fix that ensures
core/l10n/<lang>.jsis loaded on public pages, making allt("core", ...)calls in the public page JavaScript bundles work correctly.Environment