Promote development → master: banner tip set + banner/push language fix #114

Merged

developer merged 13 commits from development into master 2026-06-22 18:28:01 +00:00

Conversation 2 Commits 13 Files Changed 48

+899 -145

developer commented 2026-06-22 14:28:54 +00:00

Owner

Copy Link

Copy Source

Promotes to production (→ tag v1.2.1):

• feat(ads): seed the house banner with the curated tip set (#112) — migration 00002 replaces the single seed tip with the 47 language-agnostic tips (bilingual ad_messages rows). Data-only; backend image rollback stays DB-safe; verified up/down + on the contour (47 rows).
• fix(i18n): banner/push language follows the device's saved choice (#113) — on profile load, reconcile preferred_language with the device's explicit language choice, so the banner and out-of-app push routing match the visible UI from the first open (no longer needs a Settings toggle).

Deploy: prod-deploy flags the migration → runs under the maintenance-window + pg_dump path (brief, safe). The migration applies on the prod backend at boot.

Promotes to production (→ tag v1.2.1): - **feat(ads): seed the house banner with the curated tip set** (#112) — migration `00002` replaces the single seed tip with the 47 language-agnostic tips (bilingual `ad_messages` rows). Data-only; backend image rollback stays DB-safe; verified up/down + on the contour (47 rows). - **fix(i18n): banner/push language follows the device's saved choice** (#113) — on profile load, reconcile `preferred_language` with the device's explicit language choice, so the banner and out-of-app push routing match the visible UI from the first open (no longer needs a Settings toggle). Deploy: prod-deploy flags the migration → runs under the maintenance-window + pg_dump path (brief, safe). The migration applies on the prod backend at boot.

developer added 4 commits 2026-06-22 14:28:54 +00:00

feat(ads): seed the house banner with the curated tip set ... c36543e54e

Migration 00002 replaces the default (house) campaign's single seed tip with
the 47 curated, language-agnostic Scrabble tips — one bilingual ad_messages row
each (body_en + body_ru), which the client round-robins per ARCHITECTURE §ads.

Data-only: the ad_messages schema is unchanged, so a backend image rollback
stays DB-safe. Down restores the original single seed tip. Verified up/down
against a throwaway Postgres (47 rows; apostrophes escaped).

fix(i18n): reconcile preferred_language with the device's saved language ... 90f0424de2

The UI language follows the device (the local choice / system guess) and is
deliberately not overridden from the account, but the advertising banner and
out-of-app push routing are resolved server-side from preferred_language. A
saved device choice the account had not recorded — picked while a guest, or
differing from the Telegram system-language seed — left the banner (and pushes)
in the wrong language until a Settings change rewrote preferred_language.

On profile load (adoptSession and the in-place link path) push the saved local
choice to the account when it differs (new pure helper languageNeedsServerSync;
no-op for guests and when already equal), so the banner and pushes match the
visible UI from the first open. Unit-tested.

Merge pull request 'feat(ads): seed the house banner with the curated tip set' (#112) from feature/ad-tips-default-banner into development 06cc4c1edc

Merge pull request 'fix(i18n): banner/push language follows the device's saved choice' (#113) from feature/banner-language-sync into development 08c2c5f660

developer referenced this pull request 2026-06-22 15:02:19 +00:00

feat(feedback): capture app version + browser zone; Filed time in three zones #115

owner approved these changes 2026-06-22 17:05:32 +00:00

Dismissed

developer added 3 commits 2026-06-22 17:07:23 +00:00

feat(feedback): capture the app version; show version + local Filed time ... b78ce42922

Each feedback submission now carries the client app version (__APP_VERSION__),
snapshotted like the interface language: FlatBuffers FeedbackSubmitRequest gains
a version field → gateway transcode → backend, persisted in a new nullable
feedback_messages.app_version column (migration 00003, additive so an image
rollback stays DB-safe). The operator console detail shows the app version and
renders the Filed time in UTC plus the sender's time zone (fmtTimeIn).

Touches: fbs schema + regenerated Go/TS codegen, codec + transport (the client
attaches its build), gateway transcode + backendclient, feedback store/service,
admin view + template, docs (ARCHITECTURE §15, FUNCTIONAL + _ru). Verified:
feedback integration tests (migration + version round-trip), codec round-trip,
check/unit/build green.

feat(feedback): capture the browser UTC offset; Filed time in three zones ... 004aca4e97

The account time zone defaults to UTC until a player saves a profile, so a
report's Filed time could only render in UTC even for a player clearly in
another zone. Capture the client's detected "±HH:MM" offset (browser_tz) with
each submission and show the Filed time in three zones in the operator console
— UTC, the browser offset detected at submit, and the sender's saved profile
zone — each shown "N/A" when not known, so the operator can tell what is
certainly known from what is merely defaulted.

- Thread browser_tz through the fbs envelope (+ Go/TS codegen), the gateway
  transcode + backend client, and the backend feedback service/store; add the
  column via migration 00004 (additive, image-rollback-safe).
- Fix fmtTimeIn to resolve "±HH:MM" offsets via account.ResolveZone;
  time.LoadLocation alone silently fell back to UTC for offset zones, which is
  the second reason a "+02:00" sender showed only UTC.
- Update ARCHITECTURE/FUNCTIONAL(+ru) docs and the feedback integration test.

Merge pull request 'feat(feedback): capture app version + browser zone; Filed time in three zones' (#115) from feature/feedback-version into development 170a6ae9ef

developer dismissed owner's review 2026-06-22 17:07:23 +00:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

developer added 2 commits 2026-06-22 17:07:54 +00:00

feat(account): seed the time zone from the client's detected offset at creation ... ef2c2d1eb9

A new account's time_zone defaulted to 'UTC' until the player saved a profile, so the
robot's sleep window and the turn-timeout away-window sweeper — both anchored to the
account zone via account.ResolveZone — ran on UTC for every fresh player, skewing
robot-game timing until a manual Settings save. Seed the zone at creation instead, from
the client's detected "±HH:MM" offset.

- Carry browser_tz on the three account-creating auth requests (TelegramLoginRequest,
  GuestLoginRequest, EmailRequestRequest — the email account is provisioned at the
  code-request step, not at login) through the fbs envelope (+ Go/TS codegen), the
  gateway transcode + backend client, and the backend auth handlers into
  ProvisionTelegram / ProvisionGuest / ProvisionEmail.
- create() now writes time_zone explicitly: the validated detected offset, or 'UTC'
  (equal to the column default) when absent or malformed — deterministic, never guessed.
  The column is already NOT NULL DEFAULT 'UTC', so no migration is needed and existing
  accounts keep 'UTC'. An existing account is never overwritten on re-login.
- A detected zero offset is stored as "+00:00" (the zone is known and equals UTC),
  distinct from the "UTC" default that means "unknown" — which the feedback console's
  three-zone Filed display already reflects.
- Guard the guest handler against an empty payload (the bootstrap historically carried
  none) so it degrades to no-seed rather than panicking in GetRootAs*.
- Tests: zone seeding across Telegram/guest/email plus the "+00:00"/malformed/empty
  cases and the not-overwrite rule; codec round-trip for the three auth encoders.
  ARCHITECTURE + FUNCTIONAL(+ru) updated.

Merge pull request 'feat(account): seed the time zone from the client's detected offset at creation' (#116) from feature/account-seed-timezone into development d5369a0188

developer added 2 commits 2026-06-22 18:16:54 +00:00

feat(telegram): localized /start welcome with channel & chat follow links ... 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.

Merge pull request 'feat(telegram): localized /start welcome with channel & chat follow links' (#117) from feature/bot-welcome-localized into development 1f78bb274b

developer added 2 commits 2026-06-22 18:17:04 +00:00

fix(i18n): reconcile preferred_language to the interface locale on every adopt ... 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.

Merge pull request 'fix(i18n): banner/push follow the interface language even without a Settings change' (#118) from feature/banner-language-followup into development 9d1ca213d6

owner approved these changes 2026-06-22 18:26:15 +00:00

developer merged commit 384bd143d0 into master 2026-06-22 18:28:01 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

owner

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

owner (Ilia) developer

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: developer/scrabble-game#114