原文地址
當進行應用本地化時贮配，總容易搞砸半火。蘋果提供的工具，友好地說是缺乏一致性错沃。特別是當你更新代碼并且更新本地化內容栅组，工作就變得麻煩。我不想深入解釋否則這篇文章就結束不了了捎废。相比較我更愿意提供解決的辦法笑窜。
如果想了解相關背景和我方法的先決條件就繼續(xù)讀下去。當然你也可以直接看解決方案登疗。
很幸運的排截，蘋果已經決定在應用的開發(fā)過程當中納入基于XLIFF的本地化。XLIFF 是一種定義良好的把所有本地化字符打包到一個文件中的本地化交換格式辐益。使用了 XLIFF 工具断傲，Mac 和 iOS 應用程序的本地化是直截了當?shù)摹＿@篇文章里智政，我想展示一種基于 XLIFF 的 (相當) 簡單的本地化方法认罩。
為了能夠本地化您的應用程序，你必須把代碼中所有出現(xiàn)在用戶界面中的字符串封裝進 NSLocalizedString pragmas续捂。所以垦垂，例如，從@"No Internet connection" 得到NSLocalizedString(@"noInternetConnection", @"No Internet connection”)
NSLocalizedString的使用是它自己的一個主題牙瓢。通常劫拗，第一個參數(shù)是在應用程序中出現(xiàn)的實際字符串，第二個參數(shù)包含一個注釋comments矾克。不過页慷，我會說，目前在大多數(shù)情況下胁附，第一個參數(shù)被作為關鍵（key）酒繁，第二個參數(shù)作為基礎語言的默認值（在整個這篇文章中，基礎語言將是英語）控妻。這種方法的背景是州袒，默認值可能會改變，如果你把默認值用在第一個參數(shù)饼暑，并有其他的翻譯稳析，這種變化會破壞其他的翻譯洗做，第一個參數(shù)被用來作為一個字符串的翻譯的關鍵弓叛。這種方法的缺點是彰居，你還必須提供你的基本語言的翻譯。
第二種被翻譯的文件是storyboard和NIB 文件基本上撰筷，你不必做任何事情來促進他們的本地化陈惰。這些文件中的字符串將自動識別。

解決方法

所以毕籽，讓我們假設你已經把你所有的字符串都封裝進了NSLocalizedString pragmas并且想本地化你的應用抬闯。這意味著我們現(xiàn)在要創(chuàng)建XLIFF文件并之后進行翻譯。其實关筒，Xcode允許創(chuàng)建（和更新Ｈ芪铡）基于stroyboards，你代碼中的NSLocalizedStrings和已經存在的本地化資源的XLIFF文件蒸播。但是睡榆，Xcode不允許導出的基礎語言的XLIFF文件。它允許導出一個空XLIFF文件但是一旦你創(chuàng)建和翻譯這個XLIFF袍榆，你就不能導出這個包括現(xiàn)有翻譯的XLIFF文件胀屿。所以，我不討論如何導出XLIFF文件（你會在這里找到一個好的教程包雀，如果你喜歡）宿崭，我將采用以下在這里發(fā)現(xiàn)的每一種語言都需要的創(chuàng)建或更新的命令行命令：
<pre><code> xcodebuild -exportLocalizations -localizationPath -project [[-exportLanguage ]]</code></pre>
對于英語XLIFF文件的創(chuàng)建的一個例子是 ：
<pre><code>
xcodebuild -exportLocalizations -localizationPath . -project "North Kiteboarding.xcodeproj" -exportLanguage en</code></pre>
在這個例子中，命令執(zhí)行在North Kiteboarding.xcodeproj所在的目錄才写。執(zhí)行此命令后葡兑，將創(chuàng)建一個包含了NSLocalizedStrings，storyboard和NIB文件里面的本地化字符串赞草，并且名字為en.xliff的文件.
如果你沒有提供以前的英文本地化內容讹堤，它只包含第一個參數(shù)（key）和第二個參數(shù)（comments），而不是實際的翻譯房资。（順便說一句蜕劝，為英語翻譯，你可以只復制comments到目標領域轰异。）但是（這與以前的方法有很大的差異）岖沛，如果你已經提供了一個翻譯，現(xiàn)有的翻譯將被包含在XLIFF文件搭独。所以現(xiàn)在你（或一個翻譯機構）可以開始添加缺少的信息婴削。
盡管你可以使用一個文本編輯器，但還是可以使用一系列可供XLIFF翻譯的工具牙肝。我使用的工具 iXLIFF是我花了0.99€(譯者：目前軟妹幣18)在App Store上買的唉俗。使用這個工具嗤朴，翻譯看起來如下：