Environment
- mupdf-webviewer: 0.1.1 (latest via npm)
- Browser: Chrome 135, macOS
- System language: German (de)
- Browser language: German (de-DE)
Problem
When the browser/system language is set to a language not included in the WebViewer’s dictionary (currently only KOREAN, ENGLISH, JAPANESE are supported), the UI displays raw i18n keys instead of falling back to English.
For example, the search panel shows:
TEXT_SEARCH_VIEW_TITLEinstead of “Find”ITEMS_UNITinstead of “items”
The console is flooded with hundreds of warnings:
chunk-M2RGBLL6.js:279 i18n Dictionary for language "de" not exists.
This significantly slows down page loading due to the volume of warnings.
What I tried
- Setting
language: 'ENGLISH'in the init config — does not help, the i18n system readsnavigator.languagebefore the config is applied. - Calling
viewer.setLanguage(...)after init — tried multiple formats, none resolved the issue for already-rendered UI elements. - Changing Chrome’s language to English — this works, confirming the root cause is the missing fallback.
Expected behavior
When the browser language is not in the supported set (KOREAN, ENGLISH, JAPANESE), the viewer should fall back to English translations instead of displaying raw keys.
Suggested fix
In the i18n initialization logic, if the detected language has no dictionary, default to “en” before rendering any UI elements. The English dictionary already exists in the codebase (confirmed via grep — TEXT_SEARCH_VIEW_TITLE:"Find" is present in chunk-M2RGBLL6.js).
Workaround
Changing the browser language to English resolves the issue. However, this is not a viable solution for end users who work in non-English environments — which is the majority of users in continental Europe and Asia (outside Japan and Korea).
Additional context
The languageSchema shows ZodEnum with values ["KOREAN","ENGLISH","JAPANESE"]. Adding a fallback mechanism would benefit all users whose browser language is not one of these three — including German, French, Spanish, Chinese, and many others.