Прочитал публикацию «Локализация Android приложения средствами Google Sheets» и удивился. Над проектом работает целая команда (переводчик, разработчик, автор), но одну из первоочередных задач — перевод продукта — решает неудобно.
Платные сервисы хороши всем, кроме того, что они платные. Перевод предполагает множество авторов по своей сути — и на роль удобного многопользовательского редактора одного документа сразу всплывает Google Doc.
Я разработчик маленького, но гордого приложения под Android. Как только в проект добавился 3-й язык (после английского и русского), я сразу перенес всю словарную базу в Google Таблицы. Сразу ощутил удобство сопоставления разноязычных строк — пришлось изрядно подкорректировать длины. Первые несколько раз я переносил переводы вручную в xml файлы ресурсов проекта. Потом плюнул и написал обычный парсер: из экспортированного TSV файла Google Sheet в набор файлов локализации, готовых сразу быть добавленными в проект.
Почему Delphi? — мне так было удобнее, не так давно ковырял старую программу по переформатированию хитрых файлов и для линейного разбора текстового файла в другой. Никаких лишних файлов в проекте.
Почему TSV? — csv не подходит из-за коллизий, если строки содержат запятые… а дальше не искал.
Так как я одновременно веду разработку двух проектов, и второй проект представляет собой более функциональную версию, мне показалось удобным иметь общую словарную базу для них. Разделение ресурсов через маркеры — первый столбец в таблице.
В разборе нет ничего хитрого. Я экспортирую файл в таблицу, разделенную табуляцией, и в парсере привожу к столбцам данных. Первый, как я уже упоминал, служебный и имеет метки, как обрабатывать строку:
Общая строка для базового проекта — универсальная для всех локализаций, хранится в общей папке values/ в string_common.xml
Уникальная строка — уникальная для языка, укладывается в свою локализованную папку values_**/strings.xml
В комментариях к оппонирующей статье видел вопрос по подготовке ресурсов для разных платформ. С отдельным инструментом для приведения Google Таблиц к файлам ресурсов это не проблема, а так, задача на свободный вечер.
Я веду разработку в Eclipse в Windows и мне удобно просто заменить файлы локализации. Весь контекст перевода легко прослеживается по соседним переводам и первым столбцам — комментариям. Весь перевод, а его более 1000! строк выполняется добровольцами, благодарными пользователями. Каждый релиз программы с обновленным переводом, какой бы он не был. При вопросах и предложениях о помощи с переводом я просто даю ссылку на таблицу.
P.S. Проект, как обещал, причесал и выложил на GitHub.
Платные сервисы хороши всем, кроме того, что они платные. Перевод предполагает множество авторов по своей сути — и на роль удобного многопользовательского редактора одного документа сразу всплывает 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.