Pull to refresh

Локализация мобильных приложений. Часть 2

Reading time6 min
Views16K
Если по-честному, то эта статья не должна являться продолжением первой моей статьи о мгновенном изменении языка iOS-приложений. Если первая статья была написана программистом для программистов, то в этой заметке пойдет речь непосредственно о процессе локализации, применимом к любой мобильной (и не очень) платформе.

Но мы меня простим и сделаем вид, что это цикл статей ;).

Итак. В процессе разработки большинства мобильных приложений возникает необходимость локализации. И в этот неловкий момент может возникнуть ряд правомерных вопросов: на какие языки переводить, что именно переводить, куда обращаться, на какие мелочи стоит обратить внимание.

Попробуем ответить на каждый из этих вопросов по отдельности.

На какие языки переводить?

Для приложений, ориентированных на конкретные страны/рынки проблема локализации не стоит в принципе. Прекрасное приложение Правила русского языка вряд ли будет интересно иностранцу, не изучающему этот самый русский язык и, соответственно, вряд ли стоит переводить приложение на суахили. В то же время, локализуя Smart Coin я руководствовался совершенно определенными принципами.

Во-первых, для русского разработчика, вероятно, читающего эту статью, русский язык это первый кандидат на локализацию. Ну, а, в-нулевых, английский. Это очевидно.

Во-вторых, для поиска языков отличных от английского и русского, нужно выбрать критерии. Первый — рынок для приложения должен быть большим. Первое, что приходит на ум — США, но на английский мы уже перевели. А что еще? Неплохой ответ дает Appannie — Японский, Немецкий, Французский, Итальянский и Китайский.

С Китаем не все просто, кстати. Для неискушенного читателя поясню — существует два вида китайского: традиционный и упрощенный. Традиционный используется по большей части в Гонконге и Тайвани, а упрощенный официально ввели в 1956 году на территории КНР. То есть это потенциально огромный рынок. Однако, хоть народу там и много, но платить они не любят, к сожалению. С другой стороны, если ваше приложение бесплатное, то неплатежеспособность роли не играет.

Далее. Еще чуть менее очевидный ответ — Бразилия, Мексика и Турция. Согласно ряду отчетов, Мексика, Россия, Бразилия и Турция — самые быстрорастущие неазиатские страны в аппсторе. Можно считать перевод на португальский, испанский и турецкий (на русский мы уже перевели самостоятельно ;)) вложением в перспективу.

Кстати, из неупомянутых стран/языков у Smart Coin неплохо идут продажи в Голландии. Это, пожалуй, все.

Итак, по языкам резюмирую: Английский, Японский, Немецкий, Французский, Итальянский, Китайский упрощенный, Испанский, Португальский, Турецкий, Русский, Голландский. Я взял еще Китайский традиционный и Корейский. До кучи :).

По опыту скажу, что с переводом на бразильскую версию португальского заморачиваться особенно не стоит. Во-первых, сам аппстор в случае наличия португальского и отсутствия бразильского-португальского перенаправит всех бразильцев на португальскую версию приложения, а во-вторых, бразильский-португальский от португальского отличается меньше чем в 1% довольно специфических слов. Ровно та же ситуация с вариациями английского (UK vs. US vs. AU) и французского (FR vs. CA vs. BE vs. дофига всего).

Что переводить?

Вначале, стоит разобраться, что это за вопрос вообще такой. Что переводить? «Все!» ответит неискушенный читатель и будет, черт побери, прав сто раз. С другой стороны, разбирающийся человек задаст вопрос «а что важнее — описание в аппсторе или перевод самого приложения?»…

Для себя лично я вывел следующие правила:
  • Если решил дать какму-то языку приоритет для локализации, в первую очередь переводи описание в аппсторе.
  • Если бюджет позволяет сделать локализацию самого приложения на этот язык — делай.
  • Перевод приложения без перевода описания не имеет особого смысла.

Буду рад каким-то комментариям по поводу утверждений выше, но как по мне, так пользователь скорее откинет какое-то приложение, если он не готов воспринимать его, скажем, на английском, если не переведено описание. С непереводенным интерфейсом он кое-как смирится, страничку с непереведенным описанием такой пользователь, скорее всего, закроет сразу.

Куда обращаться?

Тут есть несколько вариантов:
  1. Профессиональное бюро переводов (как пример, могу порекомендовать Egotranslating — пользовался для перевода документов, доволен. За рекламу они мне ничего не платят, честно :). Еще видел неплохие отзывы о www.tethras.com)
  2. Веб-порталы с носителями языка, которые получают деньги за перевод (к примеру, onehourtranslation.com, gengo.com, translationcloud.net или crowdin.net)
  3. Полностью бесплатные веб-порталы, основанные на принципе кармы и рейтинга — ты мне, а я — тебе. Например, ackuna.com
  4. Машинные переводы — google translate и иже с ним.

Недостаток машинных переводов (4) очевиден. Профессиональные переводы (1) зачастую дороги, но в этом случае есть хоть какая-то гарантия качества, которой не может быть при использовании бесплатных порталов crowd-переводов (3).

Пример не самой удачной (но явно сделанной человеком) локализации можно видеть на следующем скриншоте:

Локализовать Smart Coin было решено с помощью onehourtranslation. Преимущества:
  • Недорого. Для проекта, который изначально задумывался for fun это очень важный аспект.
  • С переводчиком всегда можно обсудить перевод.
  • В случае какого-то недовольства, можно открыть диспут и если недовольство оправданно, деньги вернутся обратно на счет (внутри системы, но это значит, что заявку на перевод можно открыть еще раз).
  • Существует система проверки перевода — proofreading. Я использовал лишь однажды — для проверки своего корявенького английского. Отдельно стоит столько же сколько и обычный перевод. Но если заказывать вкупе с переводом, то получится на 30% дешевле.
  • Можно заказать перевод профессионалу из какой-то определенной области (в моем случае это мобильные приложения, но есть до черта разных — медицина, юриспруденция, итп) — стоить будет в два раза дороже обычного перевода, но, опять же, гарантия качества. Я не парился и переводил через стандартных переводчиков.

В целом, все получилось вполне удачно — люди в этом коммьюнити отзывчивые, в большинстве своем отписываются по результату, предлагают в случае любых вопросов контактировать и спрашивать. Многие из них даже просят скриншоты и контекст для более точного перевода, либо же предлагают варианты и описывают в каких местах какой из вариантов лучше использовать. Подобный подход несказанно радует.

На какие мелочи стоит обратить внимание?

Для себя я путем проб и ошибок выработал следующее правило: максимально подробное описание задачи для переводчика. Описывать буквально каждую мелочь — в моем случае это был, например, формат файла Localizable.strings:
«String_id» = «string to translate»;

Ввиду того, что String_id зачастую выглядит как обычная строка, переводчик может запросто взять и без задней мысли перевести обе строчки. В нашем случае это будет означать дополнительную работу для нас и бесполезную работу, которую проделал переводчик.

korean exampleЕще пример — собственно, сами переводы строк. В одном из моих приложений симпатичный старт гайд, который на пальцах объясняет принципы работы. Это обычные оверлей-картинки, строкам в которых очень важно влезать по длинне и выглядеть красиво. И если в случае с переводами на европейские языки у меня проблем с расстановкой переводов строк не было, то в случае с иероглифами эта проблема вставала в полный рост! Просил специальными символами пометить в переводе возможные места разрыва. Все, кроме одного отнеслись к проблеме с пониманием, однако, корейский переводчик отказался без объяснения причин да и в целом оказался не слишком внимателен, я влепил ему четыре звезды, а переводы строк расставил с помощью google translate. Такой вариант тоже можно иметь в виду.

Еще один нюанс на который стоит обратить внимание при размещении проекта на onehourtranslation это количество слов. На этом сайте количество слов это вид оплаты — перевод одного слова стоит пять центов. И, в принципе, точное количество слов высчитывать, наверное, не обязательно — это, кстати, очередной плюс этого сайта. В случае с профессиональным переводчиком вам выкатят счет за каждый предлог и артикль использованный в тексте. С onehourtranslation же все было весьма просто. Во-первых, во время размещения проекта в текстовых (txt, doc, rtf) файлах сайт сам считает количество слов, однако можно ввести и руками. Например, в файле .strings нужно посчитать количество слов без string_id. Я просто убрал все что шло до символа "=" с помощью reg exp'ов и сунул текст в word, который внизу окошка выдал общее количество слов. Ну и если где-то ошибся в ту или иную сторону, никто тебя укорять не станет. А по результатам перевода, если он сильно понравился или надо что-то доперевести, переводчику можно накинуть денег «на чай». Очень грамотно, я считаю.

Скандинавия. Решил эту проблемку вынести отдельно — уж больно неожиданно все вышло. На onehourtranslation найти переводчика на норвержский оказалось непосильной задачей. Через 3 (!) дня (при том, что ВСЕ остальные обычно стартовали в течение 1-2 часов) после открытия проекта и полного его игнора со стороны переводчиков, я написал в саппорт и спросил «Что за нафиг», мне был ответ «Скандинавские переводчики очень редки. Попробуйте заинтересовать их открыв специализированный перевод мобильного приложения (в два раза дороже)». В результате я плюнул на норвержский. Возможно и зря, но тратить на малоперспективный язык в два раза больше денег мне не хотелось. Может быть и дойдут руки когда-нибудь.

В общем и целом это, наверное, все. Надеюсь ничего не забыл и статья вам поможет ;).

Делайте качественные приложения. Успехов!
Tags:
Hubs:
+15
Comments12

Articles