fix: register i18n formatters in sessions that start in English
Proposed changes (including videos or screenshots)
TranslationProvider registers the capitalize formatter on i18next's initialized event, with the listener attached right after i18n.init(). English is bundled in resources, so a session that starts in English initializes synchronously: initialized has already fired when the listener is attached, and the formatter is never registered for that session.
Visible today when a session starts in English (browser language or userLanguage in local storage) and then switches, e.g. to pt-BR after login: {{roomType, capitalize}} in Encrypted_RoomType / Encrypted_messages renders "canal criptografado" instead of "Canal criptografado". A session that starts in pt-BR fetches its locale file, so the event fires later and the formatter works, which is why this went unnoticed.
The formatter is now registered right after init(), regardless of how init completes.
Extracted from #41650 (user information redesign), where @ivans-netto found and fixed this while adding a lowercase formatter for an English string. That formatter and its string stay in #41650. Stacked on #42503; #41650 is stacked on top.
Issue(s)
Steps to test or reproduce
- With the browser in English (or
userLanguage=en), log in as a user whose language is Português (Brasil). - Open an end-to-end encrypted room.
- Before: the encrypted room label reads "canal criptografado". After: "Canal criptografado".
Further comments
TranslationProvider.formatters.spec.tsx starts a session in English, switches to pt-BR and checks the capitalized output. It fails against the previous implementation ("canal criptografado"). It's a separate file because the provider initializes i18next once per module, and the existing spec starts in pt-BR.
Summary by CodeRabbit
- Bug Fixes
- Fixed capitalization in translated text after switching languages from an English-started session.