Вступление

Локализация вашего приложения может быть сложной задачей. Мало того, что вам нужно проверить пользовательский интерфейс, чтобы убедиться, что строки правильно ограничены. Но есть еще проблема, связанная с самими струнами. Эта статья покажет вам красивый и простой способ локализации вашего приложения для iOS / macOS. :)

Подготовка

Прежде всего, нам нужно добавить в приложение еще один язык. Это делается в разделе «Локализация» на вкладке «Информация о проекте». Файл с именем Localization.strings должен автоматически создаваться Xcode. Apple называет этот файл таблицей локализации.

Локализация модулей

Я написал две статьи о модульной архитектуре на iOS, в то время как модуль - это фреймворк, в этой статье модуль - это логически отделенная часть приложения в папке. Но не волнуйтесь, процесс тот же. :) Продемонстрирую локализацию моего последнего проекта под названием AchieveMe. Допустим, у AchieveMe есть эти модули - Панель управления, Друзья, Цели, Логин и т. Д. Каждый модуль является логической частью приложения и имеет собственное перечисление локализованных строк. С учетом сказанного вы можете представить, что разделение локализации на модули позволит вам довольно легко находить строки в enum.

Локализованное перечисление

Поскольку у нас есть много модулей с еще большим количеством перечислений, было бы неплохо определить протокол интерфейса перечисления. Давайте создадим протокол LocalizedStringRepresentable, у которого есть метод доступа get для переменной с именем text. Переменная text будет той, которую мы будем использовать в коде для получения нашей локализованной строки.

Интервал между именами

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

В нашем случае пространство имен будет путем к модулю, разделенным точками. Например, вход в модуль будет иметь префикс module.login. в качестве пространства имен.

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

Теперь давайте посмотрим на перечисление LoginLocalization.

Использование в коде

Чтобы иметь локализованную строку в приложении, просто выберите соответствующий ключ из перечисления и вызовите текстовую переменную. Что мне действительно нравится в этом, так это то, что мы не используем в коде какие-либо необработанные непереведенные строки, что делает код более понятным.

Локализованная таблица

Тогда файл Localization.strings для входа в модуль выглядел бы так:

… Как видите, у каждого слова есть префикс модуля.

Локализованный метод поиска в таблице

Наконец, нам нужно создать расширение String, которое будет содержать локализованный метод, который мы собираемся использовать для перевода наших ключей, разделенных по именам, из таблицы Localized.strings.

Локализация XIB / Раскадровки

С тех пор, как я открыл для себя SnapKit (3 года назад), я старался избегать использования Interface Builder. Однако вы можете просто перетащить IBOutlet в быстрый файл, а затем использовать перечисление для правильной локализации строк. :)

Тестирование вашей локализации

Когда все настроено, пора попробовать приложение на других языках. К счастью, Apple упростила для нас эту задачу. Вы можете указать язык приложения в Edit Scheme → Options. После этого приложение запустится с указанным языком.

Заключение

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

Если вы найдете эти статьи полезными, прокомментируйте или похлопайте мне (… или 50) :)

Большое спасибо за чтение.