Привет, Хабр!

В недавней статье наш коллега Дмитрий Марущенко yojick рассказал о том, как доставлять динамические обновления переводов с сервера на мобильные устройства. В продолжение темы сегодня поговорим о том, как мы используем эти обновлённые переводы в наших приложениях.

Исторически сложилось, что все основные мобильные платформы «из коробки» обладают превосходной поддержкой локализации сообщений. В iOS, Android и Windows Phone приложение можно локализовать без всяких трудностей. Все средства для этого уже встроены в IDE: просто укажите нужный язык в списке поддерживаемых локализаций, введите текст на этом языке — и всё остальное за вас сделает IDE. Работает как часы. Но у этого подхода всё же есть недостатки.

Нашли в тексте ошибку? Хотите что-то перефразировать? Вам нравится экспериментировать с разными обращениями к разным целевым группам? Во всех случаях ответ один: придётся пересобирать приложение, снова выкладывать его в магазин, проходить проверку, получать одобрение, публиковать новую версию со всеми изменениями и ждать, чтобы пользователи обновили приложение на своих устройствах. Даже если все процедуры пройдут без заминок, это займёт дни или недели. А если пользователи не захотят обновляться? Или того хуже — не смогут этого сделать по техническим причинам вроде неподдерживаемой ОС? Тогда нежелательный текст в вашем приложении проживет гораздо дольше, чем хотелось бы.

Это довольно неудобно. К счастью, нам удалось решить эту проблему на разных платформах (с учётом особенностей каждой из них). И мы рады поделиться своим решением.

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

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

Процесс можно повторять раз за разом. Клиент всегда будет получать от сервера самую свежую версию локализации. Подход, о котором пойдёт речь далее, мы используем на клиентской стороне во всех мобильных приложениях Badoo. Учитывая все реализованные серверные средства и предполагая, что клиентский код уже имеет доступ к обновлённым локализациям, нам нужно лишь предоставлять компонентам пользовательского интерфейса правильные сообщения. За работу!

iOS

Естественный способ локализации сообщения в iOS заключается в использовании одного из методов семейства NSLocalizedString. Мы создали набор аналогичных методов BPFLocalizedString (префикс BPF означает Badoo Platform Foundation) и используем их по всему приложению. «Под капотом» BPFLocalizedString использует сервис локализации, который содержит все данные и реализует основной функционал. Мы сохраняем все поступающие от сервера обновления в отдельном бандле. Когда клиентский код запрашивает локализованную строку, мы ищем в этом бандле нужное сообщение и при необходимости возвращаемся к дефолтному бандлу локализации.

public func localizedStringForKey(_ key: String) - > String {
  let str = self.localizationsBundle.localizedString(forKey: key)
  return str == key ? Bundle.main.localizedString(forKey: key,
  value: nil, table: nil) : str
}

Этот подход сильно упрощает клиентский код. При этом можно использовать всю тяжёлую локализационную iOS-машинерию, включая поддержку языков с правосторонним начертанием и множественные (plural) локализации. Для этого нам нужно лишь поддерживать внутри дополнительного пакета валидные данные.

Верхнеуровневый API для BPFLocalizedString выглядит так:

NSString * __nonnull BPFLocalizedString(NSString * __nonnull key, NSString * __nullable comment);
public func BPFLocalizedString(_ key: String) - > String {
 return
 BPFGlobals.shared().localizedStringsService.localizedStringForKey(
 key)
}

Его легко использовать как из Objective-C-, так и из Swift-кода.

Есть одна тонкость. Обновления локализации могут приходить в любой момент жизненного цикла клиентского приложения. И при этом мы ещё можем показывать пользователям какие-то «старые» локализованные сообщения. Чтобы сохранять согласованность данных, лучше не смешивать «старые» локализации с «новыми». Эту задачу мы решаем, применяя обновления только при следующем запуске приложения. Такое решение всё упрощает и позволяет клиентскому коду не «думать» о неожиданных случаях.

Какие здесь ограничения? Нужно быть уверенными, что мы везде заменили NSLocalizedString на соответствующие BPFLocalizedString. К счастью, эту задачу можно легко решить с помощью автоматических скриптов. Другим ограничением является невозможность применения BPFLocalizedString напрямую к статично упакованным элементам пользовательского интерфейса (XIB и Storyboard). Это вполне естественное ограничение, поскольку мы заменяем статичную локализацию на динамическую.

Android

В Android локализации упакованы в APK-файл, и в ходе выполнения менять его невозможно. В этой ОС стандартным решением по локализации сообщения является использование Resources. Доступ к Resources является частью интерфейса Context. Resources предоставляет конфигурацию текущего устройства (локейшн, размер экрана, ориентацию и так далее). Одним из решений является замена всех Resources.getString() на нашу собственную кастомную реализацию, как в iOS. Но мы выбрали более элегантный способ.

Что, если можно было бы внедрять свою реализацию Resources вместо системной? К счастью, это возможно! Возьмём класс Activity, напишем его наследника и везде применим:

public abstract class BaseActivity extends Activity {
  private Resources mResources;
  public Resources getResources() {
   if (mResources == null) {
    Resources r = super.getResources();
    mResources = new ResourceWrapper(this, r);
   }
    return mResources;
  }
}

И сделаем обёртку вокруг стандартного Resources для извлечения обновлённых значений лексем:

public class ResourceWrapper extends Resources {
 private final Resources mResources;
 private final LexemeProvider mLexemeProvider;
 public ResourceWrapper(Context context, Resources r) {
  super(r.getAssets(), r.getDisplayMetrics(), r.getConfiguration());
  mResources = resources;
  mLexemeProvider = new LexemeProvider(...);
 }
 @Override
 public String getString(@StringRes int id) throws
 NotFoundException{
  String hotString = mLexemeProvider.getString(id);
  if (hotString == null) {
    return mResources.getString(id);
  } else {
    return hotString;
  }
 // Override each method and return corresponding value from
    mResources
 @Override
 public boolean getBoolean(int id) throws NotFoundException {
  return mResources.getBoolean(id);
 }
}

Очевидно, что нужно перехватывать все методы, относящиеся к тексту (getString, getText, getQuantityString, getQuantityText), и возвращать значения, полученные от нашего собственного поставщика локализаций.

Обычно система использует не непосредственно класс Resources, который есть в исходниках Android, а некоего его наследника, поэтому надо пробрасывать все вызовы к ResourceWrapper в эту конкретную реализацию (mResourcesв нашем случае).

Пока что мы имели дело с явными получателями лексем. А что насчёт представлений, «надуваемых» из XML-макетов? Когда вы объявляете атрибут android:text, после своего «надувания» TextView вызывает context.getTheme().obtainStyledAttributes(…).getText(…), чтобы получить соответствующие значения, и в этом случае наша замена для Resources уже не работает.

Нужно и сюда тоже внедрить наш LocalizationProvider.

public class DynamicLexemeInflater {
 private static void applyDynamicLexems(View view, String name,
 Context context, AttributeSet attrs) {
  if (view instanceof TextView) {
   TextView textView = (TextView) view;
   TypedArray typedArray = context.obtainStyledAttributes(attrs,
   new int[] {
    android.R.attr.text, android.R.attr.hint
   });
   int textResourceId = typedArray.getResourceId(0, -1);
   if (textResourceId != -1) {
    String dispatchedString = context.getString(textResourceId);
    textView.setText(dispatchedString);
  }
   int hintResourceId = typedArray.getResourceId(1, -1);
   if (hintResourceId != -1) {
    String dispatchedString = context.getString(hintResourceId);
    textView.setHint(dispatchedString);
   }
   typedArray.recycle();
  }
}

Здесь мы настроили свою фабрику InflaterFactory для добавления «постобработки» «надуваемых» представлений, в которых задаются текстовые значения.

Windows Phone

Как и в iOS с Android, в Windows Phone ресурсы локализации помещены в пакет приложения. Его тоже нельзя изменить в ходе выполнения программы. Наш подход к горячему обновлению локализаций основан на API Windows Phone Silverlight 8.1.

В WP-приложениях мы обычно обращаемся к локализованным сообщениям через генерируемый инструментарием класс AppResources (или можно дать ему любое другое имя), который содержит статические геттеры для всех строк, используемых в приложении. Вот что находится внутри этих геттеров:

public static string ApplicationTitle {
 get {
 return ResourceManager.GetString("ApplicationTitle",
 resourceCulture);
 }
}

Обратите внимание, что здесь используется свойство ResourceManager, определённое как

public static global::System.Resources.ResourceManager
ResourceManager {
 get {
  if (object.ReferenceEquals(resourceMan, null)) {
   global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("PhoneApp.Resources.AppResources", 
typeof (AppResources).Assembly);
   resourceMan = temp;
  }
   return resourceMan;
  }
}

System.Resources.ResourceManager — это центральный компонент API системы локализации, на него ложится весь нелёгкий труд по загрузке актуальных строковых значений. К счастью, в перегруженном методе (overloaded method) у него есть точка расширения:
public virtual string GetString(string name, CultureInfo culture). Именно это нам и нужно для внедрения своей машинерии и для дополнения предоставляемых системой средств. Нужно лишь унаследоваться от этого класса и перегрузить метод GetString:

public class UpdateableResourceManager: ResourceManager {
 public override string GetString(string name, CultureInfo culture)
 {
  var lexemesHandler = _localizationService.GetLexemesHandler(culture);
  return lexemesHandler?.GetLexeme(name)?.Value?.Text ?? base.GetString(name, culture);
 }
}

Теперь нужно использовать наш UpdateableResourceManager вместо того, что по умолчанию используется в классе AppResources. Но поскольку этот класс генерируется автоматически, нужно также получить контроль над генерированием, чтобы добавлять в получающийся файл свои данные. Обычно это делается при каждом открывании файла AppResources в Visual Studio, но можно сделать это и вручную (или автоматически в скрипте) с помощью инструмента RESGen, как в этом примере с PowerShell:

$resgenPath = “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ResGen.exe” & $resgenPath AppResources.resx to_delete.txt “/str:cs,Badoo.Is.Ponies.Namespace,AppResources,AppResources.Designer.cs” / publicclass
Remove — Item “to_delete.txt”

Также нужно заменить строку System.Resources.ResourceManager в нашем Badoo.Next.Big.Thing.UpdateableResourceManager. Остальное обрабатывается в отдельном LocalizationService, отвечающем за всю работу с сетью, сохранение и поиск данных.

Заключение

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

Пётр Колпащиков, iOS-разработчик
Виктор Патрушев, Android-разработчик
Стас Шуша, Windows Phone-разработчик