在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)文件，並且文件中的按鍵ARE以及格式正確的值。有沒有情況下NSLocalizedString會失敗，然後直接顯示密鑰？

Answer 1

要回答您的問題：是的，我遇到了您擔心的問題，即即使存在localizable.strings文件並且包含這些鍵名稱的條目，鍵名也顯示出來。當您的項目中有多個localizable.strings文件時會發生這種情況。如果您將一組具有自己的localizable.strings（例如ShareKit）的開放源代碼項目中的文件放入您的項目中，這很容易發生。

Here is a related question討論這個問題。

但是至少如果你使用ID風格的鍵名，當你用任何語言測試你的應用時，你都會注意到這樣的問題。如果您使用英文（或基本語言）字符串作爲鍵，那麼在測試本地化版本之前，您將不會看到這個隱蔽的問題，並且可能更容易被忽視。

因此，在重寫文本時必須記住更新密鑰（所有語言）的問題上，存在使用英文文本作爲密鑰時可能隱藏錯誤的問題（英文看起來不錯，但本地化版本不會）。因此，在我看來，使用「真實」鍵名而不是實際文本更實用。如果您仍然擔心由於某種原因可能出現密鑰名稱，請選擇一個至少足夠描述性的密鑰以便理解。

Answer 2

我們傾向於使用「真實」鍵，但它們通常是英文文本（或縮寫形式），並在末尾添加「鍵」。這種方式很明顯。

Answer 3

我寫了一些自定義代碼，它實際驗證應用程序中的所有鍵都出現在所有localizable.string文件中。這個過程有兩個步驟 - 使用genstrings生成一個新的可本地化的字符串文件，其中包含源中當前引用的所有鍵。然後我使用了一些Objective-C API來加載我現有的localizable.strings文件，並比較它們都具有與新生成的完全相同的一組鍵（不多也不少）。