Fix i18n test strings - #34819
Conversation
Adopts the completed Localazy review for element-web and shared-components English sources. Pure value changes; the key set matches develop. Supersedes the en_EN portion of the automated Localazy download (#34776). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
English: adopt the reviewed terminology (Request to join, chat) in restricted-guests; single-character ellipsis per UI copy guidelines. German: fix Benutzername->Nutzername, passive progress state for account creation, Weiter instead of Fortfahren, Konto consistency, du-form body text, and hyphenated loanword compound (Portal-Logo), per the German translation guide. The error string's German now matches what the English actually says. These module translation files are not managed by Localazy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
9f14f70 to
b0ca155
Compare
b0ca155 to
b595897
Compare
Update literal assertions and regenerate snapshots for the reviewed en_EN strings (session->device, homeserver->account provider, click->select, room->chat, and related rewordings) across jest, vitest, shared-components, and playwright suites. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
b595897 to
bce7ba3
Compare
GitHub dropped the pull_request event for the previous push; empty commit to re-run the test workflows. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…rings # Conflicts: # apps/web/src/i18n/strings/en_EN.json
develop gained invite.error_forbidden, invite.room_failed_partial_* and settings.notifications.labs_notice_error after the Localazy review snapshot; carry their English values forward and drop the superseded room_failed_partial. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
37818d8 to
618134d
Compare
618134d to
d08d4dc
Compare
d08d4dc to
3999357
Compare
Adopt develop's post-review invite string changes (PR #34590 dropped trailing periods and reworded the invite error family) since its tests assert them; keep the reviewed terminology for error_version_unsupported_*. Update playwright specs for remaining reviewed strings that hid in regexes and templates (edit-history tooltip, knock rejection event text, call-in-progress a11y labels, device counts), and dismiss the 'Introducing Sections' release announcement in shared helpers before using the compose menu - the announcement replaces the menu while shown and surfaces raceily depending on toast lifecycle. Refresh the affected screenshots against the merged build. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3999357 to
811ed17
Compare
mxandreas
left a comment
There was a problem hiding this comment.
I think the designers should review these changes, as well as update Figma if they agree. In my opinion there are several changes which are matter of taste - I think we should avoid changes unless there's some clear reason to change. Otherwise each person comes with their taste
The change I did not get at all was Click vs. Select. Usually you Select a menu item but you Click on a button. Has this changed recently?
| "back": "Back", | ||
| "cancel": "Cancel", | ||
| "click": "Click", | ||
| "click": "Select", |
There was a problem hiding this comment.
To me Click vs. Select sounds quite a major change and I am also not sure if this works in all contexts it is being used. It may be better in some, but may make it worse in others.
There was a problem hiding this comment.
You can only click when you have a mouse. Element Web runs on pointer, touch and keyboard. Click is for pointer. A disabled user hearing "click" when navigating with the keyboard will be irritated. Beyond that, the source was already a mix. Changing strings consistently to "select" tidies that up.
Microsoft does the same: https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/click
There was a problem hiding this comment.
Select to me sounds like a range, more akin to highlight, either way here the key should be changed. Things in actions and common should be 1:1 mapped with their keys. Also we don't technically support touchscreens. Keyboard accessibility though yes, where select would be closer to focus rather than activate (enter) so not sure select is the right verb there either.
There was a problem hiding this comment.
Microsoft does the same: https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/click
@kongo09 If that is the trigger, then I think we should not hide such principle changes within between quick fixes to typos and discrepancies. The design team would first need to adopt this new principle - so we know to use it in the new places in the future, etc. And the question is also - how much does it actually matter.
There was a problem hiding this comment.
Inconsistency matters as it confuses the users. a11y matters as we want to be inclusive.
| "hide": "Hide", | ||
| "invite": "Invite", | ||
| "new_conversation": "New conversation", | ||
| "new_conversation": "New", |
There was a problem hiding this comment.
What is the justification for this? I am not saying that it is worse but is it better, why?
| "menus": { | ||
| "user_menu": { | ||
| "clear_status": "Clear", | ||
| "clear_status": "Clear status", |
There was a problem hiding this comment.
What's the logic in here? In another case we removed conversation from "New conversation", now in here we are adding status to "Clear status".
| "mark_all_read": "Mark all as read", | ||
| "mentions_keywords": "Mentions and keywords", | ||
| "message_didnt_send": "Message didn't send. Click for info.", | ||
| "message_didnt_send": "Message didn't send. Select for info.", |
There was a problem hiding this comment.
Select sounds very weird to me.
There was a problem hiding this comment.
See rationale above. Click is not a helpful verb for an app on pointer, touch and keyboard.
| }, | ||
| "m.room.avatar": { | ||
| "changed_img": "%(senderDisplayName)s changed the room avatar to<img/>", | ||
| "changed_img": "%(senderDisplayName)s changed the chat avatar to <img/>", |
There was a problem hiding this comment.
I wonder if this individual change make sense if room is used throughout the UI.
There was a problem hiding this comment.
There might be an inconsistency here as we have chat in some place and room in some others. For this specific case, the context is clear and we can remove either. I'll do that.
There was a problem hiding this comment.
This is inconsistency here on the second toggle. The title is Report room but the description uses the word "chat".
There was a problem hiding this comment.
Imo this is misleading to call homeserver: account provider. The matrix community, its documentation and the spec call it homeserver. The user is seeing this two terms in the application and can confuse him.
There was a problem hiding this comment.
The terminology has been decided long time ago by the backend team. The text here specifically make clear that there is either an account provider = third-party institution providing the account, or a self-managed homeserver. So it's one of the very few places where the homeserver term survives.
There was a problem hiding this comment.
If you are using Synapse + MAS + e.g. Keycloak, are all 3 your "Account Provider"?
Or do they have more specific names
- Matrix Account Provider
- Other Matrix Account Provider
<Company>Account Provider
There was a problem hiding this comment.
You're talking an administrator / tech perspective. The product should talk to the end user, unless we're inside the /devtools or the Admin console
There was a problem hiding this comment.
The user manages all 3 though.
They enter 1 domain into the server picker, e.g. matrix.org - then get taken to account.matrix.org then accounts.google.com for Google SSO. If they were to save one in their password manager as "[Matrix/Element] Account Provider" - given that is what we call it which would you suggest it be?
There was a problem hiding this comment.
In your example, The Matrix.org Foundation is the account provider identified by entering matrix.org. That this triggers a flow to some subdomain of matrix.org (in that case even called "account") should not irritate anyone. If you then select Google SSO, you also should know what you're doing. None of this should require a technical undestanding of what's actually happening, or what a homeserver or MAS is.
Not sure what you want to save in your password manager if you use Google SSO?
There was a problem hiding this comment.
But if I enter "The Matrix.org Foundation" in the "Other account provider" box is quite obviously won't work? So the account provider is obviously matrix.org according to your updated label. But then I actually enter my credentials into account.matrix.org or Google? Seems confused
There was a problem hiding this comment.
What you point out is a confused flow that is very hard for ordinary users to understand, but that's a separate problem. On the wording itself, it would maybe be one improvement if the helper text inside the box wouldn't double "Other account provider" but say: "Domain name" because that is what you actually enter of your account provider. Right now, the text is redundant anyhow.
There was a problem hiding this comment.
Yes, I think that's inline with what I said. They talk about "account" and "account type" and "account name". But as I suggest above, the helper text in the textbox could be domain name or even server name but certainly not "homeserver".
There was a problem hiding this comment.
Title of the dialog is "Report room" but the description is using the term "chat".
There was a problem hiding this comment.
ditto Report room and chat in description
There was a problem hiding this comment.
I don't think this should be in this PR. Imo we should move in to its own dedicated PR to improve german translations of the modules.
There was a problem hiding this comment.
Also I think these translations were specified by the customer, so I doubt they'd like to see them change without communication
There was a problem hiding this comment.
We can move it out. Overall the question would be if translations at Element shouldn't be internally consistent and if a customer wants a customization, that should happen elsewhere?

Fixes the test failures from the English source-string review, superseding #34776.
actions/localazy-downloadand overlays the completed Localazyreview state for en_EN (element-web + shared-components); includes the
full language payload from the bot PR
terminology (session→device, homeserver→account provider, click→select,
room→chat, …) across jest, vitest, shared-components and playwright
by Localazy) with the new terminology in English and German
(
acconttypo, MapStyleUrlNotConfigured wording, stray\ninroom_list.a11y.voice_call)
Notes for reviewers:
CI's Run Visual Tests flags them