Рабочий процесс локальной синхронизации с использованием Xcode 6, iOS 8, раскадровки и xliff?
Это идеально, что я хотел бы сделать:
- Настройте проект в Xcode, используя базовую локализацию английского языка. В конечном счете, я хочу английский и скажу голландские версии моих
Localizable.strings
и раскадровки
- Внешние строки в коде с
NSLocalizedString
, используя ключи формы fooViewController.barLabel
, прилежно и добавляя правильные комментарии к контексту с каждым ключом
- Добавьте голландскую локализацию в мои файлы раскадровки.
- Отметьте определенные метки в Storyboard как заполнители, которые будут установлены во время выполнения и не требуют переводов.
- Добавить комментарии для ярлыков в раскадровке, которые требуют перевода
- Экспортируйте файл
xliff
"язык разработки" (нажмите "Проект, редактор/экспорт для локализации...", выберите "Только язык разработки" )
- Откройте английский
xliff
файл с помощью инструмента Counterparts или Xliffie или даже веб-сайт
- Добавьте в себя английские переводы рядом с клавишами
fooViewController.barLabel
и заново сохраните en.xliff
- Создайте файл
nl.xliff
из исходного en.xliff
и добавьте голландские переводы
- Импортируйте оба файла
xliff
в Xcode и создайте соответствующие файлы .strings
для голландского и английского языков как для ключей, определенных в коде, так и для тех, что находятся в Storyboard; зафиксировать новые .strings
файлы в моем исходном репозитории
- В какой-то момент после добавления ключей, удаления и изменения в моем источнике и раскадровки, снова экспортируйте "Язык разработки"
en.xliff
в качестве источника истины
- Обновите файлы
en.xliff
и nl.xliff
текущими переводами, выделив инструмент, какие ключи были добавлены или удалены.
- Импортируйте те файлы
xliff
обратно в Xcode, который обновляет файлы .strings
, которые я могу проверить в моем исходном репозитории
Это имеет смысл? Разве это разумно делать? Я так думаю, но это не работает.
Вот проблемы, с которыми я столкнулся:
- Xcode не поддерживает шаг 4 - формат
xliff
может пометить ключ как translate=no
, но не существует способа аннотировать его в Xcode (в идеале, Xcode не будет экспортировать ключи, помеченные как заполнители).
- Xcode не поддерживает шаг 5 - невозможно установить комментарий транслятора для метки. Нет даже способа установить ключ независимо от текста заполнителя, который вы помещаете в ярлык на раскадровке, что является огромной болью, если вы найдете наклейки с надписью Lorem Ipsum полезно при планировании ваших взглядов.
- Когда вы переходите к шагу 10, Xcode жалуется, что в файле
en.xliff
нет целевого языка. Существует способ изменить целевой язык (или, по крайней мере, создать новый файл с целевым языком, установленным на EN
) в Counterparts, но я не смог найти способ сделать это с помощью Xliffie.
- При попытке реэкспорта файла
en.xliff
с обновленными ключами Xcode сказал мне "Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782"
, в каком месте символа я нашел... апостроф. Xcode не может экспортировать файл xliff
, если исходный файл .strings
содержит апостроф. Что в действительности F...?!
- Шаг 12 и 13 стал странным, и я просто не понимаю, что происходит. Оба коллеги и Xliffie заменили мои оригинальные ключи
fooViewController.barLabel
английскими переводами и выглядели так, как будто они пытались сказать мне, что у меня нет английских переводов. При попытке импортировать en.xliff
обратно в Xcode он сказал мне, что у меня не было никаких переводов для всех, кроме новых ключей, и когда я пошел дальше, он уничтожил существующие переводы из файла en.lproj/Localization.strings
.
Это беспорядок.
Перевод ярлыков в раскадровки без возможности вручную устанавливать их ключи, добавлять комментарии переводчика или отмечать определенные метки, поскольку заполнители, не предназначенные для перевода, просто не работают. Мы прибегали к подключению каждой метки к @IBOutlet
и установке ее перевода в viewDidLoad()
с помощью NSLocalizedString
.
Устранение Xcode при попытке экспортировать файл .strings
, содержащий веру апострофа нищих.
Также кажется, что существует основополагающее предположение, что если "язык разработки" в Xcode является английским, тогда разработчики отвечают за перевод на английский язык. Я не могу представить себе контекста вне контекста магазина инди-инди-инди-индие, где это правда.
Наконец, похоже, что мне не хватает чего-то о том, как инструменты, которые я пытался использовать, структурируют их рабочие процессы. Если бы кто-нибудь мог просветить меня, я был бы очень благодарен.
Кто-нибудь смог создать рабочий рабочий процесс локализации, где разработчикам не поручено окончательное редактирование управления над "языком разработки", а файлы .strings
, проверенные в репозитории, являются источником правды?
Ответы
Ответ 1
Мы прибегали к подключению каждой метки к @IBOutlet и установке ее перевода в viewDidLoad() с помощью NSLocalizedString.
Вы делаете это правильно. Шутки в сторону. Оберните свой процесс разработки вокруг него, и вы пойдете куда лучше, чем пытаетесь принять беспорядок, в который превратилась локализация раскадровки.
Он решает pt.4 - вы решаете, что вы положили в Localizable.strings
Он решает pt.5 - комментарии есть по умолчанию, для всего, что вы решили локализовать. Теперь, если честно, XCode7 добавил возможность добавлять примечания к ресурсам. Не используйте его. По какой-то причине, известной только Apple, он недоступен для всех типов ресурсов. Вы не можете аннотировать, например. верхние и нижние колонтитулы стола. Подробнее об этом позже.
Я рекомендую сделать свою собственную упаковку NSBundle.localizedStringForKey
(макрос), которая предоставляет value
. NSLocalizedString
устанавливает value
в пустую строку, по существу, заставляя key
использоваться в качестве резервного содержимого перевода. Из всех уже существующих сомнительных макросов NSLocalizedStringWithDefaultValue
принимает value
, а также все остальные 4 требуемые параметры - не то, что вы хотели бы использовать часто.
Шаг 10 вызван тем, что вы пытаетесь импортировать базовую локализацию - тот факт, что она не имеет никакого значения. Если вы хотите "перевести английский язык" (например, профессиональную коррекцию), вы должны добавить английский как дополнительную автономную локализацию поверх базы. Технически это сводится к свойствам Base xliff, отсутствующим <file target-language>
и <target xml:lang>
. Из-за какого-то странного беспорядка xliff, подобного вашему, я должен был добавить их один раз вручную. Вы не хотите этого делать:)
Re apostrophe glitch: локализация iOS - это нереальный сад чудес, но я уверен, что это не так нереально:) Попробуйте открыть файл в каком-нибудь редакторе вывода шестнадцатеричного кода - то, что XCode-рендеринг может сильно отличаться от того, что действительно делает файл содержит.
- ... даже веб-сайт
Crowdin для нас, и это прекрасно показывает все неправильно с идеей Apple о локализации раскадровки. Переводчикам нужно 3 вещи, чтобы сделать свою работу профессионально: контекст, контекст и контекст. Apple, похоже, думает, что переводчики с радостью установят приложение, поиграют с ним и зададут вопросы, чтобы получить контекст. Потому что по умолчанию в xliff export отсутствует контекст. Теперь с Xcode7 вы можете добавлять заметки, но странно не везде. Даже там, где вы можете, ваша заметка добавляется в конец уже длинной строки <note>
с машинным контекстом - понятной для сопоставления импорта раскадровки, но бесполезной и затрудняющей переводчик. Кроме того, на самом деле переводчик является профессиональным агентством или энтузиастом языка. Даже если вам повезло с должным образом укомплектованным энтузиастом, или вы заплатили премию агентства за получение дополнительной поддержки для клиентов, вы входите в The Hostile Desert Beta Distribution Options. Apple, смешная реинкарнация Testflight, либо потребует от переводчика зарегистрироваться в качестве разработчика Apple, либо дождаться бета-тестирования Apple - в зависимости от того, как рано в жизни приложения вам нужен перевод.
Кстати, мне нравится ваш блог. Иногда мне хочется сбросить мою кислотность и неудовлетворительную усталость, но так и не дошла до вас.