Безопасно ли использовать «настоящие» ключи в NSLocalizedString ()? Есть ли гарантированный запасной язык?

Question

Я знаю, что многие разработчики просто делают это так: они начинают разрабатывать свое приложение на английском языке и ставят NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...") вместо простого @"Tap this to do that!".

Затем они запускают genstrings, который каким-то образом создает файл Localizable.strings, извлекая все эти строки. Грязная часть: длинный текст, используемый в коде, становится ключевым. Оно работает. До одного дня, когда вы быстро зайдете в свой код и измените английскую строку и забудете о локализации и о том, что она служит ключом для всех этих файлов Localizable.strings.

Так что я склонен использовать «настоящие» ключи, которые не перепутаны со строками. Для быстрого тестирования я создал проект, локализованный на английский и французский языки. Затем я установил язык симулятора на немецкий. Потому что, вы знаете, было бы ужасно плохо, если бы пользователь когда-либо увидел ключ вроде TTTDT.

Итак, имея только английский и немецкий языки, я запустил демонстрационное приложение. И то, что я получил, было английским текстом из английского файла Localizable.strings.

Вывод: Похоже, что NSLocalizedString возвращается к английскому файлу, если приложение не поддерживает язык ОС.

Вопрос: При условии, что всегда есть файл Localizable.strings (English), и ключи В нем находятся вместе с правильно отформатированными значениями. Существуют ли обстоятельства, при которых NSLocalizedString завершится с ошибкой, а затем отобразит ключ напрямую?

Answer 1

Чтобы ответить на ваш вопрос: да, у меня возникла проблема, о которой вы беспокоитесь, то есть имена ключей были обнаружены, хотя файл localizable.strings присутствовал и включал записи для этих имен ключей. Это происходит, когда в вашем проекте более одного localizable.strings файла. Что может легко случиться, если вы добавите в ваш проект набор файлов из проекта с открытым исходным кодом, который имеет свой собственный localizable.strings (например, ShareKit).

Вот связанный вопрос , в котором обсуждается эта проблема.

Но, по крайней мере, если вы используете имена ключей в стиле ID, вы заметите такую ​​проблему, когда будете тестировать свое приложение на любом языке. Если вы используете в качестве ключей строку на английском языке (или на базовом языке), вы не увидите эту коварную проблему до тех пор, пока не протестируете локализованные версии, и она может легко проскользнуть незамеченной.

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

Answer 2

Мы склонны использовать «настоящие» ключи, но они обычно представляют собой текст на английском языке (или сокращенную форму) и добавляют «Ключ» в конце.Таким образом, это ясно.

Answer 3

Я думаю, что лучший подход (особенно для программистов) может быть:

1) вставьте ТЕХНИЧЕСКИЕ строки в код

2) traslate с специальной функцией удобства

Таким образом:

а) подробнее для нас

б) мы модифицируем ТОЛЬКО локализованную строку в "Localizable.strings"

в) мы можем отправлять простые "Localizable.strings" извне, не сходя с ума, чтобы искать строки в коде и заменяя их, после получения перевода.

d) для добавления языка требуется 2 клика и вставка текста.

e) мы можем сделать ошибки более общими / более мягкими для конечного пользователя:

образец: * * тысяча двадцать-один

"NETWORK_ERROR" = "Ошибка сети";

"NETWORK_ERROR_NO_DATA" = "нет данных. Просьба проверить настройки";

"NETWORK_ERROR_NO_JSON" = "нет данных. Просьба проверить настройки";

Конечный пользователь не может понять ошибку синтаксического анализа 404 или JSON, как это делает Google ..

"Opps ... произошла ошибка сети". (Кодер увидит истинную причину в коде)

и, наконец ... начать РАНЬШЕ локализовать.

удобство f.:

func localized(_ msg: String)->String{
    let s = NSLocalizedString(msg, comment : "")
    return s
}

Answer 4

Я написал некоторый пользовательский код, который фактически проверяет, что все ключи в приложении присутствуют во всех файлах localizable.string.Этот процесс состоял из двух этапов - использование genstrings для создания нового файла локализуемых строк, содержащего все ключи, на которые в данный момент имеются ссылки в источнике.Затем я использовал некоторые API-интерфейсы Objective-C для загрузки в мои существующие localizable.strings файлы и сравнил их все с тем же набором ключей (не больше и не меньше), что и сгенерированным вновь.