訊息翻譯
Fuchsia 本地化提供的首要功能是「訊息」
翻譯工作概念上來說，這讓程式能夠顯示
顯示向使用者顯示的訊息。方法是使用
依據語言代碼區分的格式設定工具。程式需要保留「本地化內容」的「本地化內容偏好設定」儲存位置。在程式執行期間，如果需要以使用者的母語在畫面上顯示「Hello, world!」訊息 (例如，西班牙文會編碼為「es」，代表歐洲西班牙文，而「es-419」則代表美洲使用的西班牙文)，程式可以透過提供抽象 [Lookup] 服務，搭配原始訊息和所需翻譯，查詢翻譯內容。概念上，這會影響程式碼中的一行
符合以下一般模式：
[Lookup].String({locale-ids=["es-419"]}, MSG_Hello_World) ⇒ (yields the translation)
在上述範例中，[Lookup] 可以是任何可呼叫的端點：可能是程式庫公開的函式，也可能是 RPC 輔助程式介面點，可透過網路擷取翻譯內容。此處的「擷取已翻譯的訊息」抽象作業稱為 String，以便與其他可能對型別資料的呼叫 (例如 StringArray 或其他) 有所區別。
請注意，訊息可能會比這更複雜，因此我們通常不希望程式作者直接處理訊息，而是透過訊息 ID 處理。
還有兩點要注意：
- 語言識別碼指定為 Unicode 語言代碼
編號 (因此
範例中的具名參數
locale-ids) 和多個這類語言代碼 ID 可以一次提供這是因為使用者可能不只一個 並依偏好使用語言階層 如此一來，本地化系統就能選擇最適合的訊息 可能會為單一工作階段提供多種語言版本。 - 在程式碼中，訊息不會指定為字串表示的字串。
這些郵件會由專屬訊息 ID 提供。在上述範例中，這個值的名稱為
MSG_Hello_World。雖然不同學派對字串應內部化或外部化有不同的看法，但我們選擇後者。我們的主要原因是保留原始碼 不會有語言問題，這導致翻譯工具鍊 較易於維護，而且還能更輕鬆地大規模翻譯 管理。
上方範例出現了兩個主要問題：
- 在程式設計師選擇的語言中，
[Lookup]服務的具體介面會是什麼樣子？此外， - 翻譯如何將翻譯提供給我的程式，以便提供這些翻譯 使用嗎？
我們會在討論 Lookup API 時依序回答這些問題。