OpenL logo

如何在手機應用程式中進行在地化

OpenL Team 3/14/2026

TABLE OF CONTENTS

如果你正在尋找如何本地化一款行動應用程式，你通常不需要「翻譯技巧」。你需要的是一套安全的發佈流程，能夠涵蓋應用程式字串、版面配置、複數規則、右至左語言支援、螢幕截圖，以及商店中繼資料，而不會破壞產品本身。

這就是關鍵的區別：行動應用程式本地化不只是翻譯文字。它是針對每個目標市場調整應用程式、產品頁面，以及品質保證流程。Apple 表示 App Store 已在 175 個地區和 40 種語言提供服務，而 Android 13 則推出了系統層級的每應用程式語言偏好設定。換句話說，兩大平台現在都認為語言選擇是核心產品體驗，而不是事後才考慮的附加功能。

本指南將帶你一步步了解 iOS 和 Android 團隊的實際操作流程。

快速總覽：

  • 將應用程式內本地化與 App Store、Google Play 商店本地化分開處理。
  • 在翻譯任何內容之前，先將字串外部化。
  • 儘早處理複數、變數、日期、貨幣和右至左語言。
  • 在正式上線翻譯前，先用偽語言進行測試。
  • 本地化螢幕截圖和商店素材，不僅僅是描述文字。

行動應用程式本地化實際包含哪些內容

本地化工作通常分為兩個方向。

1. 應用程式內本地化

這是產品本身：

  • 使用者介面字串
  • 錯誤訊息與新手引導文案
  • 日期、時間、數字、貨幣與單位
  • 複數與性別敏感字串
  • 版面擴展與右至左語言行為
  • 含有文字或方向意義的圖片或圖示

Apple 明確建議使用 Xcode、Foundation API、Auto Layout、Unicode 支援、本地化資產目錄，以及方向感知符號，來讓應用程式準備好進軍全球市場。Android 也同樣建議使用地區感知資源、應用程式語言支援，以及 RTL（右至左）感知版面配置，而不是硬編碼文字和位置。

2. 商店列表本地化

這是使用者發現你的應用程式的方式：

  • 應用程式名稱
  • 副標題或簡短描述
  • 完整描述
  • 關鍵字
  • 截圖
  • 應用程式預覽或宣傳影片

請將這些視為獨立的交付項目。一款本地化良好的應用程式，如果產品頁面過於通用、未翻譯或視覺風格與目標市場不符，仍然可能表現不佳。

從國際化開始，而非直接翻譯

翻譯是流程的最後一步，這個流程從結構設計開始。

將字串外部化並保留完整的備援語言檔

在 Android 平台，Google 提醒開發者，預設的 res/values/strings.xml 必須定義應用程式所需的所有字串。如果預設檔案不完整，而裝置運行於未支援的語言環境，應用程式可能無法載入，並顯示錯誤訊息與強制關閉按鈕。因此，當地化的第一步是資源管理，而不是語言選擇。

對於 iOS，Apple 建議將使用者可見的文字與圖片從執行程式碼中分離，讓它們能以資源檔案方式進行當地化。在現代 Apple 工作流程中，字串目錄是 Xcode 15 及以後版本中處理含有複數字串的推薦方式。

實用原則：

  • 絕不要在視圖或控制器中硬編碼 UI 文字
  • 保留一個標準來源語言
  • 確保每個面向使用者的字串都有穩定的鍵值、上下文與備援內容
  • 對於意義不明的字串，加入譯者註解

一個簡單的範例可以讓這個概念更容易理解。

Android 通常會先建立預設的 strings.xml 檔案：

<!-- 結帳畫面主要行動按鈕。請保持簡短。 -->
<string name="checkout_cta">立即付款</string>
<string name="welcome_title">歡迎回來，%1$s</string>

然後你的 UI 會讀取資源，而不是硬編碼英文：

Text(text = stringResource(R.string.checkout_cta))

在 Apple 平台，Xcode 15+ 通常會用字串目錄管理同樣的概念。簡化後的 Localizable.xcstrings 範例可能如下：

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

你不需要記住這個檔案格式。實際操作的重點更簡單：每個使用者可見的字串都需要一個唯一的來源、足夠的翻譯上下文，以及在語言包不完整時的安全備援。

如果你的應用程式也使用結構化語言檔案，我們的2026 年最佳 JSON 翻譯工具指南可以協助你思考自動化流程與格式保留。

若你想要直接針對應用資源檔案的工具，OpenL JSON Translator值得一試。它專為翻譯 .json 檔案設計，不會破壞鍵值或結構，這正是當應用字串儲存在機器可讀的在地化檔案時所需的功能。操作流程很簡單：上傳從你的應用、CMS 或在地化流程匯出的 JSON，選擇目標語言，然後下載結構相同的翻譯 JSON 檔。根據產品頁面，它支援 100 多種語言及最大 50 MB 檔案，對於處理結構化內容的應用在地化團隊來說，是一個實用的初步工具。

支援應用層級語言選擇

使用者越來越期待能夠將應用語言與裝置語言分開設定。

在 Apple 平台上，使用者可以獨立於裝置語言選擇自己偏好的應用語言。在 Android 上，Android 13 新增了集中式應用語言設定，Google 建議啟用自動的每個應用語言支援，或將你的語言選擇器串接到官方 API。

這對實際產品來說非常重要。雙語或多語用戶可能會將手機設置為英文，但在購物、銀行或外送應用程式中偏好使用其他語言。如果你的應用強制使用單一語言模式，還沒談到翻譯品質之前，你就已經製造了阻礙。

使用平台本地化架構

除非你真的有必要，否則不要急於自行開發一套平行的本地化系統。

對多數團隊來說，預設的平台本地化架構已經足夠：

  • iOS：字串目錄、Localizable.strings、.stringsdict、Foundation 格式化工具、Auto Layout
  • Android：res/values/、特定語言資源資料夾、LocaleConfig、setApplicationLocales()、supportsRtl

自訂本地化基礎建設在極大規模下才有意義，但會增加營運負擔。先從原生系統開始，只有在真正遇到痛點時再擴充。

本地化那些多數團隊容易忽略的部分

團隊常常只翻譯看得見的句子，卻忽略了周邊的產品機制。

複數、變數與文法

複數規則並非全球通用。Unicode CLDR 複數規則定義了像是 zero、one、two、few、many、other 等類別，不同語言會用到不同的子集。Apple 指出，在舊版 .stringsdict 工作流程中，other 是唯一必須的類別，但如果省略語言特有的類別，仍然可能產生文法錯誤的結果。Android 和 iOS 都依賴能辨識語言環境的複數處理，這是有原因的。

這正是天真機器翻譯容易出錯的地方：

  • 英文的 1 file 和 2 files 很簡單
  • 斯拉夫語系常常需要超過兩種複數形式
  • 有些語言會連同名詞、動詞或周邊詞一起變化

千萬不要用拼接片段的方式來製作複數 UI，例如 "You have " + count + " messages"。請使用平台的複數資源。

以下是各平台的最基本做法。

Android：

<plurals name="files_remaining">
  <item quantity="one">%1$d 個檔案剩餘</item>
  <item quantity="other">%1$d 個檔案剩餘</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS 舊版 .stringsdict 範例：

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d 個檔案剩餘</string>
      <key>other</key>
      <string>%d 個檔案剩餘</string>
    </dict>
  </dict>
</dict>
</plist>

在 Xcode 15 及之後的版本，Apple 建議改用 string catalogs 處理複數型態，但原則不變：提供平台一個訊息模式，讓系統自動選擇正確的語言形式。

若需更深入的工作流程規範（例如佔位符與結構化字串），請參考 如何翻譯技術文件而不破壞程式碼。

日期、數字、貨幣與單位

Apple 明確建議使用 Foundation API 來格式化日期、長度、重量、價格與貨幣符號，以因應不同地區。Android 亦同：請用支援地區的 API 格式化資料，避免硬編標點、十進位符號或單位順序。

常見錯誤包括：

  • 03/04/2026 在不同地區代表不同日期
  • 對非美元市場硬編美元符號
  • 1,234.56 在使用逗號作為小數點的地區顯示錯誤
  • 度量單位顯示為錯誤的系統

如果你的 App 涉及排程、帳單、配送時段或分析，這些都屬於在地化的範疇，而非單純美化。

版面擴展與右至左語言支援

英文通常較為精簡。德文則會變得更長。阿拉伯文和希伯來文則會反轉閱讀方向。一個在英文下看起來很正常的版面，在其他語言地區可能會嚴重崩壞。

Apple 建議在導入真正翻譯之前，先用偽語言進行測試，包括右至左偽語言和雙倍長度偽語言。Android 則建議使用 start 和 end 取代 left 和 right，啟用 android:supportsRtl="true"，並在裝置上用 Force RTL 測試 RTL 版面。

你的檢查清單很簡單：

  • 允許按鈕和標籤自動增長
  • 避免重要 UI 使用固定寬度的文字容器
  • 在適當情況下鏡像方向性 UI
  • 在 RTL 下檢查圖示、箭頭、進度流程和輪播
  • 測試混合方向文字，例如阿拉伯語 UI 搭配拉丁字母產品名稱或優惠碼

圖片、圖示、螢幕截圖與影片

Apple 的本地化指引強調了一個許多團隊容易忽略的重點：圖片也可以本地化。這包括圖片集、符號集，以及自訂符號的方向性。如果你的螢幕截圖包含英文 UI、橫幅上的英文文字，或左至右的箭頭，那麼這張截圖本身就沒有本地化。

這對於新手引導畫面、教學卡片和 App Store 資產尤其重要。使用者不會把「行銷視覺」和「產品語言」分開看，他們會一次性評價整體體驗。

App Store 與 Google Play 頁面需分別本地化

許多團隊即使在應用內做得很好，卻在這裡失去安裝機會。

App Store 須提前規劃的要求

Apple 建議在 App Store Connect 中在地化元資料，包括應用程式描述、關鍵字、App 預覽影片和螢幕截圖。Apple 也表示，你可以在產品頁面上展示最多 10 張螢幕截圖，並且針對每種支援的裝置尺寸和語言，最多可提供 3 支 App 預覽影片。App 預覽影片最長可達 30 秒，而當沒有預覽影片時，螢幕截圖就更為重要，因為前 1 到 3 張螢幕截圖可能會出現在搜尋結果中。

這有兩個重要意涵：

  1. 你的首張螢幕截圖不只是說明文件，更是提升曝光度的資產。
  2. 你應該針對重點市場在地化螢幕截圖和預覽影片，而不是到處都重複使用英文素材。

Google Play 上架規範規劃重點

Google Play 也將商店頁面在地化視為一項獨立流程。Play Console 允許你新增在地語言的文字、螢幕截圖和圖像素材。如果你只新增文字翻譯，卻沒有對應語言的圖像素材，Google 表示預設語言的視覺素材仍會顯示。

Google 也提醒，如果你沒有自行新增商店頁面的翻譯，使用者可能會看到自動翻譯的內容，並附有自動產生的提示。這雖然可作為備案，但並不是強而有力的市場進入策略。

一個特別相關的現有功能：Play Console 表示它可以持續使用 Gemini 模型免費翻譯應用程式字串。更具體地說，Google 指出這項功能適用於上傳至草稿版本的 app bundle 中 strings.xml 的應用程式字串，並且你可以在內建模擬器中預覽生成的翻譯，然後再發布。這是一種加速初步覆蓋率的強大方式，但對於關鍵流程仍應由人工審核把關。

建立發佈與品質檢測流程

良好的本地化流程重點不是翻譯速度，而是減少意外狀況。

步驟一：謹慎選擇目標語言地區

不要一開始就「翻譯成 20 種語言」。

請先考慮：

  • 目前的下載組合
  • 積極支援的國家
  • 金流、法律與客服覆蓋範圍
  • 是否能同時本地化應用程式與商店頁面

完整支援一個市場，通常比半吊子支援五個市場更有效。

步驟二：製作本地化準備資產

在翻譯開始前，請先凍結並準備：

  • 有上下文的原始字串
  • 按語言地區分類的截圖清單
  • 詞彙表與產品名稱規則
  • 佔位符規則
  • 商店文案的字數限制指引
  • 各語言地區的審核負責人

如果應用程式使用多個儲存庫或多種檔案格式，請及早統一命名與抽取方式。

步驟三：先用偽本地化測試

在 Apple 平台上，使用雙倍長度與從右到左的偽語言。在 Android 上，測試不支援的語言地區、強制 RTL 及應用程式語言設定。這能發現：

  • 按鈕被截斷
  • 標題被裁切
  • 文字被隱藏
  • 對齊錯誤
  • 未本地化的字串
  • 硬編碼的左右假設

這是成本最低的品質檢測方式之一。

步驟四：在真實裝置上進行語言品質檢測

翻譯完成後：

  • 測試每個目標語言的關鍵流程
  • 比較系統語言與應用程式語言的行為
  • 驗證複數規則與佔位符
  • 檢查付款、日期與地址
  • 審查在地市場的螢幕截圖與商店頁面

如果有錯誤影響到新手引導、結帳、身份驗證或通知，請將其視為發佈阻斷問題。

首次在地化衝刺檢查清單

如果這是你第一次正式推出在地化，請將衝刺範圍縮小，確保能夠順利完成：

  • 只選擇 1 個目標地區，不要一次選 10 個。
  • 為一個發佈分支凍結原始字串。
  • 匯出所有新手引導、結帳、帳號與通知相關字串，並附上上下文註解。
  • 擷取你想要在 App Store 和 Google Play 在地化的螢幕截圖。
  • 在送出正式文本給翻譯人員前，先進行一次偽本地化測試。
  • 在同一個衝刺中翻譯應用程式字串與商店頁面文案。
  • 匯入翻譯後，於 iOS 和 Android 上測試應用程式語言切換。
  • 在真實裝置上 QA 前五大用戶流程。
  • 更新同一地區的螢幕截圖、應用程式預覽與商店中繼資料。
  • 先發佈到 TestFlight 或內部測試通道，然後密切關注客服單與崩潰報告。

這份檢查清單刻意保持精簡。專注於一個地區，打造乾淨的應用程式體驗並同步商店資產，會比同時在多個市場倉促上線學到更多。

真實案例

上述核心觀念並非理論。

DoorDash 將翻譯視為平台級問題來解決

2022年，DoorDash 表示已經在四種語言中翻譯了超過一百萬條字串，並將新語言的上線流程從需數小時開發人員努力縮短為一分鐘內的一條指令。值得注意的不僅僅是規模，更是結構：DoorDash 將靜態與動態字串分開管理，加入詞彙表與風格指南支援，並設置防護措施，避免未翻譯字串漏出。

在 2026 年 2 月 2 日的 DoorDash 部落格文章中，公司表示其重建的上線平台現已支援所有 DoorDash 市場的註冊流程，並能快速推動國際市場的無縫在地化。這正是成熟在地化的典範：可重複利用的工作流程、區域彈性，以及減少臨時修補。

Meta 將在地化視為語言問題與應用程式容量問題

Meta 表示，約有 57% 的 Facebook Android 用戶與 49% 的 Facebook iOS 用戶使用非英語語言版本。在同一篇文章中，Meta 指出移除內建翻譯檔案後，iOS 應用程式節省了最多 16.6 MB，Android 則能新增近十種語言而不增加應用程式容量。

這個經驗對小型團隊也很有啟發：在地化會帶來工程層面的影響。它不僅影響文案撰寫，還會影響二進位檔案大小、執行時載入、翻譯傳遞與發佈機制。

發佈前最終檢查清單

請用這份清單做最後確認：

  • 所有用戶可見的字串皆已外部化。
  • 預設備援資源已完整。
  • 複數型與佔位符皆採用平台原生的在地化支援。
  • 日期、時間、數字、貨幣與單位皆具備地區感知能力。
  • 已測試 RTL 版面配置及混合方向文字。
  • 應用程式商店頁面文案已針對目標市場在地化。
  • 截圖與預覽已針對優先語言在地化。
  • 應用程式內語言選擇功能於 iOS 與 Android 上皆可正常運作。
  • 語言品質檢測已涵蓋最重要的用戶操作流程。

最後想法

最簡單理解行動應用程式在地化的方法就是：翻譯產品、在地化體驗、測試發佈版本。

如果你是第一次進行這項工作，不必一開始就追求全球全覆蓋。選擇一到兩個策略性地區，同步在地化應用程式與商店頁面，進行嚴謹的品質檢測，並從實際用戶行為中學習。如果你已經在管理資源檔案與開發者相關內容，建議搭配閱讀如何翻譯技術文件又不破壞程式碼及2026 年最佳 JSON 翻譯工具推薦。

如果這週只能做一件事，請這樣做：選擇 1 個地區，執行 1 次偽在地化測試，並在 App Store 或 Google Play 上在地化 1 個對應的應用程式頁面。這三步測試，比同時翻譯二十個地區更能反映你的準備狀況。

如果你需要快速初稿來處理應用程式文案、截圖或結構化語言檔案，可以先用自動化工具加速草稿產出，再於發佈前保留人工品質檢查步驟。這正是守護用戶信任、避免「只翻譯未真正在地化」上線的關鍵。

參考資料

Tags

i18n how to
Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp

Related Posts

如何為全球市場翻譯 Amazon 商品頁面

如何為全球市場翻譯 Amazon 商品頁面

了解如何依照亞馬遜自身規則翻譯亞馬遜商品頁，包括標題政策、品牌分析、A+內容，以及上架前的品質檢查。

2026/3/24
如何翻譯出生證明

如何翻譯出生證明

逐步指南，教你如何翻譯出生證明以用於移民、簽證申請及法律用途——包括各國對認證翻譯的要求，以及常見被拒原因。

2026/3/6
如何翻譯學位證書

如何翻譯學位證書

需要認證的文憑翻譯以用於移民、升學或海外就業嗎？本文將介紹認證、公證及國際認證（Apostille）的運作方式，並提供各國規定及避免被拒的實用建議。

2026/1/25