В англомовній версії нещодавно випущеного аналізатора Cache-Control відображався японський текст — замість «Fresh» статус був «新鮮». Помилка виявилася наслідком спільної логіки, яка повертала жорстко закодовані японські рядки, хоча сама сторінка надавала лише англійські мітки.

Розробник створює серію легких інструментів для браузера, кожен з яких має англійську та японську версії сторінок, що використовують однакові функції парсингу та основну логіку. Різнитися має лише видимий текст. Коли аналізатор Cache-Control був випущений, англомовний інтерфейс відображав правильні мітки, але значення, які він виводив, надходили з рівня логіки, де все ще були японські літерали. Помилок у консолі не було; сторінка виглядала нормально, проте інформація, що надавалася англомовним користувачам, була неправильною.

Чому спільна логіка може підвести переклад

Баг виник через архітектурне рішення: основна функція, яка визначає, що саме показувати, повертала рядки безпосередньо японською мовою. Рівень сторінки, відповідальний за оточення англійською мовою, не мав можливості замінити ці значення. Оскільки логіка та інтерфейс були чітко розділені, проблема залишалася непомітною під час тестування — технічно все «працювало», хоча мова, з якою взаємодіяв користувач, була неправильною.

Недоліком є те, що мова, використана всередині спільного модуля, стає мовою за замовчуванням для кожного фронтенду, який його використовує. Якщо потрібна інша мова, ця мова за замовчуванням перетворюється на приховану помилку.

Виправлення: ключі, пакети та страховка

Автор переписав архітектуру, щоб розділити зони відповідальності:

  • Пакети повідомлень (Message packs) тепер містять усі зрозумілі для людини рядки для кожної мови.
  • Спільна логіка повертає лише символьні ключі, а не сирий текст.
  • Сторінки шукають відповідне слово у відповідному пакеті на основі ключа.

Якщо повідомлення має містити число, новий код використовує невелику функцію замість шаблонного рядка. Це дозволяє кожній мові самостійно визначати місце числа, враховуючи відмінності в порядку слів.

Також було додано простий крок статичного аналізу: процес збірки сканує спільні файли на наявність японських символів. Якщо вони з'являються, розробник негайно отримує сповіщення, що запобігає повторному потраплянню жорстко закодованого іноземного тексту.

Чого цей досвід навчив автора

  1. Переклад слугує етапом перевірки. Під час написання англійських повідомлень автор помітив, що деякі японські еквіваленти були розпливчастими. Переклад змусив зробити формулювання чіткішими обома мовами.
  2. Спільні функції, що повертають рядки, закріплюють мову для всіх. Якщо функція сама визначає мову, будь-який споживач, якому потрібна інша мова, успадковує цю помилку. Баг — це не збій інтерфейсу, а помилка логіки.

Рекомендації для тих, хто підтримує багатомовні інструменти

  • Повертайте ключі, а не рядки, з основних функцій. Дозвольте рівню інтерфейсу займатися локалізацією.
  • Або передавайте потрібні рядки у функцію як параметри. Це зробить логіку незалежною від мови.
  • Перевіряйте спільні модулі на наявність жорстко закодованого тексту рідною мовою. Швидкий пошук символів, що не входять до ASCII, допоможе виявити приховані проблеми.
  • Додайте перевірку іноземних символів у спільному коді під час збірки. Раннє виявлення краще за плутанину після релізу.

На що звернути увагу надалі

Висновок: Якщо у вашому проєкті спільний код використовується для різних мовних версій, переконайтеся, що спільна частина ніколи не визначає формулювання. Нехай кожна сторінка надає власні слова, і тоді ви уникнете конфузу з англійською сторінкою, яка випадково заговорила японською.