Я создаю приложение, которое будет иметь несколько вариантов.
Эти варианты будут контролироваться несколькими строками в нескольких файлах Localizable.strings.
Однако 90% строк останутся прежними.
Я бы хотел, чтобы каждый из уникальных файлов Localizable.strings импортировал «главный», чтобы мне не приходилось просматривать каждый из файлов вариантов приложения, когда я хочу изменить общую строку.
Это возможно?
Две альтернативы:
Используйте пользовательские функции-оболочки вокруг NSLocalizedString, которые выполняют иерархический поиск за вас, а затем возвращайтесь к механизму NSLocalizedString для случая по умолчанию.
Ранее я написал ответ о том, как это сделать: Файлы ресурсов .strings будут добавлены во время выполнения?
Используйте несколько файлов .strings для каждого языка. По по умолчанию поиск выполняется в "Localizable.strings", но функция NSLocalizedStringFromTable() позволяет указать пользовательское имя "таблицы". Поэтому, если вы передадите «Конфигурация» в качестве имени таблицы, она будет искать информацию в файле «Configuration.strings».
Я работал над приложением, которое делало это. У нас было два разных файла .strings. Один управлял настройками брендинга (какое имя использовать, какие изображения использовать, какие серверы использовать и т. д.), а другой содержал все фактически переведенные строки. В комплекте приложения будет только одна копия информации о брендинге, и мы выбрали правильный вариант для использования во время компиляции с некоторыми пользовательскими скриптами. Это сработало очень хорошо.
К сожалению, Apple не поддерживает это для своих Localizable.strings файлов.
Вы можете имитировать эту функцию с помощью пользовательского сценария Ruby или Python или просто сценария Bash, используя sed; сценарий может взять корневой файл .strings и скопировать его содержимое в файл .strings каждого варианта. Это может быть даже специальный шаг сборки в Xcode.
Я не уверен, что вы хотите, но если вы просто хотите перевести несколько строк, вы можете это сделать.
Можно просто перевести часть этих строк, если перевода нет, ios выберет строки на языке приложения и отобразит. Таким образом, Localizable.strings в языке приложения можно рассматривать как основной.
В ПОРЯДКЕ. Вот что я сделал, чтобы решить эту проблему.
Я удалил различные файлы Localizable.strings из репозитория Git, но оставил их на своих местах (по одному в каждом из каталогов вариантов приложения).
Я взял всего несколько строк, которые различались в каждом варианте, и разбил их на отдельный текстовый файл под названием «MyLocalizable.strings». Я добавил каждый из них в Git и добавил их в проект, БЕЗ СВЯЗИ ИХ С ЦЕЛЬЮ. Я оставил файл Localizable.strings, связанный с каждой целью.
Итак, что у нас есть, так это то, что каждая цель имеет файл Localizable.strings, который связан с целью и будет скопирован в пакет. В каждом целевом каталоге есть файл с именем «MyLocalizable.strings», который содержит только несколько строк, которые различаются от целевого объекта к целевому.
Затем я взял подавляющее большинство строк — те, которые не изменяются — и поместил их в другой файл с именем «MyLocalizable.strings» и поместил его в центральный (общий) каталог. Опять же, я добавил это в Git и в проект, НЕ СВЯЗЫВАЯ ЭТО С ЦЕЛЬЮ.
Затем я написал очень маленький жалкий Perl-скрипт для создания файла Localizable.strings в заданной цели из общего файла с добавлением файла, специфичного для цели. При этом существующий файл Localizable.strings перезаписывается. Это означает, что файл Localizable.strings является новым для каждого запуска скрипта. Этот скрипт был размещен в общей зоне и добавлен в проект БЕЗ СВЯЗИ ЕГО С ЦЕЛЬЮ. Сценарий имеет один аргумент, который является именем цели (и ее каталога). Синтаксис этого скрипта:
#!/usr/bin/perl
use strict; # I'm anal. What can I say?
use Cwd; # We'll be operating on the working directory.
use File::Path;
my $input1File = cwd()."/BMLT/Supporting\ Files/en.lproj/MyLocalizable.strings";
my $input2File = cwd()."/".$ARGV[0]."/en.lproj/MyLocalizable.strings";
my $outputFile = cwd()."/".$ARGV[0]."/en.lproj/Localizable.strings";
open ( MAIN_FILE, $input1File ) || die ( "Could not open main file!" );
my @file_data = <MAIN_FILE>;
close ( MAIN_FILE );
open ( PRODUCT_FILE, $input2File ) || die ( "Could not open product file!" );
push ( @file_data, <PRODUCT_FILE> );
close ( PRODUCT_FILE );
open ( FINAL_FILE, ">$outputFile" ) || die ( "Could not open destination file!" );
foreach ( @file_data ) print FINAL_FILE $_;
close ( FINAL_FILE );
Затем я добавляю шаг сборки Run Script ПЕРЕД шагом Copy Bundle Resources. Этот сценарий вызывает сценарий Perl со следующим синтаксисом:
${PROJECT_DIR}/BMLT/Supporting\ Files/buildLocalizationFile.pl ${PRODUCT_NAME}
Когда сборка сделана, файлы объединяются, и объединенный файл помещается в пакет.
Создайте один Localizable.strings для всех целей с общими строками. Также создайте TargetSpecificLocalizable.strings для каждой цели и поместите в нее строки, специфичные для цели. Затем для общих строк используйте
NSLocalizedString("sample string", comment: "")
и для целевых строк используйте
NSLocalizedString("sample string", tableName: "TargetSpecificLocalizable", bundle: Bundle.main, value: "", comment: "")
