Локализация для приложений iPhone - какой у вас подход? - PullRequest
Новая
       11

Локализация для приложений iPhone - какой у вас подход?

9 голосов
/ 31 января 2011

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

Вот мои входные данные:

  1. У меня есть 15 файлов XIB (заполненных множеством выходов IB, которыене синтезируется как свойства, но должен быть локализован).
  2. Скорее всего, мое приложение будет иметь 3-5 языковых версий, но возможно, что в будущем я даже пойду на 10 языках.
  3. В ближайшем будущем я планирую добавить новые цели, которые могут изменить дизайн пользовательского интерфейса (платные / бесплатные версии).

Я вижу два пути, которыми я мог бы пойти:

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

  1. Я боюсь, что с 15 XIB и 3-5 языками это будет ужас обслуживания, который будетвыйди из-под контроля, когда я расширю локализацию до ~ 10 языков и введу новые цели (ужас обслуживания не связан с SCM, я использую git btw).
  2. Мне нужно синхронизировать всеверсии XIB, которые повлияют на больПроцесс ge-запроса.
  3. Я также боюсь, что мой пакет приложений станет большим (в настоящее время XIB используют ~ 1,1 МБ и переводят в ~ 120 КБ файлов NIB).
  4. , когда я решучтобы сделать версию для iPad, число XIB снова будет расти.

Вариант B: выполните локализацию в коде, подключив все необходимые выходы, синтезируя их в свойствах и устанавливая ихНадписи / названия правильно:

  1. Боюсь, что объем памяти моего приложения будет очень большим.Или, учитывая надлежащий mem mgmt, я не должен считать это проблемой?

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

РЕДАКТИРОВАТЬ: Я знаю, что это ibtool может упростить процесс в плане А, но я все еще не убежден в этом.

Ответы [ 2 ]

3 голосов
/ 31 января 2011

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

1 голос
/ 01 февраля 2011

Что ж, я ожидал немного больше отзывов от пользователей SO, но это нормально, так как после некоторых исследований я принял собственное решение отказаться от варианта B и перейти на модифицированную версию варианта A.

Я активно использовал идеи подхода компиляции от Philippe Casgrain .Обычно он использует ibtool для автоматической локализации перьев при сборке.Подход Филиппа пока поддерживает разумное содержание.Все остальные строки, которые я использую в коде, обрабатываются с использованием подхода NSLocalizedString, который довольно легко реализовать в моем случае (только что использовался инструмент genstrings).Единственная проблема, которая может поразить меня в будущем, - это добавление новых целей с различными / измененными макетами пользовательского интерфейса.

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

...