language-agnostic - 您項目的國際化




6 Answers

已經有一段時間了,所以這並不全面。

字符集

Unicode很棒,但你無法忽略其他字符集。 Windows XP(英語)上的默認字符集是Cp1252。 在網絡上,你不知道瀏覽器會發送給你什麼(雖然希望你的容器能夠處理大部分內容)。 當您使用的任何實現中存在錯誤時,不要感到驚訝。 當字符集移動到機器之間時,它們可以與文件名進行有趣的交互。

翻譯字符串

一般來說,譯者不是編碼員。 如果您將源文件發送給翻譯者,他們將破壞它。 應將字符串提取到資源文件(例如Java中的屬性文件或Visual C ++中的資源DLL)。 譯者應該獲得難以打破的文件和不會讓他們破壞的工具。

翻譯人員不知道產品中字符串的來源。 沒有上下文很難翻譯字符串。 如果您不提供指導,翻譯質量將受到影響。

在上下文的主題上,您可能會多次出現相同的字符串“foo”,並認為讓UI中的所有實例指向同一資源會更有效。 這是一個壞主意。 在某些語言中,單詞可能對語境非常敏感。

翻譯字符串需要花錢。 如果您發布新版本的產品,則恢復舊版本是有意義的。 有工具從舊資源文件中恢復字符串。

字符串連接和字符串的手動操作應該最小化。 使用適用的格式函數。

翻譯人員需要能夠修改熱鍵。 Ctrl + P是英文打印; 德國人使用Ctrl + D.

如果您的翻譯過程需要有人隨時手動剪切和粘貼字符串,那麼您就會遇到麻煩。

日期,時間,日曆,貨幣,數字格式,時區

這些都可能因國家而異。 逗號可用於表示小數位。 時間可能是24小時的表示法。 不是每個人都使用格里高利歷。 你也需要明確無誤。 如果您注意在您的網站上顯示美國的MM / DD / YYYY日期和英國的DD / MM / YYYY日期,除非用戶知道您已完成日期,否則日期不明確。

特別是貨幣

類庫中提供的Locale函數將為您提供本地貨幣符號,但您不能只在一個以美元計算價格的值前面加上一英鎊(英鎊)或歐元符號。

用戶界面

佈局應該是動態的。 不僅字符串在翻譯時可能會翻倍,整個UI可能需要反轉(希伯來語;阿拉伯語),以便控件從右向左運行。 那是在我們到達亞洲之前。

翻譯前的測試

  • 使用代碼的靜態分析來查找問題。 至少,利用IDE中內置的工具。 (Eclipse用戶可以轉到Window> Preferences> Java> Compiler> Errors / Warnings並檢查非外化字符串。)
  • 通過模擬翻譯進行煙霧測試。 解析資源文件並用偽翻譯版本替換字符串並加上長度加倍並插入時髦字符並不困難。 您不必說一種語言來使用外部操作系統。 現代系統應該允許您以具有翻譯字符串和外部語言環境的外國用戶身份登錄。 如果您熟悉您的操作系統,您可以在不知道該語言的單個單詞的情況下弄清楚什麼是什麼。
  • 鍵盤映射和字符集引用非常有用。
  • 虛擬化在這裡非常有用。

非技術問題

有時你必須對文化差異敏感(可能導致進攻或不理解)。 您經常看到的一個錯誤是使用標誌作為選擇網站語言或地理位置的視覺提示。 除非你希望你的軟件在全球政治中宣佈各方,否則這是一個壞主意。 如果你是法國人並且提供英國聖喬治國旗的選項(英格蘭國旗是白色領域的紅十字會),這可能會導致許多說英語的人感到困惑 - 假設外語和國家會出現類似的問題。 圖標需要經過審查才能具有文化相關性。 豎起大拇指或綠色勾號是什麼意思? 語言應該是相對中立的 - 在一個地區以特定方式對待用戶可能是可以接受的,但在另一個地區則被認為是粗魯的。

資源

C ++和Java程序員可能會發現ICU網站很有用: http://www.icu-project.org/http://www.icu-project.org/

您是如何在已經參與的實際項目中實施國際化(i18n)的?

在我閱讀了Joel的著名文章之後,我開始興趣地製作軟件跨文化, 絕對最低限,每個軟件開發人員絕對必須知道Unicode和字符集(沒有藉口!) 。 但是,我還沒有能夠在一個真實的項目中利用它,除了確保我盡可能使用Unicode字符串。 但是將所有字符串設置為Unicode並確保您了解編碼所有內容的編碼只是i18n冰山的一小部分。

到目前為止,我所做的一切都是由一群受控制的美國英語人士使用,或者在推動項目實施之前我們沒有時間去做。 因此,我正在尋找人們在實際項目中使軟件更加本地化的任何提示或戰爭故事。




我曾為我以前使用.NET的雇主開發過一個項目,並且我們使用了內置的.resx格式。 我們基本上有一個文件,其中包含.resx文件中的所有翻譯,然後是具有不同翻譯的多個文件。 這樣做的結果是,您必須非常勤奮地確保應用程序中可見的所有字符串都存儲在.resx中,並且無論何時更改,您都必須更新所支持的所有語言。

如果您變得懶惰並且沒有通知負責翻譯的人員,或者您沒有通過本地化系統嵌入字符串,那麼稍後嘗試修復它將是一場噩夢。 同樣,如果本地化是事後的想法,那麼就很難實施。 最重要的是,如果您沒有將所有可見字符串存儲在標準位置的外部,則很難找到所有需要本地化的字符串。

另外一點,非常嚴格地避免直接連接可見字符串,例如

String message = "The " + item + " is on sale!";

相反,你必須使用類似的東西

String message = String.Format("The {0} is on sale!", item);

這樣做的原因是不同的語言經常以不同的方式對單詞進行排序,並且直接連接字符串將需要一個新的構建來修復,但是如果你使用上面的某種字符串替換機制,你可以修改你的.resx文件(或任何本地化您使用的文件)用於需要重新排序單詞的特定語言。




除了以前的所有技巧之外,請記住,這不僅僅是為了改變其他語言中的等價詞,特別是對於從右到左書寫的非拉丁語字母(韓語,阿拉伯語),因此整個用戶界面必須符合,如

  • 第1項
  • 第2項
  • 第3項

必須是

阿拉伯語文本1 -

阿拉伯語文本2 -

阿拉伯文3 -

(反向子彈列表似乎不起作用:P)

如果您的系統必須在用戶更改所使用的語言後以動態方式應用更改,則可能是UI噩夢。

另一個非常困難的事情是測試不同的語言,不僅僅是為了正確的單詞,但由於像韓語這樣的語言通常會為其字符設置更大的字體類型,這可能導致語言特定的錯誤(如按鈕上的“保存”文本大於某些語言的按鈕本身)。




我認為從事國際化工作的每個人都應該熟悉Common Locale Data Repository,它現在是Unicode的子項目:

公共區域設置數據存儲庫

那些人正在努力為各種i18n問題建立一個標準資源:貨幣,地理名稱,大量的東西。 任何保持自己的核心本地數據的項目,鑑於該項目存在,是相當瘋狂的,恕我直言。




另一個挑戰是接受用戶的意見。 在許多情況下,這可以通過操作系統提供的輸入處理來緩解,例如Windows中的IME,它與常見的文本小部件透明地工作,但是這種工具不能滿足所有可能的需要。




沒有人提到過的一件事就是字符串中有一些不同的部分,如“單位將在5天內到達”或“週一有事情發生”。 其中5和星期一將根據州改變。 將它們分成兩部分並將它們連接起來並不是一個好主意。 只有一個不同的部分和良好的文檔,你可能會逃脫它,有兩個不同的部分,將有一些語言,優先改變它們的順序。




Related