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

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

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

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

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

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

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


ios iphone localization ipad nslocalizedstring
person dontWatchMyProfile    schedule 26.11.2011    source источник

Ответы (4)


arrow_upward
4
arrow_downward

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

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

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

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

person Clafou    schedule 26.11.2011

arrow_upward
1
arrow_downward

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

person zaph    schedule 26.11.2011

arrow_upward
0
arrow_downward

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

person zeroimpl    schedule 27.11.2011

arrow_upward
0
arrow_downward

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

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

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

Этим способом:

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

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

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

г) добавление языка происходит в два клика и вставка текста.

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

образец:

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

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

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

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

«Оппс ... произошла сетевая ошибка». (Кодер увидит настоящую причину в коде)

и наконец ... начать рано локализовать.

удобство f .:

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