Repository navigation
Sign up new users in their browser language - #451
Merged
Merged
Conversation
Email signups without a picked language and every Google/GitHub signup were created in English, then most switched on the welcome screen minutes later. Lifecycle emails read users.locale, so the first onboarding email often went out in the wrong language. Register and the social buttons now send signupLocale: the picked language, else the browser language (detectBrowserLanguage, so pt-PT becomes pt-BR), else Locale::DEFAULT. OAuth carries it through PreservesSignupPreferences, and CreateUser falls back to the default for a missing or unsupported value. Returning OAuth users keep their stored locale. The guest pages still render in the default language. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The test visited /register without turning self-hosted off, so the page returned 404 and the buttons were never there. Its waits now go through the shared helpers, and the inline comment in useGuestLocale is gone.
The browser test drops its querySelector helper for assertValue and attribute, and useGuestLocale names the browser language and the page default instead of inlining them in the fallback chain.
Email, Google and GitHub signups store the language they were sent and push it to PostHog; Google and GitHub fall back to the default for a missing or unsupported value and leave a returning user's language alone. In the browser, a language picked on the register page wins over the browser one, and a full email signup creates the account in the browser language.
An invited signup by email, Google or GitHub stores the language it was sent, and the register page opened from an invite sends the browser language with the invite. A new person who starts on the login page signs up through Google or GitHub in the browser language, followed from the button's link to the created account. With several browser languages the first one TryPost supports wins.
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
New accounts start in English unless the visitor picks a language on the auth page. Google and GitHub signups always store
Locale::DEFAULT, and email signups send the page's default when nothing is picked. Most people then switch on the welcome screen a few minutes later.Lifecycle emails pick their language from
users.locale, so the first onboarding email often went out in English to Portuguese and Spanish speakers. In PostHog, 31 of 33 language switches happened within 17 minutes of signup. A few people with a pt or es browser never switch and stay in English. The onboarding wait in PostHog is now 20 minutes as a stopgap; this PR fixes the source.Fix
signupLocaleinuseGuestLocale. The language the visitor picked, else the browser's language (detectBrowserLanguageover the supported codes, sopt-PTbecomespt-BR), else the default.localefield.localequery param on the start route.PreservesSignupPreferenceskeeps it in the session with the zone, week start and clock, and both controllers pass it toCreateUser.CreateUserusesLocale::tryFrom(...) ?? Locale::DEFAULT, so a missing or unsupported value falls back instead of throwing.localeonly after a pick).AGENTS.md"UI locale" and "Signup detection" updated.Tests
tests/Feature/Auth/SignupPreferencesTest.php). Google signup stores thept-BRsent to the OAuth start. GitHub signup with an unsupported (sv) or missing locale falls back toLocale::DEFAULT. An existing Google user logging in keepsLocale::Japanese.tests/Browser/SignupPreferencesTest.php). The register form sends the browser language when none is picked:pt-BR→pt-BR,pt-PT→pt-BR,es-ES→es,sv-SE→en. On/registerwithes-ES, the Google and GitHub links carrylocale=es. The existing social-button test now also expectslocale=en.Not run locally: the machine that wrote this has no PHP, Postgres or Docker, so the Pest and browser suites need to run in CI or on review. ESLint and Prettier were checked on the changed frontend files (the only warnings are the missing generated Wayfinder routes and an existing Prettier note on
Register.vue, both also onmain).