Skip to content

Fix i18n test strings - #34819

Open
kongo09 wants to merge 7 commits into
developfrom
fix-i18n-test-strings
Open

Fix i18n test strings#34819
kongo09 wants to merge 7 commits into
developfrom
fix-i18n-test-strings

Conversation

@kongo09

@kongo09 kongo09 commented Aug 25, 2026

Copy link
Copy Markdown
Member

Fixes the test failures from the English source-string review, superseding #34776.

  • Merges actions/localazy-download and overlays the completed Localazy
    review state for en_EN (element-web + shared-components); includes the
    full language payload from the bot PR
  • Updates test assertions and regenerates snapshots for the reviewed
    terminology (session→device, homeserver→account provider, click→select,
    room→chat, …) across jest, vitest, shared-components and playwright
  • Aligns the module translations (banner, restricted-guests — not managed
    by Localazy) with the new terminology in English and German
  • Includes three string corrections made in Localazy during this work
    (accont typo, MapStyleUrlNotConfigured wording, stray \n in
    room_list.a11y.voice_call)

Notes for reviewers:

  • Localazy Download #34776 can be closed in favour of this PR
  • Screenshot updates for the visual tests to follow in this branch if
    CI's Run Visual Tests flags them

@kongo09
kongo09 requested review from a team as code owners August 25, 2026 22:59
@CLAassistant

CLAassistant commented Aug 25, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

kongo09 and others added 2 commits August 26, 2026 01:05
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>
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>
@kongo09
kongo09 force-pushed the fix-i18n-test-strings branch from b595897 to bce7ba3 Compare August 26, 2026 11:04
kongo09 and others added 3 commits August 26, 2026 14:24
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>
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>

@mxandreas mxandreas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@t3chguy t3chguy Aug 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Select sounds very weird to me.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/>",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this individual change make sense if room is used throughout the UI.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@florianduros
florianduros requested a review from a team September 1, 2026 09:08

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inconsistency here on the second toggle. The title is Report room but the description uses the word "chat".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@t3chguy t3chguy Sep 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@kongo09 kongo09 Sep 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't call Email or frankly the Mail.app that Apple ships on macOS are very hard for ordinary users to understand they quite happily use the word Server rather than Account Provider or Email Provider

image

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title of the dialog is "Report room" but the description is using the term "chat".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto Report room and chat in description

@florianduros florianduros Sep 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think these translations were specified by the customer, so I doubt they'd like to see them change without communication

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread packages/shared-components/src/i18n/strings/en_EN.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-Task Tasks for the team like planning

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants