Система сопоставления локализации Android очень удобна. Вы можете определить строки по умолчанию в каталоге с именем values, а все переведенные строки можно переместить в папку с именем values-[LANG_ISO_CODE]. Например, переводы для Германии войдут в values-de, а переводы для Испании войдут в values-es.
Для простоты в этом блоге я не упомянул тот факт, что этот «ISO-CODE» не обязательно должен включать только язык, но также может включать страну. Например, в Швейцарии несколько языков. Для поддержки разных языков вы можете использовать ISO-КОДЫ
de_CH,fr_CH,it_CH.
Android автоматически загрузит и отобразит правильные строки (из правильного каталога ресурсов) в зависимости от языковых настроек вашего телефона. Начиная с Android 13 вы даже можете установить язык для конкретного приложения. Но это уже другая история 😉.
Однако, если язык телефона установлен на язык, который не поддерживается приложением, Android загрузит строки из каталога по умолчанию (values).
До сих пор во всех проектах, над которыми я работал, каталог по умолчанию содержал «английские» переводы.
Но это может быть проблемой, верно?
Нет, не потому, что мы используем английский как запасной вариант, что на самом деле желательно, поскольку английский является «глобальным языком», а по другой причине.
Мы, разработчики Android, помещаем строки, которые мы видим в наших макетах или проектах пользовательского интерфейса (от нашей команды пользовательского интерфейса), в каталог по умолчанию (values). Но так как обе команды не являются носителями английского языка (и не пишут), мы можем использовать неправильные слова, фразы или делать грамматические ошибки.
Теперь, если пользователь использует наше приложение на языке, который мы изначально не поддерживаем, он увидит язык по умолчанию. Включая все ошибки, которые могут быть в нем.
Для нас в ioki это неприемлемо. Однажды мы определили, что хотим поставлять высококачественное программное обеспечение. Сюда входят переводы по умолчанию, которые использовались в телефонах, использующих язык, который мы еще не полностью поддерживаем.
Как решить эту проблему?
Мы все ошибаемся, это точно. Даже если бы английский был нашим родным языком, ошибки (баги) случаются. В конце концов, они будут найдены кем-то, исправлены (в каталоге values по умолчанию) и отправлены в следующем выпуске. Так в чем проблема?, я слышу твой крик.
Проблема с этим подходом в том, что мы (разработчики Android) не хотим поддерживать эти переводы. Как и любой разработчик, мы хотим решать проблемы. Замена неправильной строки в нашей кодовой базе — это определенно не та работа, которую мы хотим делать. Особенно когда мы не можем проверить, действительно ли он «исправляет» неправильные переводы. Поскольку мы не являемся носителями английского языка, мы не можем сказать, является ли новая формулировка более правильной или более точной.
Поэтому нам нужно другое решение для этого. Решение, которое не «беспокоит» нас, разработчиков, при обнаружении ошибки в одном из поддерживаемых нами языков.
Что, если бы мы изначально поддерживали английский язык и во время выпуска скопировали эти английские переводы в release sourceSet…
Решит ли это нашу проблему? Да, было бы! 🎉
Подробнее, пожалуйста!
Представьте, что мы изначально поддерживаем немецкий, испанский и английский языки, и у нас будет следующая структура в нашем приложении для Android:
- main/**/values/ - main/**/values-de/ - main/**/values-es/ - main/**/values-en/
Если мы вводим язык, ориентированный на разработчиков, и создаем тип выпуска, мы копируем каталог values-en, содержащий хорошо переведенные английские строки, в каталог release sourceSet. Закончите со следующей структурой перед упаковкой APK (или Bundle):
- main/**/values/ - main/**/values-de/ - main/**/values-es/ - main/**/values-en/ - release/**/values/
Поскольку инструмент сборки Android всегда будет выбирать наиболее конкретный запрошенный sourceSet, он выберет release/**/values в качестве каталога по умолчанию и пропустит каталог main/**/values (при условии, что те же ресурсы ids доступны в release/**/values).
Вот и все. Теперь у нас есть хорошо переведенные английские строки в качестве резервного языка. Язык для разработчиков в main/**/values никогда не будет виден пользователям нашего приложения.
Проблемы и проблемы с этим решением
Это решение не решает проблему, когда разработчиков ругают за неправильный английский перевод, не так ли?
Если вы используете один из доступных инструментов локализации, вам больше не нужно исправлять переводы в коде. Например, вы можете использовать Phrase или Lokalise для удаления переводов из вашей кодовой базы. Любой член вашей (переводческой) команды может изменять переводы и исправлять ошибки. В процессе выпуска вы загружаете переводы из выбранного вами инструмента перевода и размещаете их в нужных каталогах (последнее выполняется автоматически большинством известных мне инструментов).
На практике это означает, что ваша кодовая база будет иметь только один каталог, содержащий ваш язык для разработчиков:
main/**/values
Но перед созданием версии приложения вы загружаете строки, чтобы получить структуру, которую я уже показал выше:
- main/**/values/ - main/**/values-de/ - main/**/values-es/ - main/**/values-en/ - release/**/values/
Ни один разработчик никогда не будет раздражен кем-то из-за ошибки перевода. Каждый в вашей компании может исправить ошибки с помощью соответствующего инструмента. Мы (разработчики Android) просто должны убедиться, что мы загружаем его во время выпуска. Готово ✅.
Как и все остальное, это решение имеет свои проблемы.
Одна из проблем заключается в том, что языковые ошибки, с которыми сталкиваются пользователи, скрыты от разработчиков. Например, известно, что в немецком языке слова длиннее, чем в других языках. При разработке вы можете забыть добавить некоторые ограничения представления и получить что-то вроде этого:
Другая проблема заключается в том, что ваши билд-релизы больше не воспроизводимы. Поскольку изменения в инструменте перевода могут произойти в любое время, и вы не проверяете их в системе контроля версий, может (вероятно) случиться так, что версия x.y.z вашего приложения сегодня имеет другие переводы, чем несколько недель назад.
Мы используем языковую практику, ориентированную на разработчиков, уже три года, и мы все очень довольны ею. Разработчикам не нужно беспокоиться об ошибках перевода, они просто сохраняют свой язык разработчика, в то время как владельцы продукта, члены команды пользовательского интерфейса и менеджеры продукта могут вносить изменения в перевод на лету, зная, что их изменения будут отправлены в следующем выпуске.
А как насчет вас и вашей команды? Вы когда-нибудь слышали или думали о таком решении? Вы делаете что-то подобное? Или переводы не являются проблемой в вашей организации? Дай знать, мне интересно. 🙂
