相信從事翻譯工作的您，熟悉這一痛苦，即無論如何猜不出一個特别的字符短語，到底是什麼情況下呈現，在哪裡顯示的；亦或，從事 Web 設計的您，無法體會，不做翻譯的準備，究竟意味着什麼樣的後期修複成本。本文試圖為您分享，Google Chrome 浏覽器的 GUI 翻譯實踐經驗，以其抛磚引玉。

Chrome 的 UI 字符串的屏幕截圖可以為我們的翻譯人員提供更多、更清晰的上下文。屏幕截圖請求占本地化錯誤的至少 5%。

無論語言環境如何，Google 都希望确保 Chrome 中的用戶體驗是最佳的。截屏努力實現這一目标。目标是通過為我們的翻譯人員提供更多、更清晰的上下文來改進 Chrome 的 UI 字符串的翻譯。糟糕的本地化會導緻我們失去用戶的信任，并且在時間和資源方面的修複成本都很高。

什麼時候？當新消息與現有消息匹配時，将重用現有翻譯。我們嚴重依賴重複使用的翻譯來保持我們的本地化成本可控。如果您的字符串需要與具有相同文本的現有字符串區别對待（因為獨特的上下文或長度或大小寫等新限制），請添加含義 meaning 屬性。具有不同含義屬性的消息将單獨翻譯。向現有字符串添加含義 meaning 屬性将觸發重新翻譯。

由于以下原因，含義 meaning 屬性可能指出了消歧的必要性：

• 消息的性質（例如，操作、描述、可訪問性、ID）
• 詞的性質（例如，名詞、形容詞、動詞）。例如，“click”可以根據上下文翻譯成“單擊”或“點擊”。
• 任何約束（例如，長度）
• 任何同音異義消歧
• 不包括：消息的一般上下文（應該在描述屬性中）

方法？在下面的示例中，我們要應用特定的大寫規則，因此我們不能重用現有的翻譯。我們為字符串添加了含義，以便自動翻譯控制台工具消除此字符串的歧義。含義的詳細信息将幫助未來的 Chromium 貢獻者理解相同字符串之間的區别；但是，翻譯人員不會看到該 meaning 屬性：

<message name="IDS_BOOKMARK_BUBBLE_PAGE_BOOKMARKED" meaning="In Title Case for Apple OS" desc="In Title Case: Title of the bubble after bookmarking a page."> Bookmark Added! </message>

為什麼？消息描述是我們的翻譯人員在翻譯 UI 字符串時收到的關鍵上下文。翻譯人員以随機順序孤立地查看每個字符串：他們不知道該字符串與哪個功能相關聯，它可能出現在頁面上的什麼位置，或者它觸發了什麼操作。為項目中的每個字符串添加足夠的上下文可以提高翻譯的速度、準确性和質量，最終提高用戶滿意度。例如，以下代碼：

<message name="IDS_BOOKMARK_BUBBLE_PAGE_BOOKMARKED" desc="In Title Case: Title of the bubble after bookmarking a page."> Bookmark Added! </message>

翻譯者隻會看到：

• “在标題案例中：為頁面添加書簽後的氣泡标題。”
• “已添加書簽！”

方法？在消息描述中添加盡可能多的信息：

• 位置：按鈕、标題、鍊接、下拉菜單等。
• 語法：這是名詞還是動詞？如果是形容詞，它在描述什麼？
• 受衆：目标受衆是誰？
• 因果關系：是什麼導緻此消息出現？将出現的下一條消息是什麼？
• 占位符：占位符是什麼意思？您的占位符可能會顯示哪些值？如果你有多個占位符，它們是否需要以某種方式排列？此消息會替換另一條消息中的占位符嗎？
• 長度：此消息是否必須少于一定數量的字符？（比如手機産品的UI空間有限。）換行應該如何處理？每行有字符限制嗎？

請記住，翻譯人員不會像您一樣了解産品，而且他們從事多個産品和項目。而且，他們不是工程師。因此，請确保描述能夠被更廣泛的受衆理解，并且不包含過多的技術細節。想象一下，将這個描述斷章取義地提供給一個不在你項目中的人，比如你的表弟。他們還會明白嗎？

注意：更改消息描述而不更改消息本身或添加含義屬性不會觸發字符串的重新翻譯。

良好的消息描述示例：

• 源文本：“美國城市或郵編”描述：該消息在電影放映時間位置的空搜索框中顯示為灰色。按國家/地區本地化以命名城市和可選的郵政編碼。評論：此描述清楚地解釋了源文本在 UI 中的顯示位置，并說明了如何針對非美國語言環境調整消息。

• 源文本：“縮放”描述：單擊“縮放”菜單命令會啟動有關如何縮放的幫助。嘗試将翻譯限制為 10 個字符。評論：詳盡的描述說明源文本播放的内容，觸發的内容，并說明字符限制和基本原理。
• 源文本：“帳戶預算增加”描述：該文本是句子“PLACEHOLDER from X to Y”中的占位符注釋：由于字符串隻是句子的一部分，因此該描述提供了有關上下文的基本信息，并提醒譯者注意它将作為較長的 UI 消息的一部分出現。

糟糕的消息描述示例：

• 源文本：“全部”描述：短語“選擇：全部無”中的“全部”一詞評論：良好的直接上下文，但不清楚“全部”指的是什麼。建議描述：出現在短語“Select: All None”中，指的是消息線程。

• 源文本：“PLACEHOLDER from X to Y”描述：描述帳戶預算更改評論：尚不清楚占位符的用途。建議描述：描述賬戶預算變化；PLACEHOLDER 是“賬戶預算增加”或“賬戶預算減少”之一；X 和 Y 都是美元金額。

• 源文本：“我們無法發送您的消息。外星人吃了它。請在幾分鐘後重試。”描述：一個有趣的錯誤信息。評論：譯者會按字面意思翻譯信息，所以如果他們有創意，信息描述應該讓他們知道。此外，“外星人”在文化上可能不合适。更好的描述：一條錯誤消息。由于幽默因文化而異，因此請對錯誤使用适當的翻譯。它不一定是直接翻譯。