Comments 9
С ИИ нужно поаккуратнее. Я использовал Claude Sonnet 3.7 и 3.5 для переводов интерфейса с английского на испанский. Я думал, что всё ок, пока QA не нашла мне там кучу ошибок. Причём большинство ошибок — несогласованность родов существительных и прилагательных. Иногда даже по три ошибки в одном предложении. Буду пробовать для переводов GPT4.1, но с кодом он очень слабо работает по сравнению с Claude. Придётся постоянно переключаться.
Тот же опыт с OpenAI o3 c французким и немецким.
В l10n.dev качество лучше, чем просто копировать текст в Claude или GPT — потому что процесс настроен именно под JSON i18n-файлы с учетом всех правил локализации и i18n о которых я пишу в этой статье, а не под «разовый перевод в чате». При переводе с помощью ИИ необходимо учитывать поддержку тех или иных языков моделью, качество переводов мы контролируем. "Думающие" модели по результатам экспериментов показали что, в случаях когда необходимо строже следовать инструкциям, они дают хуже результат.
Извинюсь за уточнение: если напрямую загрузить в Claude или GPT файл больше ~16 000 символов, модель начнёт подстраивать содержимое под ограничение контекстного окна — сокращать, объединять или упускать детали. В результате часть контекста теряется, и перевод может оказаться менее точным.
В моём сервисе это решается разбиением и обработкой текста с сохранением связей между сегментами и контекстом, поэтому качество перевода не страдает даже при больших объёмах.
Интересно, пользуется ли кто-то описанными в статье возможностями i18next типа контекста или несколькими формами множественного числа? На сколько реально это правильно перевести на 20-30 языков включая иероглифы. Или может проще и дешевле перефразировать "{{count}} день" в "Дней: {{count}}" ?
Используйте точки в нотации, чтобы отражать структуру приложения (
form.login.button) и не создавать длинные, плоские JSON-файлы.
Что делать если вёрстка поменялась, и соответственно последовательность\вложенность компонентов тоже поменялись? Т.е. "путь" ключа через точку уже не соответствует реальной вложенности?
Что делать со старымим ключами - если компонент\страница уже не нужны и их сносят полностью? Кто и в какой момент времени должен подчистить ключи?
Тоже плохо:
"msg_001": "Это поле обязательно"Как раз самый нормальный вариант. "Плоское лучше вложенного" (из пайтон заповедей), плюс чёткий айдишник не привязанный к вложенности ui. С помощью глобального поиска и замены - решаются все проблемы. И нет соблазна писать динамические ключи в коде, типа "page.component.some-other-component.${some-state}" - который по поиску уже не найдёшь (ни в исходном коде, ни в джейсонине)
Json может быть плоским если так удобно (flattened json), при этом ключи все ещё могут быть информативными. Если вы переверстали можете не менять ключи если лень или если перевод уже утвержден или есть какая-то внешняя система для работы с переводами и необходимо сохранить согласованность. При этом информативный ключ даёт переводчикам немного больше контекста о том где должна быть строка, другого контекста у него может не быть, особенно если это аутсорс переводчик. ИИ анализирует весь файл он контекст поймет по тексту в целом, даже если у вас ключ это какой-то id. По поводу поиска не понял, никаких сложностей не вижу особенно применяя regex, а вот как искать и помнить что строка msg1 это заголовок а msg2 это кнопка не представляю возможным.
а вот как искать и помнить что строка msg1 это заголовок а msg2 это кнопка не представляю возможным.
А зачем это помнить, и знать впринципе? Это абстрактные айдишки, которые ничего не должны знать про интерфейс.
При этом информативный ключ даёт переводчикам немного больше контекста о том где должна быть строка, другого контекста у него может не быть, особенно если это аутсорс переводчик.
Ну это другого рода проблема. Хороший контекст - это макет. А лучший контекст - это полное прохождение и понимание пользовательского сценария со стороны переводчика.
По поводу поиска не понял, никаких сложностей не вижу
Самому, или инструментом, или аи-шкой - натравить на исходный код и переводы с такой задачей "Посмотри все айдишки msg1, msg2, msg3, msg_n в исходниках, если не найдёшь - удали из джейсонин. Повторять раз в неделю." Проблема в том, что если ключи составные через точку, то часто они собираются в коде динамически. И даже если их найти через регекспы - фиг поймёшь юзается такой ключ или нет.. нужно разбираться в коде и прикидывать все возможные варианты ключа.
Их можно не удалять, если решить что с ними делать не удается, это повлияет только на размер файла
Если это не проблема - то можно тогда забить, да.)
Что делать со старымим ключами - если компонент\страница уже не нужны и их сносят полностью? Кто и в какой момент времени должен подчистить ключи?
Их можно не удалять, если решить что с ними делать не удается, это повлияет только на размер файла, на UI не повлияет.
i18n и l10n: Почему разработчикам стоит об этом знать — и как может помочь ИИ