Руководство по переводу React-приложений для i18n (альтернативы i18next и React-Intl)

[artptr86]

Разрозненные переводы: разработчики работают с десятками JSON-файлов, разбросанных по проекту.

Обычно файлы локалей все лежат в одном месте. Или же разделены помодульно, если тому соответствует архитектура приложения. Здесь же вы предлагаете управлять, возможно, тысячами файлов с локалями, разбросанными по проекту.

Type safety: отсутствующие ключи или несоответствия в переводах обнаруживаются только во время выполнения.

i18next имеет встроенную проверку отсутствия ключей через типовыведение:

https://www.i18next.com/overview/typescript

https://github.com/i18next/react-i18next/tree/master/example/react-typescript/simple

Владение контентом: маркетологам и другим нетехническим специалистам сложно управлять переводами без участия разработчиков.

Нет. В случае обычных файлов локалей достаточно только умения пользоваться Git. Появление новых ключей перевода определяется простым сравнением ключей дефолтной локали с другими локалями. Это можно даже вынести, например, в пайплайн тестирования релиза. В вашем случае переводчикам нужно также понимать и архитектуру приложения, и знать TypeScript, чтобы понимать, что там нагородили разработчики. Кроме того, системы автоматизации переводов скорее всего поддерживают плоские JSON с ключами-значениями, а из *.content.ts все строки придётся доставать руками и править на месте — минус автоматизация.

Предположим, мы вводим в приложение новый язык. Переводчикам (часто нанятым отдельно из специализированного агентства) предлагается бегать по всему приложению для перевода? А если они где-то забудут добавить ключ, возникнет ошибка?

[aymericzip]

Для людей без технических навыков, например переводчиков или маркетологов, мы предлагаем CMS, чтобы им не приходилось работать с Git и прочими инструментами разработчиков.С помощью этой системы они могут легко понимать, над каким проектом работают, какие переводы отсутствуют или ещё должны быть сделаны.Также есть возможность автоматически сгенерировать перевод с помощью кнопки, использующей ИИ и учитывающей контекст, чтобы получать более качественные переводы для каждого словаря.Если используется ключ, который должен быть общим, можно создать общий словарь и вызывать этот ключ именно из него.

[artptr86]

То есть вы реализуете банальный вендор-лок. Причём я сомневаюсь, что ваша CMS мощнее и удобнее, чем профессиональные CAT-системы (Computer-Aided Translation), используемые переводчиками. Даже если они возьмутся за такую работу, то, скорее всего, запросят значительно больше денег.

[artptr86]

AI в CAT-системах тоже прикручен: https://support.crowdin.com/for-translators/#ai-assistant

[artptr86]

Так мы ответа дождёмся или только в карму минусы ставить умеете?

[aymericzip]

Твой комментарий вполне уместен. И действительно, если интеграция решения для i18n с Crowdin является для тебя критерием выбора, то думаю, Intlayer не самое подходящее решение.

Целевая аудитория Intlayer, это в основном личные проекты или небольшие проекты / SaaS. Смысл в том, чтобы ускорить разработку, и для таких случаев добавление отдельной платформы локализации часто считается избыточными расходами. Для банков или крупных компаний лучше оставаться на классических решениях.

Но я отметил, что для тебя критичен Crowdin. Я добавил в дорожную карту задачу, предложить такую интеграцию в виде плагина

[xxrat]

[ вопрос уже задали выше ]