Lingo.dev CLI переводит нативные мобильные файлы ресурсов — Xcode .strings, Android XML, Flutter ARB и React Native JSON — через настроенный движок локализации. CLI сам определяет формат каждого файла по расширению, сохраняет структуру и корректно обрабатывает формы множественного числа.
Обзор платформ#
| Платформа | Нативный формат | Типичный путь к исходному файлу |
|---|---|---|
| iOS (Xcode) | .strings | en.lproj/Localizable.strings |
| iOS (Xcode) | .stringsdict | en.lproj/Localizable.stringsdict |
| iOS (Xcode) | .xcstrings | Localizable.xcstrings |
| Android | strings.xml | app/src/main/res/values/strings.xml |
| Flutter | .arb | lib/l10n/app_en.arb |
| React Native | .json | src/locales/en.json |
Что понадобится#
При каждом запуске CLI контент проходит через движок локализации — именно он определяет, какую модель LLM, глоссарий, тональность бренда и правила использовать. Создайте его в панели управления Lingo.dev.
Установите CLI (Node.js 22+) и войдите в систему:
npm install -g @lingo.dev/cli
lingo loginlingo login выполняет вход с помощью одноразового кода. Для CI пропустите интерактивный вход — передайте --api-key или задайте LINGO_API_KEY.
Настройка платформы#
Запустите lingo init, чтобы создать .lingo/config.json (исходная и целевая локали плюс шаблоны файлов), затем lingo link, чтобы подключить orgId и engineId. Зафиксируйте .lingo/config.json в репозитории. Примеры ниже — итоговая конфигурация для каждой платформы.
Шаблон всегда указывает на исходный файл, а CLI сам выводит путь к каждому целевому. Обычно это означает замену локали в пути (en.lproj → de.lproj, app_en.arb → app_de.arb). Две платформы устроены иначе — CLI справляется с обеими автоматически: String Catalog хранит все локали в одном файле, поэтому целевой путь совпадает с исходным; Android хранит строки по умолчанию в неквалифицированной директории values/ без локали в пути, поэтому CLI добавляет к ней квалификатор целевой локали (values/ → values-de/).
Xcode поддерживает три формата локализации. Выберите тот, который соответствует конфигурации вашего проекта.
String Catalogs (.xcstrings) — современный формат Xcode, появившийся в Xcode 15. Один JSON-файл содержит все локали, и Xcode обновляет его автоматически при добавлении новых строк. CLI изменяет этот файл напрямую, поэтому шаблон указывает на единственный каталог без сегмента локали.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}Устаревшие файлы .strings — по одному файлу на локаль в директориях [code].lproj/. Исходная локаль указана в пути (en.lproj), а CLI записывает каждую целевую локаль в отдельную директорию .lproj. Если в проекте также используются .stringsdict для форм множественного числа, добавьте второй элемент files.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [
{ "pattern": "MyApp/en.lproj/Localizable.strings" },
{ "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
]
}Проект, в котором языковой бандл разработки — Base.lproj, а не en.lproj, тоже работает: CLI распознаёт Base.lproj как исходную локаль.
Подробности о настройке i18n-инфраструктуры в Xcode — в документации Apple по локализации.
Запуск перевода#
Переведите все ресурсные файлы одной командой:
lingo pushCLI считывает файлы исходной локали, определяет изменения с момента последнего запуска с помощью lockfile (.lingo/lock.json, который вы фиксируете в репозитории), переводит только то, что изменилось, и записывает результаты в файлы целевых локалей.
При первом запуске — или когда вы добавляете новую целевую локаль — переведите всё с нуля:
lingo push --backfill-missingЕсли проект содержит несколько типов ресурсов и нужно выбрать конкретную платформу, передайте glob (флагов --bucket и --target-locale не существует). Шаблоны сопоставляются с исходными путями, поэтому фильтруйте по исходному файлу, а не по целевому:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Чтобы получить актуальные переводы на другой машине, запустите lingo pull. Чтобы проверить актуальность переводов без записи изменений — например, в качестве условия деплоя — запустите lingo check.
Множественное число и особенности платформ#
Каждая мобильная платформа по-своему работает с формами множественного числа: iOS использует .stringsdict или правила String Catalog, Android — XML-элементы <plurals>, а Flutter — ICU MessageFormat в ARB-файлах. CLI сохраняет нативную структуру множественного числа для каждой платформы при переводе и генерирует корректные категории для каждой целевой локали.
Примечания для переводчиков
Строки в мобильных приложениях часто короткие и сильно зависят от контекста. Используйте примечания для переводчиков в файлах Xcode .xcstrings, чтобы дать движку локализации больше контекста о том, где используется строка: «подпись кнопки в процессе оформления заказа» переводится иначе, чем «пункт меню навигации».
Автоматизация в CI#
Самый удобный способ поддерживать переводы в актуальном состоянии — Lingo.dev GitHub App. Он работает на стороне сервера, читает зафиксированные .lingo/config.json и engineId и автоматически создаёт PR с обновлениями переводов — без раннера, секретов и управления lockfile с вашей стороны. Если вы предпочитаете запускать переводы в собственном пайплайне, выполните lingo push в CI-раннере и зафиксируйте результаты.
