Должны ли расширения приложения иметь свои собственные Localizable.strings?

В настоящее время используется Xcode 6.3

В нашем (с открытым исходным кодом) приложении у нас есть две цели:

  • Наше основное приложение «Клиент»
  • Расширение действия «ShareTo»

Обе цели имеют локализованные строки через NSLocalizedString().

Когда я «Экспорт для локализации», я вижу одно расширение <file> в экспортированном файле XLIFF с именем Client/Localizable.strings, которое содержит строки как для основного приложения, так и для расширения приложения.

Те же результаты при экспорте из командной строки через xcodebuild.

Я абсолютно уверен, что это поведение экспорта со временем изменилось: раньше строки из расширения приложения заканчивались отдельной записью Extensions/ShareTo/Localizable.strings в файле XLIFF. Не объединены в Client/Localizable.strings.

Итак, теперь мне интересно, это новое и правильное поведение? Означает ли это, что строки поиска расширений приложений находятся в родительском пакете?


person Stefan Arentz    schedule 11.04.2015    source источник


Ответы (1)


Это действительно не имеет значения. Если Xcode нравится один, вы можете объединить оба файла вместе.
В более крупных проектах вместо одного Localizable.strings мы будем использовать несколько файлов .strings, по одному для каждого класса или один для каждого класса, назначенного для определенного класса с использованием NSLocalizedStringFromTable();
Просто убедитесь, что файл строк скопирован. к обоим пакетам (проверьте инспектор файлов, первая вкладка правой боковой панели).

person Schemetrical    schedule 11.04.2015
comment
Спасибо за Ваш ответ. Добавление одного Client/Localizable.strings к обеим целям является обходным путем, но на самом деле не является решением IMO. - person Stefan Arentz; 11.04.2015
comment
@StefanArentz, вы всегда можете разделить его, если вам это не нравится, и использовать NSLocalizedStringFromTable();. Это не обходной путь, во многих случаях строки являются общими для целей, потому что многие строки одинаковы. - person Schemetrical; 11.04.2015