Repository navigation
[Translations] Make the login error dialog labels public - #2089
Merged
Merged
Conversation
A failed login opens the shared error dialog before the user is authenticated. At that point Studio only receives the public translation keys, so the dialog title showed the raw key "error" and, since Studio UI 2026.3, the button showed "alert-modal.ok-text". Add both keys to PublicTranslations::PUBLIC_KEYS. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The implementation is sound, but its public-translation documentation must be updated to reflect the expanded allowlist.
1 open finding
What changed in this PR
Verdict: Needs changes. The PR correctly exposes shared login-error dialog labels to unauthenticated users.
Changes:
- Adds
errorandalert-modal.ok-textto the public allowlist. - Adds a focused regression test for both keys.
Review contract:
- Root cause fixed at the owning allowlist (
PublicTranslations.php:35-37). - Both allowlist consumers inherit the change; no BC break identified.
- Regression coverage is appropriately scoped (
TranslatorServiceTest.php:66-74). - Documentation remains inaccurate:
doc/03_Extending/07_Translations.md:35says only login-form strings are public. - Runtime catalogue values were not independently verifiable from this diff.
| File | Description |
|---|---|
src/Util/Constant/PublicTranslations.php |
Adds shared error-dialog labels to public translations. |
tests/Unit/Service/Translator/TranslatorServiceTest.php |
Verifies both labels are returned before authentication. |
🧠 Review effort: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Changes in this pull request
Resolves #
A failed login (e.g. "Invalid credentials") opens Studio's shared error dialog while the user is still unauthenticated. At that point the UI only loads
PublicTranslations::PUBLIC_KEYS, which holds just the login and forgot-password form labels. So the dialog showed raw keys:error(useAlertModal().error()→t('error'))alert-modal.ok-text(studio-ui 2026.3 added thisokText)This PR adds both keys to the public allowlist. Their values are generic labels ("Error", "OK").
Additional info
TranslatorServiceTest::testLoginErrorDialogKeysArePublic: fails without the fix, passes with it. Unit suite green locally (1276 tests) inpimcore/pimcore:php8.4-debug-latest. php-cs-fixer and PHPStan not run locally; CI validates.errortitle also exists on 2025.4 and 2026.2. It is fixed from 2026.3 only, since this is not critical.errorand buttonalert-modal.ok-text.🤖 Generated with Claude Code