developer/scrabble-game
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Stage 15: dual Telegram bots & language-gated variants #16

Merged
developer merged 2 commits from feature/stage-15-language-service-split into master 2026-06-05 07:40:53 +00:00
Conversation 1 Commits 2 Files Changed 45
+1015 -272
developer commented 2026-06-05 07:36:19 +00:00
Owner
Copy Link
Copy Source

Service-agnostic refinement of the owner's idea: the sign-in service returns a set of supported game languages with the user identity, and the lobby gates the New Game variant choice by it (en → English; ru → Russian + Эрудит).

  • Connector: two bots in one container (one per service language, each own token + game channel; the same telegram_id spans both). ValidateInitData tries each token and returns the validating bot's service_language + supported_languages. Per-language config (TELEGRAM_BOT_TOKEN_EN/_RU, channels).
  • Gating (UI + session, creation-only): supported_languages rides the Session (fbs, session-scoped, not persisted); New Game offers only the matching variants — only starting a game (auto-match + friend invite) is gated, not accept/open/play; the backend does not enforce.
  • Push routing (per-account): accounts.service_language (migration 00010, written every login, last-login-wins) routes the user-facing Notify push back through the right bot (/internal/push-target coalesces with preferred_language).
  • Admin: SendToUser/SendToGameChannel gain an operator-chosen language selector in the console — unrelated to ValidateInitData.
  • Non-Telegram logins carry the gateway default set (GATEWAY_DEFAULT_SUPPORTED_LANGUAGES, all variants).

Wire (committed regen): ValidateInitDataResponse +service_language +supported_languages; Session +supported_languages; SendToUser/SendToGameChannel +language. Docs (ARCHITECTURE / FUNCTIONAL / _ru / READMEs) + PLAN updated; stage marked done. Tests: connector multi-bot routing, gateway transcode (service_language + supported_languages + guest default), backend service_language round-trip (integration), UI availableVariants unit + codec round-trip; gating confirmed live in the mock UI.

Service-agnostic refinement of the owner's idea: the sign-in service returns a **set of supported game languages** with the user identity, and the lobby gates the New Game variant choice by it (en → English; ru → Russian + Эрудит). - **Connector**: two bots in one container (one per service language, each own token + game channel; the same telegram_id spans both). `ValidateInitData` tries each token and returns the validating bot's `service_language` + `supported_languages`. Per-language config (`TELEGRAM_BOT_TOKEN_EN/_RU`, channels). - **Gating (UI + session, creation-only)**: `supported_languages` rides the `Session` (fbs, session-scoped, not persisted); New Game offers only the matching variants — only **starting** a game (auto-match + friend invite) is gated, not accept/open/play; the backend does not enforce. - **Push routing (per-account)**: `accounts.service_language` (migration `00010`, written every login, last-login-wins) routes the user-facing `Notify` push back through the right bot (`/internal/push-target` coalesces with `preferred_language`). - **Admin**: `SendToUser`/`SendToGameChannel` gain an operator-chosen language selector in the console — unrelated to `ValidateInitData`. - **Non-Telegram** logins carry the gateway default set (`GATEWAY_DEFAULT_SUPPORTED_LANGUAGES`, all variants). Wire (committed regen): `ValidateInitDataResponse` +`service_language` +`supported_languages`; `Session` +`supported_languages`; `SendToUser`/`SendToGameChannel` +`language`. Docs (ARCHITECTURE / FUNCTIONAL / _ru / READMEs) + PLAN updated; stage marked done. Tests: connector multi-bot routing, gateway transcode (service_language + supported_languages + guest default), backend `service_language` round-trip (integration), UI `availableVariants` unit + codec round-trip; gating confirmed live in the mock UI.
developer added 2 commits 2026-06-05 07:36:19 +00:00
refine plan stage order 23b5c3b5cc
Stage 15: dual Telegram bots & language-gated variants
Tests · Go / test (push) Successful in 9s
Details
Tests · Integration / integration (push) Successful in 10s
Details
Tests · UI / test (push) Successful in 20s
Details
Tests · Go / test (pull_request) Successful in 8s
Details
Tests · Integration / integration (pull_request) Successful in 11s
Details
Tests · UI / test (pull_request) Successful in 19s
Details
e9f836db87 
Service-agnostic refinement of the owner's idea: the sign-in service returns a
set of supported game languages with the user identity, and the lobby gates the
New Game variant choice by it (en -> English; ru -> Russian + Эрудит).

- Connector hosts two bots in one container (one per service language, each its
  own token + game channel; the same telegram_id spans both). ValidateInitData
  tries each token and returns the validating bot's service_language +
  supported_languages. Per-language config (TELEGRAM_BOT_TOKEN_EN/_RU, channels).
- supported_languages rides the Session (fbs, session-scoped, not persisted); the
  UI offers only the matching variants on New Game — gating only the START of a
  new game (auto-match + friend invite), not accept/open/play; backend does not
  enforce.
- service_language persisted (accounts.service_language, migration 00010, written
  every login, last-login-wins) and routes the user-facing Notify push back
  through the right bot (push-target coalesces with preferred_language).
- Admin SendToUser/SendToGameChannel gain an operator-chosen language selector in
  the console (unrelated to ValidateInitData).
- Non-Telegram logins carry the gateway default set
  (GATEWAY_DEFAULT_SUPPORTED_LANGUAGES, all variants).

Wire (committed regen): ValidateInitDataResponse +service_language
+supported_languages; Session +supported_languages; SendToUser/SendToGameChannel
+language. Docs (ARCHITECTURE/FUNCTIONAL/_ru/READMEs) + PLAN updated; stage marked done.
owner approved these changes 2026-06-05 07:38:50 +00:00
developer merged commit 8c8f8c4d42 into master 2026-06-05 07:40:53 +00:00
developer deleted branch feature/stage-15-language-service-split 2026-06-05 07:40:53 +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
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: developer/scrabble-game#16
Delete Branch "feature/stage-15-language-service-split"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?