Comments 15
Зачем там типизация, если я всёравно где-нибудь, да напишу t("page.helo"
Мне бы больше хотелось что-то типа t.page.hello / t.page.hello({name: 'world'})
Кстати, переводы это не только два килограмма перевод меток, но и направление текста, так ещё и вёрстку под конкртеный язык может понадобиться менять
Типизацию через точки я тоже хочу. Точнее даже накостылил её. Но ни одна относительно популярная библиотека её не даёт.
Поэтому промежуточный вариант - это типизация самих переводов (чтобы не потерять ни одно из полей). А если вы напишите t("page.helo") - у вас всё равно ни на одном языке не отобразиться перевод и вы это заметите.
Про направление текста и т.д. - в текущем проекте мы на это забили. Используем только языки, которые пишутся слева направо.
Единственная разница в вёрстке, что текст на русском или чуть длиннее, или +1 строка. Но т.к. размерности никто не хардкодит, всё спокойно адаптируется
t(page.hello) довольно легко можно накостылить, сгенерировав структуру с соответствующими значениями по каждому ключу. Плюсом я для себя подшаманил вывод типов, чтобы по hover-у вместо бесполезного string (который по факту находится по каждому ключу) писало текст перевода, правда, это возможно только если переводы лежат не в json-е, из него пока ts не может вывести строгий тип. У нас по историческим причинам оригиналы текстов лежат в ts-файле.
Официальная дока как раз через точку https://nextjs.org/docs/app/building-your-application/routing/internationalization
Спасибо, что делитесь информацией!
До сих пор не понимаю, почему такие статьи минусят
Спасибо :)
Я недавно смотрел подкаст с @Boomburum (один из руководителей хабра). Он говорит, что это норма, если узкоспециализированные статьи в первые часы собирают минусы. Потом рейтинг выравнивается
Это из-за того, что на хабре много токсичных товарищей, который минусуют вообще всё подряд без учета тематики. А потом подтягивается 5%-10% аудитории, которой статья в тему — и возвращают рейтинг в плюс.
Потому что нагородил всякого хлама.
Задаёшь дефолтный язык, ру например, чтобы не плодить кучу файлов, деофлтнвй текст можно задать так же через , в самом блоке текста {t{kod, "text}}, далее парсим в файлик тексты со всего проекта, к примеру сканером или парсером. Появляется исходный файлов со всеми текстами со всего проекта. Дальше осталось только конфигурации настроить самих переводов, например через гул апи. Он проходит по исходном файлику ru.json, переводит на заданные языки и создаёт сам en.json и тд, какие там. Все осталось уважать смену языков с файлами переводов
А тут какая то шняга кривая ещё и вручную
Итого, вы предложили:
Взять нестандартный подход, без документации, покрытия тестами и незнакомый для новых программистов.
Зачем-то потратить время на написание парсера (и его тестирование).
Перевести ~2500 строк текста (в моём случае) через API, который не будет учитывать контекст фраз, местоимения и терминологию проекта.
Про проблемы, которые появятся с ростом переводов до 20к строк+, разделением кода и серверным рендерингом я молчу.
Резюмируя, "создаём велосипед руками и головняк на будущее". Если проект на 1-2 человека и это привычно - тогда ок. Но для проекта больше - это лишнее.
В статье как раз описан подход, где берётся стандартное протестированное решение, знакомое программистам на рынке. Без велосипедостроения и отлавливания багов за счёт бюджета проекта.
Вполне стандартный подход, если ты его не видел не значит что он нестандартный
Партнёры давно уже впитывает в реакт , читайте пункт 1
Ну ка расскажи мне способ идеального автоматизированной перевода со всеми эти фичами, чтобы не страдал контекст? 20к строк? В моем примере указан автоматизированный перевод, уж какой есть в апи, хочешь ручками - пожалуйста, твоё право, суть подхода не меняется, вместо созданного через апи файл втыкаю свой, какие проблемы
Причём тут разделение кода, и северный рендеринг?)))) Речь про создание системы для переводов
Дружище,ты читай разные источники, а не делай вывод и суждение по первому попавшимуся, который сразу у тебя в голове становиться эталонным
Минусят потому-что типизация словаря - это бред полнейший. Извините если что, я "олдовый разработчик".
Не выбирайте i18-next для новых проектов, пожалуйста, это самое отсталое решение.
Пожалуйста, обоснуйте свой комментарий и подскажите более ценные, на ваш взгляд, альтернативы
Ключи для локализации
Использование ключей вместо inline-сообщений сильно ухудшает DX. Разработка и сопровождение приложения с тысячами ключей становится кошмаром.
Поддержка ICU Message Format
Реализация ICU в i18next сложная и громоздкая. Добавление сообщений с этим форматом через ключи превращается в непрозрачный процесс. Библиотеки, такие как Lingui.js, предоставляют из коробки удобный API для работы с ICU.
Lazy loading в i18next
Lazy loading переводов в i18next через namespaces, но это решение крайне ограниченное. Если на странице внезапно потребуется другой namespace, он не будет загружен автоматически.
Lingui.js как альтернатива
• Lingui.js позволяет автоматическую экстракцию сообщений из компонентов, что устраняет необходимость ручного управления ключами.
• Если нужно - сообщения попадают в lazy-словари на основе вложенности компонентов
• API значительно проще: каррированные функции или компонент `` c натуральными сообщениями вместо громоздких ключей.
• Генерация переводов в формате gettext и ICU Message Format, что упрощает интеграцию с любыми системами управления для переводами.
Организация ключей
Придумывать и поддерживать ключи — это когнитивная нагрузка, которой легко избежать. Беспокоитесь о коллизиях текстов - контекст (context) решает эту проблему.
Зачем вам типизация словаря локализации? Как у вас мысль об этом появилась? Что это дает вашей компании(какой профит)?
Локализуем React (NextJS, TypeScript) сайт на несколько языков с помощью i18next