niklnd Apr 25 2017 at 17:54

Упрощение локализации в iOS

5 min

7.3K

Touch Instinct corporate blogDevelopment for iOS*Swift*

Tutorial

+14

Comments 24

slutsker Apr 26 2017 at 03:04

спасибо за ваше решение!
Статья в очередной раз вызвала у меня вопрос — ведь это же максимально распространенная задача: удобная кроссплатформенная локализация с теми фичами, о которых вы пишите. Разработка мобильных приложений появилась не вчера. Почему же нет удобного и массового решения этой задачи? Или я просто не знаю о нем?

niklnd Apr 26 2017 at 11:58

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

slutsker Apr 27 2017 at 02:06

А для Android что-то подобное уже существует?

KamiSempai Apr 27 2017 at 10:29

Могу предложить свое решение: LocoLaser: переводим приложения в Google Sheets
Работает с Android и iOS. Ресурсы находятся в гугл таблицах. Умеет генерировать Swift и Obj-C классы. Есть плагин для Gradle.

Tereks Apr 26 2017 at 05:29

А как в вашей системе разработчику добавить строку, чтобы ее увидели в команде локализации? Закоммитить в submodule?

niklnd Apr 26 2017 at 11:53

Да, всё верно.

Tereks Apr 26 2017 at 12:00

А как у вас происходит согласование строк? Если все будут коммитить в один репозиторий, то случится дублирование строк. Вы договариваетесь до коммита? К

niklnd Apr 26 2017 at 12:09

У нас есть code-review абсолютно для всех репозиториев. Как правило такие коммиты смотрят разработчики, которые участвуют в проекте, поэтому дублирование находится на этом этапе, так как pull request просто реджектится для исправления.

Lailore Apr 26 2017 at 07:42

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

niklnd Apr 26 2017 at 12:03

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

Lailore Apr 26 2017 at 13:23

Так я говорю про саб класс не просто так. в сторе борде будет не строка, а шаблон типа: {Today}: {$0} {Items}
И все динамическое на месте. Просто шаблонизатор

svanichkin Apr 26 2017 at 12:03

Вторая статья на тему локализаций за последний месяц и опять со своим велосипедом )) Я например использую нативные методы, локализация storiboard + локализация в строках и ничем меня это не коробит.

-2

niklnd Apr 26 2017 at 12:07

Любое решение имеет место быть.
Плюсы нашего в отличии от нативного указаны в статье.
Главные из них:
— кроссплатформенность
— ошибки при изменении сразу находятся на этапе компиляции, а не в продакшене у юзера
— отсутствие магических строк в сторибордах и коде.

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

KamiSempai Apr 26 2017 at 17:01

Работа со строками в iOS сделана таким образом, что невозможно иметь общую строковую базу на несколько платформ и не городить при этом велосипедов. Очевидно, вы разрабатываете только под iOS и не сталкивались с этой проблемой.

PS: хотел третью статью написать. Но видимо придется повременить. :)

budnikovv Apr 26 2017 at 12:53

замена магических строк на константы которые проверяет компилятор, схожий подход в статье https://habrahabr.ru/company/tinkoff/blog/271459/

niklnd Apr 26 2017 at 12:55

Не совсем схожий, так как у них в итоге генерируется в конце
NSLocalizedString(LocKey_main_continue, @"")

А у нас просто String.lockLeyMainContinue

Но идея в целом похожа

KamiSempai Apr 26 2017 at 16:54

Не приведет ли такое количество констант к увеличению времени запуска приложения?

niklnd Apr 26 2017 at 17:20

К вопросу про время компиляции — безусловно увеличивается, ровно как и любой run script в билд фазе. Однако, в сравнении с swiftlint статическим анализатором, то время на порядок меньше занимает.

Что касается увеличение времени запуска, то опять же смотря какого. Если имеется в виду холодный запуск приложения, то естественно да, так как все строка хранятся в static memory. Но при замерах, которые мы проводили разница в проекте с 1000 строк просто микроскопическая что находится в пределах статистической погрешности.

Да, и если интересует жестко вопрос оптимизации времени запуска приложения, особенно на свифте, то рекомендую посмотреть видео-запись доклада с прошедшей конференции мобиуса (видео будут через неделю), там это детально расписано и получаются конкретные цифры, а не абстрактные. (Не знаю можно ли в комментах рекламировать видео или нет :)

KamiSempai Apr 26 2017 at 17:11

Как по мне, так отдавать переводчикам JSON — неблагодарное дело. Обязательно что-то поломают. Код-ревью в этом случае выглядит как костыль.
Также, замечу, тема локализации Storyboard не раскрыта. Или вы готовите еще одну статью?

niklnd Apr 26 2017 at 17:25

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

KamiSempai Apr 26 2017 at 17:34

Возможно вам стоит взглянуть вот на этот подход: Удобная локализация iOS приложений в Interface Builder
Это та самая «первая» статья из двух за месяц. В ней я рассказал как можно избавится от аутлетов.

niklnd Apr 26 2017 at 17:45

Что происходит, если один и тот же label в сториборде может иметь разный текст? Как решается это в данном подходе?
Именно поэтому мы и решили сделать систему консистентной, а тут как говорится «лес рубят, щепки летят».

KamiSempai Apr 26 2017 at 17:59

Если какой-то компонент нужен вам в коде, вы делаете на него аутлет. И это нормально.
В статье описана ситуация с надписями которые не меняются в процессе работы программы. Тянуть ссылки на них в код, только чтобы поставить текст, мне кажется немного топорным решением.

Johan Apr 27 2017 at 17:30

На самом деле, есть ряд сервисов для групповой работы с переводами, которые дадут тот самый GUI для переводчиков. Суть затеи при этом не поменяется.

Кодогенерация — зачетная мысль.