Комментарии 10
Для первого шага неплохо, но есть пара вопросов.
Как у вас решается проблема обновлений? Скажем, из 200 значений для исходного языка к следующей версии разработчик поменял 20 (не меняя ключей), добавил 10 и удалил 5.
Плюс, рано или поздно неизбежно встанет проблема контекста. Например, есть у вас русская строчка «с» — переводчик должен переводить это на английский как «with» (я пришёл с Васей) или «since» (мы дружим с детства)? Практически все форматы локализации дают возможность проставлять контекстные комментарии к ключам, чтобы переводчик знал, что переводит.
Не сочтите за рекламу, но для более серьёзной работы (~10000 строк, ежедневные обновления некоторых фрагментов) мы использовали платный сервис Crowdin, вполне прозрачно решающий практически все проблемы, возникающие в процессе локализации. Для разработчиков всё получалось просто: push/commit в одну из систем контроля версий, скрипт синхронизации сам вычитывает и заливает в сервис все изменившиеся файлы, а после окончания перевода автоматически коммитит результат обратно.
Всё зависит от многих факторов, и ваш способ вполне подходит, если платформа одна, проект небольшой и переводчикам не требуется Translation Memory. Но я бы не рекомендовал его к использованию в непрерывно разрабатываемых проектах, ресурсные файлы которых превышают 100-200 строк.
Как у вас решается проблема обновлений? Скажем, из 200 значений для исходного языка к следующей версии разработчик поменял 20 (не меняя ключей), добавил 10 и удалил 5.
Плюс, рано или поздно неизбежно встанет проблема контекста. Например, есть у вас русская строчка «с» — переводчик должен переводить это на английский как «with» (я пришёл с Васей) или «since» (мы дружим с детства)? Практически все форматы локализации дают возможность проставлять контекстные комментарии к ключам, чтобы переводчик знал, что переводит.
Не сочтите за рекламу, но для более серьёзной работы (~10000 строк, ежедневные обновления некоторых фрагментов) мы использовали платный сервис Crowdin, вполне прозрачно решающий практически все проблемы, возникающие в процессе локализации. Для разработчиков всё получалось просто: push/commit в одну из систем контроля версий, скрипт синхронизации сам вычитывает и заливает в сервис все изменившиеся файлы, а после окончания перевода автоматически коммитит результат обратно.
Всё зависит от многих факторов, и ваш способ вполне подходит, если платформа одна, проект небольшой и переводчикам не требуется Translation Memory. Но я бы не рекомендовал его к использованию в непрерывно разрабатываемых проектах, ресурсные файлы которых превышают 100-200 строк.
Проблема обновлений решается просто — целиком перезаписываем документ данными из IDE, переводим, экспортируем, перезатираем файлы в проекте, пуш, GOTO 0.
Дассс, проблема с контекстом действительно может рано или поздно возникнуть, хотя у нас таких проблем не было. Возможно еще и потому, что переводит текст на норвежский наш тестировщик. Он знает контекст, а на датский и шведский можно его узнать, глядя на норвежский, потому что они очень похожи.
Существует несколько онлайн тулов, но они все платные, что влечет за собой возню с бюрократией (самое удивительное, что этой возни нет при единоразовой покупке по R#, dotCover), но там где подписка, начинаются проблема + нужно было бы пинать администратора, администрирующего наш git/gerrit. Заказчик считает, что время разработчика дешевле этой возни.
10000 тысяч строк — это уже монстр какой-то. В нашем проекте их ~300.
Дассс, проблема с контекстом действительно может рано или поздно возникнуть, хотя у нас таких проблем не было. Возможно еще и потому, что переводит текст на норвежский наш тестировщик. Он знает контекст, а на датский и шведский можно его узнать, глядя на норвежский, потому что они очень похожи.
Существует несколько онлайн тулов, но они все платные, что влечет за собой возню с бюрократией (самое удивительное, что этой возни нет при единоразовой покупке по R#, dotCover), но там где подписка, начинаются проблема + нужно было бы пинать администратора, администрирующего наш git/gerrit. Заказчик считает, что время разработчика дешевле этой возни.
10000 тысяч строк — это уже монстр какой-то. В нашем проекте их ~300.
А я и не говорил, что 10000 строк — это один проект. Это весь портфель проектов довольно крупной компании, выходящей на международный рынок. Но суть не меняется.
Вам во многом повезло, и большая часть тех граблей, которые возникают в процессе локализации, у вас не возникла. Но если в перспективе планируется вновь работать с многоязычными проектами, я бы предложил довести ваш процесс хотя бы до чего-то подобного:
1. Скриптом парсим нужные файлы по заданному шаблону в табличку (да хоть CSV, если его умеет Гугл). Как раз в этот скрипт можно и заложить парсинг контекста (в Android strings.xml это XML-комментарий, непосредственно стоящий перед нодой строки).
2. Если в Google Drive уже лежит подобная табличка, для каждой строчки старой таблички проверяем, если в новой таблице есть такой же ключ с таким же значением на исходном языке — заменяем новую строку со всеми переводами старой строкой, т.к. всё уже переведено.
3. Если в новом файле осталось что-то непереведённое, заменяем его и триггерим какое-то событие «пнуть переводчиков» (SMS, Email, Jabber…).
4. Перепинываем ссылку на документ между переводчиками и пруфридерами до готовности, после чего выгружаем и сохраняем себе, куда надо.
5. ????
6. PROFIT!
Вам во многом повезло, и большая часть тех граблей, которые возникают в процессе локализации, у вас не возникла. Но если в перспективе планируется вновь работать с многоязычными проектами, я бы предложил довести ваш процесс хотя бы до чего-то подобного:
1. Скриптом парсим нужные файлы по заданному шаблону в табличку (да хоть CSV, если его умеет Гугл). Как раз в этот скрипт можно и заложить парсинг контекста (в Android strings.xml это XML-комментарий, непосредственно стоящий перед нодой строки).
2. Если в Google Drive уже лежит подобная табличка, для каждой строчки старой таблички проверяем, если в новой таблице есть такой же ключ с таким же значением на исходном языке — заменяем новую строку со всеми переводами старой строкой, т.к. всё уже переведено.
3. Если в новом файле осталось что-то непереведённое, заменяем его и триггерим какое-то событие «пнуть переводчиков» (SMS, Email, Jabber…).
4. Перепинываем ссылку на документ между переводчиками и пруфридерами до готовности, после чего выгружаем и сохраняем себе, куда надо.
5. ????
6. PROFIT!
Позвольте узнать, как решается проблема с контекстом в сервисе Crowdin?
Я джва года ждал такой скрипт!
Сам делаю в гугл таблицах словари, из них выгружаю в Эксель, в Экселе собираю инсерты для БД.
Сам делаю в гугл таблицах словари, из них выгружаю в Эксель, в Экселе собираю инсерты для БД.
Моего знакомого нет на хабре, но статья его заинтересовала и он попросил меня задать вопрос вам. Буду рад если откликнитесь
«Наша фирма разрабатывает приложения сразу на 3 платформы: Android, WP и iOS. Собственно интересует вопрос, как лучше организовать локализацию сразу на 3 платформы? По поводу Android и WP особых вопросов не возникает, все делается также как и было описано в этой статье, только скрипт на питоне. А вот с iOS есть проблемы, так как локализация там кардинально отличается.
На данный момент мы решили сделать так: К локализованной строке добавляется строковый комментарий с именем ID, питоновский скрипт ищет ресурс под этим комментарием и локализует его.
Недостатки: Для генерации файлов локализации нужны сгенерированные .strings для всех языков, Xcode пытается оптимизировать ресурсы и склеивает 2 одинаковых в один, в результате чего теряется возможность создавать 2 разных перевода в зависимости от контекста.
Я предлагал решить эту проблему путем подстановки ID вместо строки, тогда бы получился файл вот с такими строками:
»string_res_1" = «Localized string 1»;
«string_res_2» = «Localized string 2»;
и так далее…
Но iOS программист отказался так делать, сославшись на то, что если мы забудем локализовать какую либо строку, пользователь может увидеть невнятный код вместо человеческого сообщения на английском языке, да и в сторибоард с кодами экран выглядит не так как должен быть."
«Наша фирма разрабатывает приложения сразу на 3 платформы: Android, WP и iOS. Собственно интересует вопрос, как лучше организовать локализацию сразу на 3 платформы? По поводу Android и WP особых вопросов не возникает, все делается также как и было описано в этой статье, только скрипт на питоне. А вот с iOS есть проблемы, так как локализация там кардинально отличается.
На данный момент мы решили сделать так: К локализованной строке добавляется строковый комментарий с именем ID, питоновский скрипт ищет ресурс под этим комментарием и локализует его.
Недостатки: Для генерации файлов локализации нужны сгенерированные .strings для всех языков, Xcode пытается оптимизировать ресурсы и склеивает 2 одинаковых в один, в результате чего теряется возможность создавать 2 разных перевода в зависимости от контекста.
Я предлагал решить эту проблему путем подстановки ID вместо строки, тогда бы получился файл вот с такими строками:
»string_res_1" = «Localized string 1»;
«string_res_2» = «Localized string 2»;
и так далее…
Но iOS программист отказался так делать, сославшись на то, что если мы забудем локализовать какую либо строку, пользователь может увидеть невнятный код вместо человеческого сообщения на английском языке, да и в сторибоард с кодами экран выглядит не так как должен быть."
«Со сторибоард, кстати, отдельная тема, так как нет возможности повлиять на генерацию комментариев и ID ресурсов. В итоге все переводится в коде 0_о. Тесть получаются ссылки на UILabel и в коде им ставится локализованный текст.»
Это вы мне или Archon? Если мне, то я тут ничем не могу помочь, нет опыта ни iOS, ни WP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Локализация Android приложения средствами Google Sheets