アプリ内の言語切り替えを、端末の言語設定と切り離して実装する — Android Per-App Language の実装メモ

後方互換のための autoStoreLocales 設定

API 33 未満でも setApplicationLocales を効かせるには、AppCompat が選んだ言語をどこに保存するかを指定します。一番手軽なのは自動保存を有効にする方法です。マニフェストに次のメタデータとサービスを追加します。

<!-- AndroidManifest.xml の <application> 内 -->
<service
    android:name="androidx.appcompat.app.AppLocalesMetadataHolderService"
    android:enabled="false"
    android:exported="false">
    <meta-data
        android:name="autoStoreLocales"
        android:value="true" />
</service>

autoStoreLocales を true にすると、API 33 未満では AppCompat が内部の保存先に言語を覚え、起動時に自動で復元します。API 33 以降では OS が保持するので、この設定は無視されます。つまり同じコードのまま、新旧どちらの端末でも動きます。

この自動保存にはわずかなコストがあります。AppCompat は最初の Activity が立ち上がる前に保存済みロケールを読み込むため、コールドスタートにごく短い同期 I/O が乗ります。私の手元の計測では、Pixel 6a で数ミリ秒程度で、体感には影響しませんでした。自前で保存先を管理したい場合は autoStoreLocales を使わず、起動時に明示的に setApplicationLocales を呼ぶ実装に切り替えられます。

言語を切り替える 1 行と、設定画面への導線

実際の切り替えは 1 行です。ユーザーが言語を選んだら、その言語タグを LocaleListCompat に包んで渡します。

import androidx.appcompat.app.AppCompatDelegate
import androidx.core.os.LocaleListCompat
 
fun applyAppLanguage(languageTag: String) {
    // 例: "ja" / "en" / "zh-Hans"。空文字でシステム既定に戻す
    val locales = if (languageTag.isEmpty()) {
        LocaleListCompat.getEmptyLocaleList()
    } else {
        LocaleListCompat.forLanguageTags(languageTag)
    }
    AppCompatDelegate.setApplicationLocales(locales)
}

「端末の言語に従う」へ戻す選択肢を必ず用意してください。getEmptyLocaleList() を渡すとシステム既定に戻ります。これがないと、一度日本語を選んだユーザーが端末を英語に変えてもアプリだけ日本語のまま、という取り残しが起きます。

API 33 以降では、自前の設定画面を持たずに OS の言語設定へ飛ばす導線も用意できます。Settings.ACTION_APP_LOCALE_SETTINGS のインテントで、システム側のアプリ言語画面を直接開けます。アプリ内 UI と OS 設定のどちらを主にするかは方針次第ですが、私はアプリ内に切り替えを置きつつ、OS 設定への導線も補助的に添えるようにしています。

切り替えた瞬間のちらつきと、二重再生成

setApplicationLocales を呼ぶと、Activity が再生成されて新しい言語で描き直されます。ここで二つの現象に出会いました。

一つ目は、呼び出し方によって Activity が二回再生成されることです。設定画面の中で言語を選んでそのまま recreate() も呼ぶと、API がトリガーする再生成と自前の再生成が重なります。setApplicationLocales を呼んだら、自前の recreate() は呼ばないでください。再描画は API に任せます。

二つ目は、再生成の瞬間に一瞬だけ前の言語の画面が見えることがある点です。これは設定ダイアログを閉じてから言語を当てると目立ちにくくなります。私はダイアログの dismiss を先に行い、わずかに遅延させてから setApplicationLocales を呼ぶようにして、視覚的なちらつきを抑えました。

// 言語選択ダイアログ内
fun onLanguageSelected(tag: String) {
    dismiss() // 先にダイアログを閉じる
    view?.post {
        applyAppLanguage(tag) // 次フレームで適用すると切り替えが滑らかになる
    }
}

ライブラリやリソースがアプリ言語に追従しないとき

切り替え自体は効いているのに、一部だけ端末言語のまま、という相談が一番多いです。原因はだいたい次のどれかでした。

まず、Context を取り違えているケースです。文字列を読むときに applicationContext から取得していると、Activity のロケールではなくアプリ全体のベースを参照してしまうことがあります。表示に使う文字列は、その画面の Activity／Fragment の Context から取得してください。

次に、WebView です。WebView 内のコンテンツは Android のリソース言語とは別系統で、Accept-Language ヘッダや読み込む URL のロケールに依存します。アプリ言語に合わせたいなら、現在の AppCompatDelegate.getApplicationLocales() から言語タグを取り出し、読み込み時に明示的に渡す必要があります。

そして AdMob などの広告 SDK です。広告のクリエイティブ言語は、原則として端末の言語やユーザーの推定地域に基づくため、アプリ内言語の切り替えには追従しません。これは仕様で、無理に合わせようとするより、UI 文言（同意バナーの自前部分など）だけアプリ言語に合わせ、広告本体は SDK に委ねる、と割り切るのが現実的でした。下の表は、私が切り分けに使っているチェック順です。

エージェントに任せた範囲と、人が握った範囲

この実装で Antigravity のエージェントに任せたのは、locales_config.xml の雛形生成、対応言語タグとリソースフォルダの対応表づくり、そして「API 33 未満で setApplicationLocales を動かす最小構成」の下調べでした。雛形が一通り出てくるので、最初の方向決めがとても速くなります。

一方で、二重再生成のような実機でしか分からない挙動、AdMob の追従を諦めるという製品判断、そして「端末既定に戻す」選択肢を必ず置くという仕様は、人が握るべき部分でした。エージェントは正しく動くコードを書いてくれますが、ユーザーが取り残される導線かどうかは、自分のアプリの読者を思い浮かべながら決める必要があります。実機を一台、言語を切り替えながら触ってみる時間が、結局いちばん確実だと感じています。

公開しているアプリに言語切り替えを足すと、レビューやメールの言語が少しずつ変わっていくのが分かります。小さな機能ですが、届く相手が広がる手応えのある実装でした。同じように多言語のアプリを育てている方の参考になれば幸いです。