Two gaps in the earlier i18n scaffolding: the Mini App's UA/EN switcher
existed but most screens and all menu content stayed hardcoded Ukrainian.
Menu content (business data, not UI chrome):
- Category.name_en, Product.name_en/description_en (nullable, opt-in per
item — untranslated items fall back to Ukrainian rather than showing
blank). Editable from the existing category/product admin forms.
- Allergen labels (a small fixed EU-mandated set) get an English label
directly in ALLERGENS, no DB column needed.
- /api/categories and /api/products take an optional ?locale= param (no
session on these unauthenticated routes to read a stored preference from).
Full EN coverage for everything else:
- Every remaining webapp screen: MenuPage/ProductCard, CartItemRow (fixes a
pre-existing gap in the "already translated" cart screen), OrdersPage,
ContactsPage, ClosedScreen, BottomNav, AnnouncementPopup, plus app-level
status/error text.
- Every reachable bot message: /menu, /contacts (including its
locale-dependent reply-keyboard button, matched by text across all
locales since the label itself varies), and the rating thank-you flow.
- Every customer-facing checkout/order error message (empty cart, closed,
min order amount, payment/promo validation, cancel/pay errors) via
locale params threaded through workhours.closed_message() and
promo.validate_promo_code().
New: PATCH /api/me/locale persists an explicit in-app language choice back
to TelegramUser.locale (fire-and-forget from the webapp switcher), so it
also applies to the bot's own push notifications, not just the Mini App
session that made the choice.
Fixed a real bug caught while testing: product_form.html's allergen
checklist unpacked ALLERGENS values as 2-tuples, which broke (ValueError)
once they became 3-tuples (uk_label, emoji, en_label) — admin's "add
product" page 500'd until this was caught in browser testing.
byrsapty
ff232d1a0f