Offer "Pseudo-English" (qps-ploc) as a UI language for i18n testing (BL-16748) - #8283
Open
andrew-polk wants to merge 1 commit into
Open
Offer "Pseudo-English" (qps-ploc) as a UI language for i18n testing (BL-16748)#8283andrew-polk wants to merge 1 commit into
andrew-polk wants to merge 1 commit into
Conversation
Contributor
|
| Filename | Overview |
|---|---|
| src/BloomExe/Program.cs | Configures pseudo-localization before localization-manager initialization and safely falls back to English on channels where it is unavailable. |
| src/BloomExe/Workspace/WorkspaceView.cs | Adds a stable pseudo-locale label and places it last in the language menu while preserving existing selection behavior. |
| src/BloomExe/web/I18NApi.cs | Applies pseudo-localization to English fallback responses that bypass normal L10NSharp lookups, while excluding numeric IDs. |
| src/BloomExe/Book/TranslationGroupManager.cs | Prevents the testing-only pseudo-locale from generating persisted translated content in books. |
| src/BloomExe/web/controllers/CommonApi.cs | Excludes qps-ploc from the language chooser used to author persistent hint content. |
| src/BloomBrowserUI/react_components/TopBar/TopBar.tsx | Adds a stable language-independent data attribute to workspace tabs for automation. |
| .github/skills/bloom-automation/switchWorkspaceTab.mjs | Prefers the new stable workspace-tab selector while retaining legacy label-based fallbacks. |
| src/BloomTests/Workspace/PseudoLocalizationTests.cs | Covers pseudo-locale naming/completeness and non-development channel gating, though not the I18N fallback branches. |
| src/BloomExe/BloomExe.csproj | Upgrades L10NSharp to the beta version providing runtime pseudo-localization support. |
Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mas..." | Re-trigger Greptile
Contributor
Author
|
[Claude Opus 5 (1M context) during preflight] Consulted Devin on 2026-09-02 18:29 UTC up to commit Clean: no bugs, no Investigate flags, no informational items. Nothing to mirror. |
…BL-16748)
We have no way to see which of Bloom's on-screen strings actually go
through localization. A string someone hard-coded, a placeholder that got
mangled, a label the layout clips once it grows -- all of it looks fine in
English, and only surfaces when a translator or a user in another
language hits it.
So on the developer and alpha channels the UI Language menu now offers
"Pseudo-English (i18n test)". L10NSharp 10.1.0-beta0001 pseudolocalizes
every lookup for the standard qps-ploc pseudo-locale, transforming the
live English at lookup time -- each vowel doubled and accented, the whole
string bracketed, so "Title Missing" becomes "[Tîitlée Mîissîing]". A
tester then reads the problems straight off the screen: plain English
means the string was never internationalized, a visible {0} or %0 means a
broken placeholder, a missing "]" means truncation, brackets mid-sentence
mean the sentence is concatenated at runtime, and clipped layout means we
cannot cope with the ~30-40% growth real translations bring. No qps-*
translation files exist or are ever written.
- Program.SetUpLocalization turns the locale on for the developer and
alpha channels only, and GetDesiredUiLanguage refuses a stored qps-ploc
on a channel that does not offer it -- otherwise a setting carried over
from an alpha would leave a release user with a mangled UI and no menu
entry to escape it.
- WorkspaceView names the locale itself (Palaso's language-name lookup
has nothing useful to say about a pseudo-locale) and puts it last in the
menu rather than sorting it among real languages.
- I18NApi pseudolocalizes the English fallback it returns for ids that are
not in the English XLIFF. Without this those come back as plain English
and are indistinguishable from hard-coded text, which defeats the
exercise.
- The locale is excluded from the two places where the list of available
localizations feeds *book data* rather than the UI: the pre-translated
content TranslationGroupManager writes into a new book, and the
hint-bubble language chooser.
- DistFiles/localization/README.md documents that the locale is
runtime-derived, that no qps-* XLF should ever exist, and which surfaces
stay plain English on purpose (the whole-file localizations -- template
readmes, help pages, xmatter descriptions) so the tester's rule stays
exact.
- Bloom's workspace tabs carry a data-workspace-tab attribute so
automation can find them without matching the visible English label,
which breaks under this locale and under any real localization.
Verified end to end in a running Bloom against the released package: the
menu entry, the WinForms chrome and dialogs, the React UI, template and
page labels, the toolbox and hint bubbles all transform, while book
content, book titles, the collection name and language data stay plain.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
andrew-polk
force-pushed
the
BL-16748-pseudo-english
branch
from
September 2, 2026 22:15
c64f5ad to
a436f8e
Compare
andrew-polk
marked this pull request as ready for review
September 2, 2026 22:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
We have no way to see which of Bloom's on-screen strings actually go through localization. A string someone hard-coded, a placeholder that got mangled, a label the layout clips once it grows — all of it looks perfectly fine in English, and only surfaces when a translator or a user in another language hits it.
What the PR does
On the developer and alpha channels, the UI Language menu now offers Pseudo-English (i18n test). L10NSharp 10.1.0-beta0001 pseudolocalizes every lookup for the standard
qps-plocpseudo-locale by transforming the live English at lookup time — each vowel doubled and accented, the whole string bracketed, soTitle Missingbecomes[Tîitlée Mîissîing]. A tester can then read the problems straight off the screen: plain English means the string was never internationalized, a visible{0}or%0means a broken placeholder, a missing]means truncation, brackets mid-sentence mean the sentence is concatenated at runtime, and clipped layout means we can't cope with the ~30–40% growth real translations bring. Noqps-*translation files exist or are ever written.Program.SetUpLocalizationturns the locale on for the developer and alpha channels only, andGetDesiredUiLanguagerefuses a storedqps-plocon a channel that doesn't offer it — otherwise a setting carried over from an alpha would leave a release user with a mangled UI and no menu entry to escape it.WorkspaceViewnames the locale itself (Palaso's language-name lookup has nothing useful to say about a pseudo-locale) and puts it last in the menu rather than sorting it among real languages.I18NApipseudolocalizes the English fallback it returns for ids that aren't in the English XLIFF. Without this those come back as plain English and are indistinguishable from hard-coded text, which defeats the exercise.TranslationGroupManagerwrites into a new book, and the hint-bubble language chooser.DistFiles/localization/README.mddocuments that the locale is runtime-derived, that noqps-*XLF should ever exist, and which surfaces stay plain English on purpose (the whole-file localizations — template readmes, help pages, xmatter descriptions) so the tester's rule stays exact.data-workspace-tabattribute so automation can find them without matching the visible English label, which breaks under this locale and under any real localization.Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16748
Devin review
This change is