Public File Request guest identification dialog is not translated into Japanese

[kou0223]

Summary

When using a public File Request page in Nextcloud Server 34 with the UI language set to Japanese, the guest identification dialog is displayed in English instead of Japanese.

The affected strings are:

• Name
• Enter your name
• Submit name

After investigating the implementation, it appears that the Japanese translations are present and bundled correctly, but they are not selected at runtime.

I may be misunderstanding part of the translation pipeline, so if my analysis is incorrect, please let me know.

---

Environment

• Nextcloud Server 34
• Official Docker image (nextcloud:34-apache)
• Public File Request
• Browser language: Japanese

Runtime values:

document.documentElement.lang
// "ja"

navigator.language
// "ja"

window.OC.getLanguage()
// "ja"

---

Steps to reproduce

1. Set the Nextcloud UI language to Japanese.
2. Create a File Request.
3. Open the public File Request URL.
4. The guest identification dialog appears before uploading files.

---

Expected behavior

The dialog should display:

名前
名前を入力してください
名前を送信する

---

Actual behavior

The dialog displays:

Name
Enter your name
Submit name

---

Investigation

I traced the implementation and found that the guest identification dialog is provided by @nextcloud/dialogs (PublicAuthPrompt.vue) via showGuestUserPrompt().

The production bundle (dist/core-common.js) already contains the Japanese translations.

For example:

msgid:"Enter your name"
msgstr:["名前を入力してください"]

msgid:"Submit name"
msgstr:["名前を送信する"]

The translations are bundled under:

language:"ja_JP"

Meanwhile, the runtime language reported by Nextcloud is:

window.OC.getLanguage()
// "ja"

From my reading of @nextcloud/l10n, GettextBuilder.detectLanguage() uses the language returned by getLanguage(), while build() appears to load translations only for an exact language key.

This seems to result in the runtime looking for:

translations["ja"]

while the bundled translations are registered as:

translations["ja_JP"]

---

Verification

To verify this hypothesis, I modified only the bundled language identifier in the generated dist/core-common.js.

-language:"ja_JP"
+language:"ja"

No translation strings or application logic were modified.

After performing a hard reload with the browser cache disabled, the dialog immediately displayed:

名前
名前を入力してください
名前を送信する

Changing only the bundled language identifier was sufficient to make the translations work.

This suggests that the translations themselves are correct and available, but they are not selected because the runtime language (ja) does not match the bundled language key (ja_JP).

---

Additional investigation

For completeness, I also checked the repository history.

l10n/ja_JP.pot appears to have been introduced by the Transifex integration in commit:

0c0cbbccf727e0bbb6a574d6c556b90003ee50e1

The current build process derives the bundled language identifier directly from the translation filename, so ja_JP.pot becomes:

language:"ja_JP"

---

Question

Is this the intended behavior?

If not, would one of the following approaches be appropriate?

• Register the Japanese translations under ja
• Provide an alias between ja and ja_JP
• Adjust the translation generation process
• Handle this during runtime language resolution

If this issue belongs in another repository (for example nextcloud-l10n or another translation-related component), I'd be happy to move it or open a new issue there instead.

I'm also happy to test a proposed fix if that would be helpful.

Thank you for maintaining Nextcloud and its libraries.