語言和語言代碼解析總覽
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
從 Android 7.0 (API 級別 24) 開始,Android 為多語言使用者提供進階支援,使用者就能在設定中選取多個語言代碼。為提供這項功能,Android 大幅增加支援的語言代碼數量,並改變系統解析資源的方式。
本文件一開始介紹 Android 7.0 (API 級別 24) 以下版本的資源解析策略,接著闡述 Android 7.0 中更完善的資源解析策略,最後說明如何善用擴增的語言代碼數量,支援更多的多語言使用者。
解析語言資源的難題
在 Android 7.0 之前,Android 有時無法提供相符的應用程式和系統語言代碼。
舉例來說,假設您遇到以下情況:
- 應用程式的預設語言是
en_US
(美式英文),同時也在 es_ES
資源檔案中提供本地化的西班牙文字串。
- 裝置設定為
es_MX
。
Java 程式碼要參照字串時,即使應用程式在 es_ES
中提供本地化的西班牙文資源,系統仍會從預設 (en_US
) 資源檔案載入字串。這是因為系統找不到完全相符的項目時,會捨棄語言代碼中的國家/地區代碼,持續尋找可用資源。最後,如果找不到相符項目,系統會改回採用預設值,也就是 en_US
。
如果使用者選擇應用程式完全不支援的語言 (例如法文),系統也會採用預設值 en_US
。例如:
表 1. 沒有完全相符語言代碼時的資源解析狀況。
使用者設定 |
應用程式資源 |
資源解析 |
fr_CH |
預設值 (en)
de_DE
es_ES
fr_FR
it_IT
|
嘗試 fr_CH => 失敗
嘗試 fr => 失敗
使用預設值 (en)
|
在本例中,系統會顯示英文字串,但不知使用者能否理解英文。如今這種行為相當常見。
改進資源解析策略
Android 7.0 (API 級別 24) 提供更強大的資源解析能力,可自動尋找更理想的備用資源。但是,為加快解析速度並方便維護,您應將資源存放在最常用的父項方言中。舉例來說,如果之前是在 values-es-rUS
目錄中存放西班牙文資源,請移至包含拉丁美洲西班牙文的 values-b+es+419
目錄。同樣地,如果資源字串位於名為 values-en-rGB
的目錄,請將目錄重新命名為 values-b+en+001
(國際英文),因為 en-GB
字串的最常用父項是 en-001
。以下範例說明這些做法為何能提升資源解析的效能和可靠性。
資源解析範例
如果使用 Android 7.0 以上版本,表 1 所述案例會有不同的解析方式:
表 2. 沒有完全相符語言代碼時更完善的解析策略。
使用者設定 |
應用程式資源 |
資源解析 |
- fr_CH
|
預設值 (en)
de_DE
es_ES
fr_FR
it_IT
|
嘗試 fr_CH => 失敗
嘗試 fr => 失敗
嘗試 fr 的子項 => fr_FR
使用 fr_FR
|
現在使用者可取得法文資源,而非英文資源。此範例也說明為何在 Android 7.0 以上版本,應將法文字串存放在 fr
,而非 fr_FR
。這麼做的行動方針是比對最接近的父項方言,讓解析速度更快且更能預測。
除了這套更完善的解析邏輯,Android 現在也提供更多可選擇的使用者語言選項。以下再次嘗試使用上述範例,將義大利文指定為額外的使用者語言,但應用程式不支援法文。
表 3. 應用程式只符合使用者次要偏好語言代碼設定時的資源解析狀況。
使用者設定 |
應用程式資源 |
資源解析 |
- fr_CH
- it_CH
|
預設值 (en)
de_DE
es_ES
it_IT
|
嘗試 fr_CH => 失敗
嘗試 fr => 失敗
嘗試 fr 的子項 => 失敗
嘗試 it_CH => 失敗
嘗試 it => 失敗
嘗試 it 的子項 => it_IT
使用 it_IT
|
即使應用程式並不支援法文,仍會提供使用者能理解的語言。
設計應用程式的其他語言代碼支援功能
您可以使用 Android 提供的工具更輕鬆將應用程式內容本地化,以使用者慣用的語言與他們互動。建議您使用下列技巧設定應用程式,讓應用程式能彈性因應不同的語言和格式慣例。
指定應用程式支援的語言
為確保系統能正確解析語言,請在模組層級 build.gradle
檔案中使用 resConfigs
屬性,指定應用程式支援的語言。
以下程式碼範例說明如何使用 resConfigs
指出支援的語言。在本例中,應用程式同時支援英文和西班牙文。
Groovy
android {
defaultConfig {
...
resConfigs "en", "es"
}
}
Kotlin
android {
defaultConfig {
...
resConfigs("en", "es")
}
}
由於建構系統合併應用程式資源及其依附元件的方式,您必須以這種方式指定支援的語言,才能確保系統正確接收使用者語言設定。
LocaleList API
從 Android 7.0 (API 級別 24) 開始,Android 會公開 LocaleList.getDefault()
API,方便應用程式直接查詢使用者指定的語言清單。您可以使用這個 API 建立更精細的應用程式行為,並對內容顯示方式做出最佳調整。舉例來說,Google 搜尋可根據使用者的設定顯示多種語言的搜尋結果。瀏覽器應用程式可以避免提供使用者慣用語言的網頁翻譯內容,而鍵盤應用程式可以自動啟用所有合適的版面配置。
在 Android 6.0 (API 級別 23) 以下版本,Android 對許多常見語言 (en、es、ar、fr、ru) 只支援一或兩個語言代碼。由於每種語言只有少數變化版本,應用程式不必在資源檔案中,以硬式編碼字串的形式儲存某些數字或日期。然而,Android 擴大支援更多語言代碼後,即使是在單一語言代碼中,日期、時間、貨幣和類似資訊的格式也可能有顯著差異。如果以硬式編碼設定這些格式,可能會讓使用者困惑。因此,針對 Android 7.0 以上版本開發應用程式時,請務必使用格式設定工具,不要將數字和日期字串硬式編碼。
舉例來說,Android 7.0 以上版本支援 27 個阿拉伯文語言代碼。這些語言代碼可以共用大多數資源,但部分語言代碼偏好使用 ASCII 數字,其他則偏好使用原生數字。例如要使用數字變數建立句子 (例如「選擇 4 位數 PIN 碼」) 時,請按照以下方式使用格式設定工具:
format(locale, "Choose a %d-digit PIN", 4)
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Language and locale resolution overview\n\nStarting in Android 7.0 (API level 24),\nAndroid provides enhanced support for multilingual users,\nallowing them to select multiple locales in settings. Android\nprovides this capability by greatly expanding the number of locales supported\nand changing the way the system resolves resources.\n\nThis document starts by explaining the resource resolution strategy in\nversions of Android lower than 7.0 (API level 24). Next, it describes\nthe improved resource resolution strategy in Android 7.0.\nLast, it explains how to take advantage of\nthe expanded number of locales to support more multilingual users.\n\nChallenges in resolving language resources\n------------------------------------------\n\nPrior to Android 7.0, Android could not always successfully\nmatch app and system locales.\n\nFor example, assume that you have the following situation:\n\n- Your app's default language is `en_US` (US English), and it also has Spanish strings localized in `es_ES` resource files.\n- A device is set to `es_MX`\n\nWhen your Java code refers to strings, the system would load\nstrings from the default (`en_US`) resource file, even if the app has\nSpanish resources localized under `es_ES`. This is because when the system\ncannot find an exact match, it continues to look for resources by stripping the\ncountry code off the locale. Finally, if no match is found, the system falls\nback to the default, which is `en_US`.\n\nThe system would also default to `en_US` if the user chose a language that\nthe app didn't support at all, like French. For example:\n\n\n**Table 1.** Resource resolution without an exact locale match.\n\n| User Settings | App Resources | Resource Resolution |\n|---------------|--------------------------------------|-----------------------------------------------------|\n| fr_CH | default (en) de_DE es_ES fr_FR it_IT | Try fr_CH =\\\u003e Fail Try fr =\\\u003e Fail Use default (en) |\n\nIn this example, the system displays English strings without\nknowing whether the user can understand English. This behavior is pretty common\ntoday.\n\nImprovements to resource-resolution strategy\n--------------------------------------------\n\nAndroid 7.0 (API level 24) brings more robust resource resolution, and\nfinds better fallbacks automatically.\nHowever, to speed up resolution and improve\nmaintainability, you should store resources in the most common parent dialect.\nFor example, if you were storing Spanish resources\nin the `values-es-rUS` directory\nbefore, move them into the `values-b+es+419` directory,\nwhich contains Latin American Spanish.\nSimilarly, if you have resource strings in a\ndirectory named `values-en-rGB`, rename\nthe directory to `values-b+en+001` (International\nEnglish), because the most common\nparent for `en-GB` strings is `en-001`.\nThe following examples explain why these practices improve performance and\nreliability of resource resolution.\n\n### Resource resolution examples\n\nWith versions of Android greater than 7.0, the case described in\n**Table 1** is resolved differently:\n\n\n**Table 2.** An improved resolution strategy for when there is no\nexact locale match.\n\n| User Settings | App Resources | Resource Resolution |\n|---------------|--------------------------------------|---------------------------------------------------------------------------|\n| 1. fr_CH | default (en) de_DE es_ES fr_FR it_IT | Try fr_CH =\\\u003e Fail Try fr =\\\u003e Fail Try children of fr =\\\u003e fr_FR Use fr_FR |\n\nNow the user gets French resources instead of English. This example also shows\nwhy you should store French strings in `fr` rather than `fr_FR`\nfor Android 7.0 or higher. Here the course of action is\nto match the closest parent dialect,\nmaking resolution faster and more predictable.\n\nIn addition to this improved resolution logic, Android now offers more\nuser languages to choose from. Let's try the above example again with Italian\nspecified as an additional user language, but without app support for French.\n\n\n**Table 3.** Resource resolution when the app only matches the\nuser's second-preferred locale setting.\n\n| User Settings | App Resources | Resource Resolution |\n|-------------------|--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|\n| 1. fr_CH 2. it_CH | default (en) de_DE es_ES it_IT | Try fr_CH =\\\u003e Fail Try fr =\\\u003e Fail Try children of fr =\\\u003e Fail Try it_CH =\\\u003e Fail Try it =\\\u003e Fail Try children of it =\\\u003e it_IT Use it_IT |\n\n\nThe user still gets a language they understand, even though the app doesn't\nsupport French.\n\nDesigning your app to support additional locales\n------------------------------------------------\n\nAndroid provides tools that make it easier to localize app content and engage users in their\npreferred languages. We recommend using the following techniques to configure your app so it can\naccommodate different languages and formatting conventions, in a scalable way.\n\n### Specify the languages your app supports\n\n\nTo ensure that languages are resolved correctly, specify the languages your app supports using the\n`resConfigs` property in the module-level `build.gradle` file.\n\nThe following code sample shows how to use `resConfigs` to denote languages supported.\nIn this example, the app supports both English and Spanish. \n\n### Groovy\n\n```groovy\nandroid {\n defaultConfig {\n ...\n resConfigs \"en\", \"es\"\n }\n}\n```\n\n### Kotlin\n\n```kotlin\nandroid {\n defaultConfig {\n ...\n resConfigs(\"en\", \"es\")\n }\n}\n```\nDue to the way the build system merges resources from your app and its dependencies, you must specify supported languages in this way to ensure that user language settings are received correctly.\n\n### LocaleList API\n\n\nStarting with Android 7.0 (API level 24), Android exposes the\n`LocaleList.getDefault()` API\nthat lets apps directly query the list of languages a user has specified. This API\nallows you to create more sophisticated\napp behavior and better-optimized display of content. For example, Search\ncan show results in multiple languages based on user's settings. Browser apps\ncan avoid offering to translate pages in a language the user already knows,\nand keyboard apps can auto-enable all appropriate layouts.\n\n### Formatters\n\n\nUp through Android 6.0 (API level 23), Android supported only one or\ntwo locales\nfor many common languages\n(en, es, ar, fr, ru). Because there were only a few variants of each language,\napps could get away with storing some numbers and dates as hard coded strings\nin resource files. However, with Android's broadened set of supported\nlocales, there can be\nsignificant differences in formats for dates, times, currencies, and similar\ninformation even within a single locale. Hard-coding your formats can produce\na confusing experience for end users.\nTherefore, when developing for Android 7.0 or higher versions,\nmake sure to use formatters instead of hard coding numbers and date strings.\n\n\nFor example, Android 7.0 and higher includes support for\n27 Arabic locales. These locales can share most resources,\nbut some prefer ASCII digits, while others prefer native digits. For example,\nwhen you want to create a sentence with a digit variable, such as\n\"Choose a 4 digit pin\", use formatters as shown below: \n\n```\n format(locale, \"Choose a %d-digit PIN\", 4)\n```"]]