13 марта 2019

Локализация и интернационализация в iOS

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

Локализация и интернационализация

Зачастую разработчики путают эти два термина или считают, что это одно и то же. Оба этих термина взаимозаменяемы, но на самом деле являются разными, но взаимосвязанными понятиями.

Локализация — это процесс адаптации пользовательского интерфейса и ресурсов приложения для соответствия культурным, языковым и другим требованиям конкретного целевого рынка. Термин «локализация» часто используется как синоним термина «перевод». Но локализация не ограничивается переводом интерфейса на другой язык. Язык — это всего лишь часть локализации. Следующие элементы также необходимо учитывать в процессе локализации:

  • форматы даты и времени, включая числовые форматы;
  • используемая валюта;
  • правила грамматики;
  • направление языка;
  • текст и изображения, которые в разных культурах могут рассматриваться как деликатные или могут быть неверно истолкованы;
  • цвета и символы;

и другое.

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

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

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

Средства для интернационализации и локализации в iOS

Весьма часто разработчики ограничиваются созданием файлов .strings для перевода пользовательского текста. Данный тип файлов используется для хранения всех локализованных строк в приложении в виде перечисления пар ключ-значение. Ключ — это обычно идентификатор строки для локализации, значение — переведенная строка. По умолчанию для локализованного текста в iOS используется файл с именем Localizable.strings.

Но, как описывалось ранее, локализация не сводится к переводу текстов, а интернационализация не сужена до простого использования Localizable.strings. Так как необходимо брать в расчет и другие аспекты, то может потребоваться написание дополнительного кода или логики. К счастью, в iOS имеется множество готовых механизмов для интернационализации и локализации. Поэтому перед тем, как приступить к работе, проверьте, существует ли готовое решение.

В iOS доступно два основных способа интернационализации:

  • С помощью редактора пользовательского интерфейса (.xib, .storyboard).
  • В коде (.m, .swift, etc).

Интернационализации пользовательского интерфейса

Вы можете локализовать файлы интерфейса двумя способами:

  • Использование отдельных файлов .storyboard /.xib для разных локалей.
  • Использование файлов .strings для разных языков и предоставление переведенного текста.

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

Использование Вase internationalization

Базовая интернационализация позволяет вам иметь дело с новым элементом пользовательского интерфейса только один раз, вместо того, чтобы добавлять его в несколько отдельно локализованных наборов. Включая базовую интернационализацию, Xcode изменяет структуру папок проекта — создаются отдельные папки для каждого языка. Xcode предлагает вам определить ресурсы, которые будут использоваться в рамках базовой интернационализации, а также попросит вас определить язык по умолчанию, например, английский. Файлы .storyboard или .xib будут перемещены в папку Base.lproj, в то время как их строковые элементы будут помещены в папки локали проекта, например, en.lproj. Сохраняя новые файлы пользовательского интерфейса в папке Base.lproj, вы также даете им возможность поддерживать базовую интернационализацию.

Localization internationalization iOS Noveo Internationalization localization iOS Noveo

Но использование такого способа интернационализации также имеет ряд недостатков:

  • Новые локализационные ключи не добавляются автоматически при добавлении новых элементов в пользовательский интерфейс. вам придется использовать утилиты, чтобы сделать это (ibtool, AppleGlot, BartyCrouch).
  • Локализационные ключи трудно сопоставить с их первоначальным представлением (читай подклассом UIView). Вы можете видеть только тип локализованного view и переведенный текст.
/* Class = "UILabel"; text = "This is a test"; ObjectID = "UXG-2b-0WP"; */
"UXG-2b-0WP.text" = "This is a test";
  • Невозможно повторно использовать локализацию из других .strings файлов. Отсюда вытекает проблема дублирования локализационных строк.
  • Не поддерживается динамическая локализация множественных форм существительных (aka плюрализация).

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

Использование Auto Layout

Разные языки могут в значительной степени различаться по длине слова. Континентальные европейские языки, такие как французский, немецкий и испанский, могут быть на 20-50% длиннее, чем английский, тогда как азиатские языки, как правило, сокращаются на 30-50%. Используйте Auto Layout, чтобы компоновать свои views относительно друг друга без фиксированного расположения, ширины и высоты, чтобы views изменялись соответствующим образом при изменении языка или локали.

Советы по использованию Auto Layout при интернационализации приложений:

  • Удалите все constraints фиксированной ширины и высоты. Если тексту не хватает места для размещения, он может обрезаться.
  • Прикрепляйте views к соседним views. Таким образом, когда один view изменяется в соответствии с вашим локализованным текстом, другие views будут занимать правильные позиции. В противном случае views могут пересекаться на некоторых языках.
  • Вместо атрибутов left и right  используйте leading и trailing. Это правило позволит правильно расположить views для RTL-языков, таких как арабский или иврит. Если язык разработки LTR, выравнивайте views, начиная с верхнего левого угла, и добавляйте constraints, расширяющие views до нижнего правого угла. В таком случае большая часть пользовательского интерфейса отобразится зеркально на языках справа налево.

Internationalization localization iOS Noveo

  • Для выравнивания текста используйте NSTextAlignment.natural вместо .left. Это автоматически правильно расположит текст для любого направления языка.

Internationalization localization in iOS Noveo

Интернационализации в коде

Чаще всего интернационализация вашего приложения не ограничивается перечислением пользовательского текста в .storyboard и .xib. Например, вам может понадобится показать оповещения или ошибки с использованием UIAlertController или динамически добавить view с пользовательским текстом на экран. iOS обеспечивает механизм для получения локализованного текста из файлов .strings во время выполнения. Чтобы локализовать строки из кода, вам нужно использовать функцию NSLocalizedString — она вернет локализованную версию строки, если такая есть:

func NSLocalizedString(_ key: String, tableName: String? = default, 
bundle: Bundle = default, value: String = default, comment: String) -> String

NSLocalizedString обычно сопровождается двумя аргументами, первый из которых является ключом (key), а второй — комментарием (comment) для обеспечения дополнительного контекста. Комментарий не является обязательным и может быть заменен на "". Но он может послужить подсказкой и помочь избежать неправильных переводов. Параметр tableName указывает на имя файла .strings, в котором нужно искать строку. По умолчанию имя файла Localizable.strings. Но можно добавить несколько .strings-файлов для того, чтобы организовать строки в проекте. Например, сделать по отдельному строковому файлу для каждого экрана или модуля в проекте. Параметр bundle определяет бандл, в котором следует искать .strings-файл. По умолчанию это будет бандл main. И наконец, value задает строку для отображения пользователю, если функция не находит локализованную строку, связанную с ключом.

Можно начать вручную вводить пары ключ-значение в строковые файлы, но есть более простой способ: можно запустить утилиту extractLocStrings, которая сделает это за нас. Утилита анализирует исходные файлы .c, .m, .swift и генерирует файлы .strings — по одной записи для каждого уникального локализуемого строкового ключа. Просто запустите команду в терминале:

find . -name "*.swift" -print0 | xargs -0 xcrun extractLocStrings -o Base.lproj

Команда отыщет все файлы с расширением .swift в текущей или ниже директории и применит для них extractLocStrings, результат запишет в папку Base.lproj. Подробнее про find, xargs, xcrun.

Например, у вас в SignInViewController.swift имеется следующий код:

let signInButtonTitle = NSLocalizedString("login-screen.sign-in-button", 
comment: "Sign in button")

let signUpButtonTitle = NSLocalizedString("login-screen.sign-up-button", 
value: "Sign up", comment: "")

В результате работы утилиты будем иметь следующее:

/* Sign in button */
"login-screen.sign-in-button" = "login-screen.sign-in-button";

/* No comment provided by engineer. */
"login-screen.sign-up-button" = "Sign up";

Здесь наглядно видно, как работают параметры NSLocalizedString при генерации строкового файла. Дефолтным значением будет являться сам ключ, если не указан параметр value. No comment provided by engineer будет комментарием по умолчанию, если разработчик поленился предоставить значение для comment.

Обратите внимание на следующие моменты:

  • extractLocStrings перезаписывает существующие строковые файлы. Команда не решает проблему слияния строковых файлов.
  • При указании разных комментариев для одного и того же ключа будет использован только один последний найденный.
  • При указании разных значений для одного и то же ключа будет использовано только одно, но команда выдаст предупреждение Key "Key" used with multiple values. Value "Value 1" kept. Value "Value 2" ignored.

Ниже будут рассмотрены способы доставки строковых файлов до переводчиков.

Плюрализация, даты, числа, измерения

Языки могут иметь различные правила образования множественной формы слов. В некоторых языках слово не меняется в множественном числе (например, японский), а для других слово будет меняться в зависимости от количества (например, русского). Для разных правил множественности строки указываются в файле .stringdict, который представляет собой plist с расширением .stringdict. Это позволяет использовать одну строку в коде, которая затем будет локализована с использованием правил множественного числа для zero, one, two, few, many, other по мере необходимости. Подробнее про подход можно посмотреть здесь.

В некоторых арабских странах цифры выглядят иначе, чем мы привыкли видеть. Вместо 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 используется ٠‎ (0), ١ (1), ٢ (2), ٣ (3), ٤ (4), ٥ (5), ٦ (6), ٧ (7),‎ ٨ (8),‎ ٩ (9).‎ Чтобы заменить части текстовой строки, например, числа, динамическими значениями, во время выполнения программы можно воспользоваться методом localizedStringWithFormat(_:_:) у String. Выглядеть это будет следующим образом:

String.localizedStringWithFormat(
  NSLocalizedString("Greeting",
    comment: "My name is {username}. I am {number} years old."), name, age)

Одной из удобных функций форматированной строки являются позиционные спецификаторы, можно сообщить форматированию порядок аргументов, вставив n$ (n-позиция) в спецификатор формата (%1$@, %2$d, %3$lf, etc). Например:

  • en.lproj/Localizable.strings
"UserFavoriteFood" = "%1$@'s favorite food is %2$@";
  • ru.lproj/Localizable.strings
"UserFavoriteFood" = "%2$@ - любимая еда %1$@";
  • Код
let userFavoriteFood = String(
    format: NSLocalizedString("UserFavoriteFood", comment: ""),
    name, food)

NumberFormatter хорошо известен большинству разработчиков iOS, поскольку он помогает округлять и анализировать числа. Однако не все знают, что он также выполняет работу по локализации. Например, использование NumberFormatter приведет к отображению 5.4 в локали США и 5,4 во французском языке. Это становится еще более полезным для отображения валют. Например, в США обычно пишут $100, а в России — 100 руб.

Для управления датами существует соответствующий класс DateFormatter, значениями веса и массы — MassFormatter, для измерений длины и высоты — LengthFormatter, и другие. Форматтеры исключительно полезны, когда дело доходит до переводов, поскольку они делают много работы для нас. Они управляют именами, датами, цифрами или валютами и позволяют легко конвертировать из одного формата в другой. Apple уделяет им серьезное внимание, но иногда разработчики даже не знают, что они предоставляют такую широкую функциональность, или используют их неправильно. Но следует быть осторожным — так как работа происходит под капотом, возможно некоторое непредсказуемое поведение.

Локализация изображений

Иногда может потребоваться обновить изображение для определенного языка. Например, картинку с неоднозначным жестом. Вместо того, чтобы использовать if-else в коде, возможно создать локализованное изображение и указать изображения для разных локалей. Единственным недостатком такого подхода является невозможность поместить такие изображения в файл .xcassets. Другое решение — добавить различные версии изображений в файл ресурсов с разными именами, затем вставить имена в файл Localizable.strings и получать соответствующее изображение в коде следующим образом:

let image = UIImage(named: NSLocalizedString("some_image", comment: ""))

Другим хорошим примером может служить кнопка «Назад» на арабском языке. Поскольку этот язык пишется справа налево, стрелка должна быть направлена вправо. Но для этого варианта в Xcode есть простое решение в каталоге .xcassets — нужно просто указать, для каких направлений применимо изображение:

Internationalization localization iOS Noveo

Взаимодействие с веб-службами

В значительной части iOS-приложений есть взаимодействие с веб-службой для отображения контента. О локализации этого контента тоже важно не забывать. Часто веб-службы предоставляют динамические данные, управляемые локалью. Есть два способа передать эту информацию веб-сервису: через Cookie или в заголовке HTTP. Но совместимый со стандартами метод заключается в использовании заголовка HTTP Accept-Language, так как многие веб-серверы легко справляются с этим заголовком. В свою очередь очень просто извлечь текущий язык приложения в iOS:

let locale = NSLocale.current.languageCode

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

Добавление локализационных строк

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

Ниже рассматриваются некоторые варианты такой автоматизации.

XLIFF

XLIFF — расширяемый платформенно-независимый стандарт обмена локализуемыми данными и сопутствующей информацией, основанный на языке разметки XML.

Xcode предлагает функцию быстрого экспорта всех файлов .strings для заданного языка в один файл .xliff. Файлы XLIFF используются многими системами перевода. Android не поддерживает XLIFF напрямую, но есть инструменты, которые генерируют из него файлы strings.xml. Файл XLIFF из Xcode будет содержать файлы базовой интернационализации (по одному на .storyboard и .xib), файл Localizable.strings и файл InfoPlist.strings. Отправьте XLIFF файл в команду локализации для перевода на несколько языков.

Во время перевода вы можете продолжить разработку своего приложения. Переводчики должны возвращать отдельный файл .xliff для каждого языка с фактическим переводом. Файлы должны использовать идентификатор языка в качестве префикса. Например, если вы запросите перевод английского en.xliff на немецкий и русский языки, возвращаемые файлы должны быть названы de.xliff для немецкого и ru.xliff для русского.

При первом экспорте локализации папка проекта содержит только базовую интернационализацию с файлами ресурсов .storyboard и .xib, из которых Xcode создает файлы строк, для включения в экспортируемый XLIFF. Xcode не добавляет файлы строк в проект до тех пор, пока вы не импортируете локализацию позже. В момент импорта язык и файлы строк для языка добавляются в проект. Например, импортируя fr.xliff, французский язык добавляется в проект. Xcode создает папку fr.lproj в папке проекта и добавляет локальную копию Localizable.strings и InfoPlist.strings в папку fr.lproj. В следующий раз, при импорте локализации, строковые файлы объединяются с существующими файлами проекта.

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

  • Не предоставляется визуальный и функциональный контекст.
  • Не предоставляются ресурсные данные, такие как ассеты.
  • Не предоставляются метаданные о сгенерированном XLIFF.
  • XLIFF не имеет атрибутов ограничения размера и длины, что может быть очень полезно, чтобы локализаторы знали, будет ли строка отображаться на экране Watch, или экране iPhone, или экране iPad, чтобы принимать решения о длине перевода.

Чтобы решить эти проблемы, Apple внедрила новую систему экспорта и импорта локализации в Xcode 10.

Xcode Localization Catalog

Apple пытается помочь разработчикам локализовать свое приложение более эффективно, расширяя возможности экспорта локализации Xcode. Новый способ экспорта локализации называется Xcode Localization Catalog и имеет расширение .xcloc. По сути это папка, наполненная ресурсами, а не только одним .xliff. Идея состоит в том, чтобы отправить переводчикам все, что им нужно, и получить все обратно таким же образом.

Теперь, вместо экспорта только текстовых строк, Xcode фактически экспортирует любой контент, который вы выберете. Прежде вам приходилось отправлять любой нетекстовый контент переводчикам раздельно, но теперь вы можете экспортировать и импортировать ассеты, сохраняя иерархию каталогов. Еще одной особенностью файла .xcloc, помимо возможности включать в себя .storyboard-файлы для контекста, является папка Notes. Папка Notes изначально пуста, но вы можете добавить свой файл ReadMe и скриншоты. Apple настоятельно рекомендует автоматизировать создание скриншотов с помощью тестов, введенных в Xcode 9.

Internationalization localization iOS Noveo

Google Spreadsheet

Разработчики часто используют Google Spreadsheet для доставки локализационных строк до переводчиков. Google Spreadsheet позволяет достаточно легко решить проблему локализации для iOS и Android одновременно.

Локализация на обеих платформах работает с использованием системы на основе ключа. Каждый язык представляет собой набор пар ключ-значение, где ключ является идентификатором для этой конкретной строки, а значение представляет собой переведенную строку на определенном языке. Для начала достаточно добавить три столбца на лист. Первый для ключей iOS, второй для ключей Android и последний для реальных текстов для перевода. Когда появляется новый язык, просто добавляется еще одна колонка с ним. Google Spreadsheet позволяет индивидуально настроить доступ к редактированию таблицы, поэтому каждый переводчик имеет доступ только к колонкам со своими языками.

Internationalization localization iOS Noveo

Чтобы автоматизировать процесс добавления новых ключей, доставку новых переводов в приложение, а также избежать проблемы с разным синтаксисом для параметров и iOS, и Android, используют специальные скрипты и утилиты. Простейшим примером может служить утилита localize-with-spreadsheet.

Но подход не лишен недостатков:

  • Для каждого визуального элемента с текстом для перевода в каждом .storyboard и .xib потребуется создание IBOutlet.
  • Отсутствие версионирования и интеграции похода в Gitflow Workflow. Любые изменения в локализации, а не только необходимые для текущей ветки разработки, появляются сразу. А удаление строки может вызвать сбои или баги в приложении для других веток.
  • В приведенном примере утилиты отсутствует поддержка плюрализации.
  • При использовании на двух платформах потребуются дополнительные усилия на синхронизацию ключей, чтобы предотвратить разрастание документа и упростить задачу переводчикам. Понадобятся постоянные коммуникации между командами для согласования набора строк, чтобы избегать дублирования переводов и выделения платформо-специфичных ключей.

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

Динамическая локализация

Еще одним удобным способом для получения переводов является скачивание локализационных файлов с веб-сервера. Как часто разработчики слышат «Просто поменяйте пару строк» или «Добавьте новый язык»? Этот же способ позволяет не только добавлять новые переводы без перекомпиляции, но и обновлять их даже для залитого в Store приложения, без необходимости задействовать разработчиков каждый раз. При скачивании ресурсов локализации на сервер отправляется текущий номер версии локализации, в ответ получаются новые файлы и новый номер версии. К слову, такой подход можно применять и для других ресурсов приложения, не только для переводов.

Но нужно помнить о следующих моментах при использовании такого подхода:

  • Для загрузки языков с сервера требуется время. И даже чтение кэшированных файлов с диска может занимать некоторое время. Нужно убедится, что в эти моменты в приложении не будут отображаться текст из Interface Builder или локализационные ключи. А это влечет либо увеличение времени запуска приложения, либо изменения текстов «на лету».
  • Стандартный вызов NSLocalizedString предполагает, что строки находятся в основном бандле приложения: если вы хотите использовать другой путь до локализации, вам нужно заранее позаботиться об указании нужного бандла.

Другие инструменты

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

Советы

  • Одна из самых больших ошибок, которые люди делают с локализацией — это откладывать ее на потом. Не стоит оттягивать интернационализацию и локализацию до финальных этапов разработки вашего приложения. Можно столкнуться с огромным количеством проблем, возникающих в конце. Продумайте, как вы организуете эти процессы в самом начале.
  • Не вписывайте пользовательские строки непосредственно в программный код. Сохраняйте все пользовательские строки в файлах локализации с самого начала.
  • Установление соглашения об именовании для строковых идентификаторов. Не стоит именовать ключи точно так же, как и значения для одного из поддерживаемых языков. Это усложнит поиск недостающего перевода и понимание контекста. Используйте подход с разделением имен, как этот:
NSLocalizedString("SortScreen.Label.TheOrder.text", "")
NSLocalizedString("OrderScreen.Button.Order.normalTitle", "")

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

  • Добавьте комментарии к своим пользовательским строкам, когда это возможно, чтобы уточнить, где и как будут использоваться строки. Сделайте скриншоты экранов, которые нужно локализовать. Чем больше контекста вы можете предоставить для своей команды переводчиков, тем лучше.
  • Избегайте конкатенации строк. Две или несколько строк иногда объединяются разработчиками с целью экономии места. Тем не менее, порядок слов существенно различается в каждом языке, и конкатенация строк, скорее всего, приведет к ошибкам перевода в процессе локализации.
  • Проверяйте свое интернационализированное приложение на разных этапах разработки, даже до локализации вашего приложения. Просмотрите приложение для обнаружения проблем с Auto Layout и нелокализованными строками. Проверьте его, используя псевдоязыки, смоделируйте языки справа налево, и протестируйте определенные языки и регионы. После импорта локализации проверьте свое приложение на всех поддерживаемых вами языках.
  • Со временем ваше приложение будет расти, и вы будете добавлять дополнительные функции и вносить изменения, а это означает, что вам необходимо постоянно вносить изменения в локализованные версии вашего приложения. Поэтому всякий раз, когда вы планируете какие-либо изменения в своем приложении, вы должны убедиться, что они не повлияют на ваши локализованные версии и что они будут функционировать также.
  • Локализационные файлы имеют тенденцию увеличиваться в размерах и становиться трудно поддерживаемыми: разработчики могут дублировать ключи, уже переведенные строки или забывать удалять пары ключ/значение, если они больше не используются. Для того, чтобы сохранить чистоту и легкость поддержки, можно применить дополнительные средства автоматизации. Например, использовать скрипты для поиска неиспользуемого Swift-кода, которые помогут избавиться от лишних NSLocalizedString.

Заключение

Локализация является важным инструментом для продвижения приложения на многие рынки. Этот процесс требует особого внимания и дополнительных затрат от разработчиков. В этой статье мы рассказали о различии между интернационализацией и локализацией, узнали о механизмах и способах их реализации, а также дали советы, как облегчить эти процессы в приложениях iOS.

В свою очередь наша iOS-команда использует разные подходы для интернационализации и локализации в зависимости от проекта. Но можно выделить основные моменты, которых мы придерживаемся всегда:

  • Обязательно локализуем строки со старта проекта, даже если используется один язык.
  • Отказались от локализации в .storyboard и .xib.
  • Используем Google Spreadsheet для переводов и написали модификацию localize-with-spreadsheet для плюрализации и упрощения взаимодействия с Android.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: