Локализация Android приложения средствами Google Sheets

Прочитал публикацию «Локализация Android приложения средствами Google Sheets» и удивился. Над проектом работает целая команда (переводчик, разработчик, автор), но одну из первоочередных задач — перевод продукта — решает неудобно.

Платные сервисы хороши всем, кроме того, что они платные. Перевод предполагает множество авторов по своей сути — и на роль удобного многопользовательского редактора одного документа сразу всплывает Google Doc.



Я разработчик маленького, но гордого приложения под Android. Как только в проект добавился 3-й язык (после английского и русского), я сразу перенес всю словарную базу в Google Таблицы. Сразу ощутил удобство сопоставления разноязычных строк — пришлось изрядно подкорректировать длины. Первые несколько раз я переносил переводы вручную в xml файлы ресурсов проекта. Потом плюнул и написал обычный парсер: из экспортированного TSV файла Google Sheet в набор файлов локализации, готовых сразу быть добавленными в проект.

Почему Delphi? — мне так было удобнее, не так давно ковырял старую программу по переформатированию хитрых файлов и для линейного разбора текстового файла в другой. Никаких лишних файлов в проекте.
Почему TSV? — csv не подходит из-за коллизий, если строки содержат запятые… а дальше не искал.



Так как я одновременно веду разработку двух проектов, и второй проект представляет собой более функциональную версию, мне показалось удобным иметь общую словарную базу для них. Разделение ресурсов через маркеры — первый столбец в таблице.

В разборе нет ничего хитрого. Я экспортирую файл в таблицу, разделенную табуляцией, и в парсере привожу к столбцам данных. Первый, как я уже упоминал, служебный и имеет метки, как обрабатывать строку:
  • 0 — никак, служебная информация;
  • 1 — код языка, на замену звездочкам в values_**;
  • 2 — код языка родителя, с которого берутся недостающие переводы, если он указан; например для белорусского и украинского это русский язык.
  • 3 — общая строка для базового проекта;
  • 4 — уникальная строка для базового проекта;
  • 5 — уникальная строка для проекта-наследника, перезаписывающая строку с таким же ключом базового проекта;
  • 6 — общая строка для проекта-наследника;
  • 7 — уникальная строка для проекта-наследника;


Общая строка для базового проекта — универсальная для всех локализаций, хранится в общей папке values/ в string_common.xml
Уникальная строка — уникальная для языка, укладывается в свою локализованную папку values_**/strings.xml

В комментариях к оппонирующей статье видел вопрос по подготовке ресурсов для разных платформ. С отдельным инструментом для приведения Google Таблиц к файлам ресурсов это не проблема, а так, задача на свободный вечер.

Я веду разработку в Eclipse в Windows и мне удобно просто заменить файлы локализации. Весь контекст перевода легко прослеживается по соседним переводам и первым столбцам — комментариям. Весь перевод, а его более 1000! строк выполняется добровольцами, благодарными пользователями. Каждый релиз программы с обновленным переводом, какой бы он не был. При вопросах и предложениях о помощи с переводом я просто даю ссылку на таблицу.

P.S. Проект, как обещал, причесал и выложил на GitHub.

Средняя зарплата в IT

110 450 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 7 043 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 8

    0
    Вы не боитесь, что результат, когда значения для не переведённых строк берутся из «родительского» языка, будет восприниматься как некачественный перевод? Пользователь не знает, что у вас произошла сознательная подмена, и может подумать, что ваш переводчик недостаточно хорош и/или не разобрался. Да и на практике в приложении будут получаться «трасянка» и «суржик». Сама идея с «родительским» языком неплоха, но мне кажется, пользователи должны иметь опцию, чтобы включать/выключать использование «родительского» языка для отсутствующих строк.
      +1
      Я заметил, что кривой перевод, чем отсутствие любого, приносит больше пользы, чем вреда. На первых этапах часто находятся добровольцы с предложением помощи и все приводят в норму.

      Конкретно в моих проектах я использовал описанную возможность для клонирования русского перевода для белорусской локализации. Обоснованно предположил, что лучше на русском, нежели на английском.

      При 7к+ установок из Беларуси жалобы на перевод ни одной. Для Украины и 25к+ установок 3 человека предложили свою помощь для совершенствования изначального моего кривого перевода (строк было поменьше, до ста). Бразильцы, несмотря на скопированную португальскую локализацию и при 9к+ установок продолжают пользоваться… и благодарить.
      0
      Проще написать скрипт прямо для гугл-дока. У нас так сделано — скачивается файл XML сразу. В остальном похоже сделано, только телодвижений меньше, а результат такой же.
        0
        Согласен отчасти. Когда делал первый вариант — просто пошел по пути меньшего сопротивления. Когда проект начал разрастаться были мысли все в облако, но решил не трогать, пока нет необходимости в изменениях. А сейчас, после блокировки в Крыму всех Гугло-сервисов, уже боязно неожиданно остаться без необходимого инструмента в нужное время.
        +1
        Какая разница — вы в любом случае после блокировки останетесь с последней версией.

        Вот про не трогать пока нет необходимости — это весткий аргумент.
          0
          Скажите, а не боитесь, что Вася возьмёт и всё сотрёт или напишет в переводе какой-то матер?
            0
            Отвечу за автора, так как сейчас сам активно использую Google Sheets для локализации.
            Если Вася все сотрет всегда можно будет откатиться до нормального состояния, так как таблицы помнят все свои изменения. С «матером» вопрос решается еще проще, даванием по шее тому кто этот «матер» написал. Как я уже говорил ранее таблица помнит все изменения и при должном желании виновного найти не проблема.

            Вдогонку добавлю. В таблицах можно указать кто к каким колонкам имеет доступ. Поэтому, если колонки с идентификаторами заблокировать для всех кроме разработчиков, можно не бояться что переводчик что-то удалит. И вообще переводчикам стоит давать доступ только к тем языкам с которыми они работают.
              0
              Упустил вопрос и своевременный ответ, с которым полностью согласен

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

              Такой подход до сих пор для меня актуален (спустя полтора года публикации и 2.5 года использования).
              Единственный момент — использование некоторых ресурсов в более чем 1/2 приложениях — возможно попробую использовать различные страницы.

              Кстати идея для стартапа — глобальный ресурс сопоставления самых популярных фраз для списка языков. Просто отмечаешь те «строки», которые нужны и выкачиваешь себе локализацию. Общепопулярные бесплатны, специальные темы платно. Краудфандерам (переводчикам на общих началах) — льготный доступ.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое