fix(i18n): banner/push follow the interface language even without a Settings change #118

Merged
developer merged 1 commits from feature/banner-language-followup into development 2026-06-22 18:17:03 +00:00
Owner

A user who never changed the language in Settings stayed on the creation-time preferred_language seed after switching the device language: UI followed the device (ru) but the banner + out-of-app push (both server-resolved from preferred_language) stayed en. The on-adopt reconcile was gated on an explicit local choice (localeLocked); a system-guess locale was never pushed.

Reconcile preferred_language to the active interface locale on every adopt/link regardless of how it was chosen (persistLanguageToServer self-gates for guests / when equal). Banner + push are the only server-rendered language surfaces and both read preferred_language, so the whole interface stays consistent. Drops the now-dead localeLocked flag.

Stacked on #117 (bot welcome) — diff self-cleans once #117 merges. Review on the contour: open on an en device, switch to ru, reopen — banner should be ru.

A user who never changed the language in Settings stayed on the creation-time preferred_language seed after switching the device language: UI followed the device (ru) but the banner + out-of-app push (both server-resolved from preferred_language) stayed en. The on-adopt reconcile was gated on an explicit local choice (localeLocked); a system-guess locale was never pushed. Reconcile preferred_language to the active interface locale on every adopt/link regardless of how it was chosen (persistLanguageToServer self-gates for guests / when equal). Banner + push are the only server-rendered language surfaces and both read preferred_language, so the whole interface stays consistent. Drops the now-dead localeLocked flag. **Stacked on #117** (bot welcome) — diff self-cleans once #117 merges. Review on the contour: open on an en device, switch to ru, reopen — banner should be ru.
developer added 2 commits 2026-06-22 18:09:51 +00:00
feat(telegram): localized /start welcome with channel & chat follow links
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 15s
CI / ui (pull_request) Has been skipped
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m17s
aa330b726e
The main bot answered /start with a single English line ("Tap to open Scrabble.").
Localize it: Russian or English by the sender's reported Telegram language
(Message.from.language_code, which the Bot API carries on the message itself — there is
no separate user-update event — English fallback), with the longer welcome copy and a
localized launch button ("Открыть «Эрудит»" / "Open “Erudite”").

The welcome links the game channel and the discussion chat by their public @username,
resolved once at startup from the configured TELEGRAM_GAME_CHANNEL_ID / TELEGRAM_CHAT_ID
via getChat and cached. A handle that is unset, private, or unreadable degrades to a
generic noun ("the channel" / "our chat") rather than a dangling "@", so the paragraph
always reads cleanly (the bot's info screen still lists the real links). Adds
GameChannelID to bot.Config (wired from the existing config) for the channel handle.

Tests: startText localization + handle embedding + per-slot generic fallback; handleStart
language selection; resolveWelcomeHandles. README updated.
fix(i18n): reconcile preferred_language to the interface locale on every adopt
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 16s
CI / ui (pull_request) Successful in 54s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m22s
81b716569f
A user who never changed the language in Settings kept their account at the
creation-time preferred_language seed (e.g. en from the Telegram launch language_code)
even after switching the device to another language: the UI followed the device (ru) but
the ad banner and out-of-app push — both resolved server-side from preferred_language —
stayed en. The on-adopt reconcile was gated on an explicit local choice (localeLocked),
so a system-guess locale was never pushed through.

Reconcile preferred_language to the active interface locale (app.locale) on every session
adopt and link, regardless of how the locale was chosen; persistLanguageToServer already
self-gates (a no-op for guests and when already equal), so there is no steady-state write.
The banner and push are the only server-rendered language surfaces and both read
preferred_language, so this keeps the whole interface consistent — not just the banner.
Drop the now-dead localeLocked flag (the reconcile guards were its only readers; the saved
prefs.locale still restores the UI choice per device).

Trade-off: preferred_language now follows the most-recently-opened device, so an explicit
choice on one device can be overwritten by a system guess on another (the "explicit" mark
is local, per-device); making it globally sticky would need a DB flag.

Docs: ARCHITECTURE §4 + the profile field.
owner approved these changes 2026-06-22 18:16:21 +00:00
developer merged commit 9d1ca213d6 into development 2026-06-22 18:17:03 +00:00
developer deleted branch feature/banner-language-followup 2026-06-22 18:17:03 +00:00
Sign in to join this conversation.
No Reviewers
No Label
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: developer/scrabble-game#118