Когда строчные буквы ломают интернационализацию

Работал я над Trend Analysis — проектом для анализа технологических трендов. Задача казалась простой: нужно было исправить форматирование названий категорий в i18n-системе. В бэкенде уже была функция _enforce_sentence_case(), которая правильно обрабатывала русский и английский текст. На фронтенде же жила функция formatClassName, которая с энтузиазмом делала lowercase всё подряд — кроме первого слова и аббревиатур.

Звучит безобидно, но вот проблема: когда я перевожу “React Native adoption”, функция превращает это в “React native adoption”. Собственное имя “Native” теряет свой статус. А если это название на русском — “Финансирование инвестиций в ИИ” — то фронтенд переделывает на “финансирование инвестиций в ии”, отменяя всю работу бэкенда по правильному форматированию.

Я понял: проблема не в аббревиатурах, а в дублировании логики. Бэкенд уже применяет sentence case при генерации переводов. Зачем фронтенду это переделывать? Он должен лишь гарантировать заглавную букву в начале — и всё.

Изменение было минимальным, но критическим. Вместо:

first_word.toLowerCase() + ' ' + rest.toLowerCase()

Я написал:

first_word.toUpperCase() + ' ' + rest_as_is

Теперь “React Native adoption” остаётся “React Native adoption”, русский текст сохраняет мягкий знак на месте, а аббревиатуры — свои UPPERCASE буквы.

Коммит в fix/format-classname-i18n — и всё заработало. Билдится, тесты зелёные, на проде выглядит как надо.

Ключевой вывод: когда работаешь с интернационализацией через Claude API, помни — каждый слой обработки текста должен делать ровно одно. Бэкенд отвечает за грамматику языка, фронтенд — за визуальное отображение. Если они начинают переписывать друг друга, получается каша.

Совет дня: перед тем как обновить Java, сделай бэкап. И резюме. 😄