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

Я знаю, что многие разработчики делают это так: они начинают разработку своего приложения на английском языке и помещают NSLoclaizedString (@ "Нажмите это, чтобы сделать это ! ", @" Сообщая, что делать ... ") вместо простого @" Нажмите это, чтобы сделать это! ".

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

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

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

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

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