當地語系化
本指南介紹國際化和當地語系化背後的概念，以及如何使用這些概念產生 Xamarin 行動應用程式的指示連結。
如果您想要直接跳到本地化 Xamarin 應用程式的技術詳細數據，請從下列其中一篇平臺特定的作法文章開始：
- 使用 RESX 檔案的 Xamarin.Forms 跨平台當地語系化。
- Xamarin.iOS 原生平台當地語系化。
- Xamarin.Android 原生平台當地語系化。
i18n 和 L10n
國際化是讓您的程式代碼能夠顯示不同的語言，並針對不同的地區設定調整其顯示方式（例如數位和日期格式）。 這也稱為 全球化。
本地化 是後續步驟 – 為每個語言建立資源（例如字串和影像），並將它們與國際化應用程式結合。
國際化通常縮短為 i18n – “i” 與 “n” 之間 18 個字母的速記。 當地語系化同樣縮短為 L10n – 在 “L” 和 “n” 之間有 10 個字母。
概觀
本文件介紹與國際化和當地語系化相關的概念，以及它們如何一般套用至行動應用程式開發。 設計及建置應用程式時，您可能先前已硬式編碼但必須參數化以進行本地化的專案包括：
- 螢幕版面配置和文字
- 圖示、圖形和色彩、
- 視訊和聲音檔案，
- 動態文字和文字格式設定（例如數位、貨幣和日期），
- 從右至左 （RTL） 語言的版面配置變更，以及
- 數據排序。
無論您的應用程式以哪一個行動平臺為目標，這些秘訣都會協助您建置高品質的當地語系化應用程式。
設計考量
建構應用程式，以便將其內容當地語系化稱為國際化。 正確進行國際化不僅僅是允許在運行時間載入不同的語言字串 – 設計良好的應用程式應該允許根據語言和地區設定來變更所有資源（包括影像、音效和視訊），而且可以調整格式和版面配置，以應付不同的大小字元串。
本節討論建置國際化應用程式時要考慮的一些設計考慮。
版面配置和字串長度
中文和日文字串可能非常短 ， 有時一或兩個字元對於輸入字段標籤來說可能足夠有意義。
德文字符串（例如）可能很長;有時候英文的簡短文字在其他語言中會變得很長，要麼被裁剪，要麼意外地重排版面配置。
比較 iOS 主畫面上英文、德文和日文的幾個專案的字串長度：
請注意，英文 設定 （8 個字元） 需要 13 個字元的德文翻譯，但日文中只有 2 個字元。
當標籤長度可能會有很大的差異時，顯示標籤和輸入字段並排的版面配置很難使用。 卷標通常會在欄位上方顯示的版面配置更容易當地語系化，因為標籤和輸入都可使用螢幕的完整寬度。
一般規則是，如果您要建置固定版面配置（特別是並存元素），則允許至少比卷標和文字所需的英文字符串寬 50%。 這無法解決每個問題，但會提供可在許多情況下運作的緩衝區。
輸入驗證
在撰寫驗證規則時，請注意假設事項。 可能需要至少三個字元的英文文字欄位輸入，這似乎有效，因為單一字母很少具有任何意義。 不過，在中文和日文中，單一字元可能是有效的輸入，而且驗證訊息「至少需要 3 個字元」對這些語言沒有意義。
其他看似簡單的工作，例如驗證電子郵件地址或網站 URL 會隨著字元而變得更加複雜，不限於 ASCII 子集。
以國際化撰寫驗證規則 – 選擇最不嚴格的規則，或撰寫邏輯，讓每個語言的運作方式不同。
影像和色彩
並非所有影像都需要根據用戶的語言選擇來變更。 許多圖示或相片都適合所有使用者，不管他們說話的語言為何。 不過，有些資源適合當地語系化，例如：
- 描繪人員或特定位置的影像 – 如果應用程式顯示當地人員/位置，則應用程式可能會覺得與使用者更相關。
- 圖示 – 某些圖示可以是特定文化特性，您可以藉由當地語系化影像來反映本機理解，讓您的應用程式更容易使用。
- 色彩 – 某些文化特性會以不同的方式瞭解色彩 – 紅色可能表示某個區域中的警告，但另一個區域有好運氣。 在設計應用程式時，請洽詢原生說話者，以判斷是否應該建置將色彩本地化的機制。
影片和音效
在本地化應用程式時，視訊和音效會呈現特殊挑戰，因為雖然翻譯字元串相當容易，但錄製多個配音軌或視訊剪輯可能既昂貴又困難。
視訊和聲音檔案的多個復本也可能大幅增加應用程式的大小（特別是如果您當地語系化成大量語言或有許多媒體檔案）。 您可能只考慮在使用者安裝應用程式之後下載必要的語言資產，但這也可能會導致網路緩慢的用戶體驗不佳。
解決當地語系化問題的方式通常有很多種– 最重要的事情是先考慮這些問題，並確保您的應用程式是設計來照顧它們。
日期、時間、數位和貨幣
如果您使用 .NET 格式函式，請記得指定文化特性，以便正確剖析小數分隔符（並避免擲回轉換例外狀況）。 例如，1.99 和 1,99 都是根據地區設定的有效十進位表示法。
當數據來自已知的來源時（亦即，來自您自己的程式代碼或您控制的 Web 服務），您可以硬式編碼符合格式設定的文化特性識別碼，例如適用於標準英文格式設定的 InvariantCulture。
double.Parse("1,999.99", CultureInfo.InvariantCulture);
如果應用程式使用者正在輸入資料，請使用反映其地區設定的 CultureInfo 實例來剖析資料：
double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));
如需詳細資訊，請參閱剖析數值字串和剖析日期和時間字元串 MSDN 文章。
由右至左 （RTL） 語言
某些語言，例如阿拉伯文、希伯來文和烏爾杜語（例如），是從右至左讀取。 支援這些語言的應用程式應該使用適合由右至左閱讀程式使用的螢幕設計，例如：
- 文字應靠右對齊。
- 標籤應該會顯示在輸入欄位的右邊。
- 默認按鈕放置通常會反轉。
- 使用方向進行內容的階層式瀏覽和動畫（以及其他流覽隱喻和動畫）也應該反轉。
iOS 和 Android 都支援由右至左的版面配置和字型轉譯，內建功能可協助進行上述調整。 Xamarin.Forms 目前並不會自動支援 RTL 轉譯。
排序
不同的語言會以不同的方式定義其字母的排序順序，即使它們使用相同的字元集也一樣。
如需語言 （CultureInfo） 會影響排序順序的範例，請參閱 .NET Framework 中使用字串最佳做法中的字元串比較詳細數據。
行動平臺上的內建資料庫功能不太可能支持語言特定的排序順序，因此您可能需要在商業規則中實作其他程序代碼。
文字搜尋
請務必以多種語言撰寫及測試搜尋演算法。 需要考慮的事項包括：
- 自動完成 – 如果您已建置自動完成函式，請確定其會提供與使用者語言相關的建議。
- 比對查詢與數據 – 搜尋以特定語言輸入的查詢，是否只會針對以該語言撰寫的內容執行，或針對您應用程式中的所有內容執行？
- 字幹分析 – 如果您的搜尋是為了搜尋類似單字、字根和其他搜尋優化而建置的，這些優化是否為您所支援的所有語言所建置？
- 排序 – 請確定結果已正確排序（請參閱上方）。
來自外部來源的數據
許多應用程式會從外部來源、Twitter 和 RSS 摘要下載數據到天氣、新聞或股價。 向使用者顯示此專案時，您必須考慮將不相關或無法讀取資訊的畫面顯示給他們的可能性。
您可以使用幾個策略來嘗試，並確保您的應用程式顯示與使用者相關的資料：
- 不同的來源 – 您的應用程式可能會根據使用者的語言或地區設定，從不同的來源下載數據。 地區設定新聞、天氣和股價可能比從 北美洲 摘要下載的東西更有意義。
- 本地化的顯示 – 如果您要顯示 Twitter 或相片摘要，則應該以自己的語言顯示元數據（例如所花費的時間），即使內容本身維持在原始語言中也一樣。
- 翻譯 – 您可以在應用程式中建置翻譯選項，以執行連入資料的機器翻譯。 這可能是自動的，或在使用者的裁量權 – 只要確保通知使用者是否發生此情況，因為機器翻譯永遠不會完美！
這也可能會影響音訊播放軌或視訊的外部連結 – 設計應用程式時，請務必事先規劃來源翻譯的內容，或確保使用者介面在內容不會以其語言呈現時充分通知使用者。
不要過度翻譯
應用程式中的某些字串可能不需要翻譯，或至少需要翻譯人員特別注意。 範例可能包括：
- URL – 如果您列出 URL，它可能或可能不需要依語言調整。 例如，facebook.com 不需要在主要網站上自動偵測語言的翻譯。 其他網站有地區設定特定的內容，您可能想要提供不同的 URL，例如 yahoo.com 與 yahoo.fr 或 yahoo.it。
- 電話號碼 - 特別是那些具有不同國家/地區代碼或號碼的來電者使用特定語言的電話號碼。
- 聯繫人詳細數據 – 位址和其他資訊可能會因語言或地區設定而有所不同。
- 商標和產品名稱 – 某些字串不需要翻譯，因為它們一律以相同語言撰寫。
最後，如果某些字串需要特殊處理，請務必包含翻譯工具的詳細指示。
格式化文字
行動應用程式通常不會有問題，因為字串通常不是格式豐富的。 不過，如果您的應用程式中需要 RTF 文字（例如粗體或斜體格式設定），請確定翻譯工具知道如何輸入格式設定，您的字串檔案會正確儲存，並且會在向用戶顯示之前正確格式化（例如，不要不小心將格式代碼本身呈現給使用者）。
翻譯 提示
翻譯應用程式所使用的字串會被視為當地語系化程式的一部分。 此工作通常會外包給翻譯服務，並由可能不知道您應用程式或您業務的多語系員工執行。
下列秘訣可協助您產生更容易正確翻譯的字串，進而改善當地語系化應用程式的品質。
本地化完整的字串，而不是單字
有時候開發人員會嘗試指定單一單字或句子 『snippets』，以便在整個應用程式中重複使用它們。 例如，針對文字「您有 5 則訊息」，他們可能會指定下列字串進行翻譯
不正確：
"You have"
"no"
"message"
"messages"
然後嘗試使用字串串連在程式代碼中建立正確的片語：
不正確：
"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"
不建議這樣做 ，因為它不一定適用於所有語言，而且很難讓翻譯人員瞭解每個簡短區段的內容。 這也會導致重新使用翻譯的字串，這可能會導致稍後在不同內容中使用它們時發生問題（然後更新）。
允許參數重新排序
某些程式設計語言需要額外的語法來指定字串中的參數順序，不過 .NET 已經支援編號佔位符的概念，因此
良好：
"a {0} b {1} cde {3}"
可以翻譯下列內容（其中佔位元的位置和順序已變更）
"{2} {3} f g h {0}"
和令牌會依翻譯工具的用途排序。 請務必在將字串傳送至翻譯工具時，包含每個佔位元所包含的說明。
使用多個字串進行基數
避免字串，例如 "You have {0} message/s." 針對每個狀態使用特定字串，以提供更佳的用戶體驗：
良好：
"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."
您必須在應用程式中撰寫程式代碼，以評估要顯示的數位，然後選擇適當的字串。 某些平臺（包括 iOS 和 Android）具有內建功能，可根據目前語言/地區設定的喜好設定，自動選擇最佳的復數位符串。
允許性別
以拉丁文為基礎的語言有時會根據主題的性別使用不同的單字。 如果您的 app 知道性別，您應該允許翻譯的字串反映這一點。
即使在英文中，字串也會更明顯地參考您應用程式的特定人員或使用者。 例如，某些網站會顯示類似 的 "Bob commented on his post" 訊息，因此您需要男性、女性和非二進位或未知性別的字串：
良好：
"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"
不要重複使用字串
或者更準確地說，不要只因為字串本身有不同的用途或意義而重複使用字元串。
例如：假設您在應用程式中有開啟/關閉開關，而切換控件需要當地語系化 'on' 和 'off' 的文字。 您也可以在文字標籤的應用程式中顯示該設定的值。 您應該針對切換顯示使用不同的字串與參數的狀態（即使它們與您預設語言中的字串相同），例如：
- “On” – 顯示在交換器本身
- “Off” – 顯示在開關本身
- “On” – 顯示在標籤中
- “Off” – 顯示在標籤中
這可為翻譯工具提供最大的彈性：
- 基於設計理由，切換本身可能會使用小寫 「on」 和 「off」，但顯示標籤會使用大寫 「On」 和 「Off」。
- 有些語言可能需要縮寫參數值，以符合使用者介面控件，而完整（翻譯）字組可以出現在標籤中。
- 或者，對於某些語言，切換的轉譯可能會使用 「I」 和 「O」 來熟悉文化特性，但您可能仍希望標籤讀取 「開啟」或「關閉」。
翻譯服務
機器翻譯
若要在應用程式中建置翻譯功能，請考慮 Azure 翻譯工具 文字 API。
為了進行測試，您可以使用許多在線翻譯工具之一，在開發期間在應用程式中包含一些本地化的文字：
還有其他許多可用專案。 機器翻譯的品質通常不足以釋出應用程式，而不需要先由專業翻譯人員或原生說話者進行檢閱和測試。
專業翻譯
此外，還有專業的翻譯服務會採用您的字串，並將其散發給自己的翻譯人員，為您提供完成的翻譯費用。
最著名的服務之一是 LionBridge。 大部分的專業服務都支援所有常見的檔類型，包括字串、XML、RESX 和 POT/PO。
摘要
本文介紹一些概念，您應該先熟悉，再將應用程式國際化，然後當地語系化您的資源，並涵蓋如何變更每個平臺的語言喜好設定。
這些概念可以套用至 Xamarin 可能的各種平臺特定和跨平臺國際化技術。
繼續閱讀您感興趣的平台技術詳細數據：
- 使用 RESX 檔案的 Xamarin.Forms 跨平台當地語系化。
- Xamarin.iOS 原生平台當地語系化。
- Xamarin.Android 原生平台當地語系化。