ローカリゼーションの見直し
AAOはNDMFのLocalizerを使っている
VPMのdependency使いたくないな…
NDMFをガッツリ参考にして作るのが丸いか？
NDMFのLocalizerを使う場合、MAで選択したロケールが使用される
AAOはこのためにNDMFのLocalizerを使っていそう
言語の辞書は共有されないが、選択言語は同一キーのEditorPrefsなので共有される
OSの言語設定を参照せず、初期設定で英語が使用されるのがネック
値が存在しない場合はen-usがLanguageに代入される
LanguageのsetterでEditorPrefsに値がセットされる
InitializeOnLoadMethodで実行されるため、初回起動のタイミングでen-usが書き込まれることになる
EditorPrefsが空のときOSの言語設定を参照、という処理を挟むことができない
代入された値が_curLanguageと同じ場合はEditorPrefsが更新されないため、ユーザーがコンボボックスで言語を選択しない限りEditorPrefsは空のまま
とはいえ、NDMFの言語設定を勝手に変えるのも行儀が悪い感じはするが…
EditorPrefsの値を削除してUnityを再起動すると英語になることを確認
この仕様を嫌う場合は自前でLocalizerを持つことになるが…
初期値セットのPR出してもいい
EditorPrefsにサポート外のロケールがセットされている場合の挙動（th-THで確認）
言語選択のコンボボックスは何も選択されていない状態になる
UI文字は英語にフォールバックされる
NDMFが使用するロケール文字列がCurrentUICultureに準拠しているなら、HasKeyがfalseのときCurrentUICultureをセットしてもいいのでは？
もしくはGetStringのデフォルト値をCurrentUICultureにする
まず、3つのAPIの違いについてだ。GlobalizationPreferences.Languagesプロパティは、上で検証したようにエンドユーザーの設定言語のリストが得られた。残りの2つは、何を取得しているのだろうか？
Unity環境だと使えない？
CultureInfo.CurrentUICultureプロパティは、動作中のアプリの言語だ。これは、実行時に適用されている言語リソースと一致する。
ApplicationLanguages.Languagesプロパティは、エンドユーザーの設定言語のリストの中から、アプリの対応言語を抜き出したリストだ（ただし、設定言語中にマッチする言語がないときはCultureInfo.CurrentUICultureプロパティと同じになる）。
Unity用のAPI
"ja-JP"のようなフォーマットでは取得できない
switchで"ja-JP"のような文字列を返すのがいいか
UnityEditor 環境で実行するとそれぞれ以下の値が取得できました。
Application.systemLanguage: Japanese
CultureInfo.CurrentUICulture: ja-JP
一方で UWP アプリ上で本スクリプトを使って値をチェックすると、日本語環境でも以下のように CurrentUICulture で ja-JP でない値が取得できることがありました。
Application.systemLanguage: Japanese
CultureInfo.CurrentUICulture: en-GB
MAはVRCSDK依存だが、NDMFは依存パッケージが無いのでNDMFに依存するのはアリかも？
anatawaさんのリポジトリにはNDMFが含まれているため、bdさんのリポジトリを登録しなくてもインストールがコケない
これって自動化されてる？
インストールが失敗しなければいいので、NDMFの更新に即時追従する必要はないか…
念のためNDMFのリポジトリをフォークしておく
AAOには韓国語の言語ファイルが存在せず、韓国語を選択すると英語にフォールバックされる
TryGetLocalizedStringで選択言語の辞書が見つからない場合はDefaultLanguageが使用される
AAOの言語選択UIは、NDMFのLanguageSwitcher.DrawImmediateをそのまま使用している
選択中の言語のファイルが存在しない場合、英語が選択されているものとして表示するコンボボックスにしてもいいかも
もしくは、コンボボックスの表示はそのままにして、選択中の言語ファイルが存在しない場合は警告を表示する
言語設定を参照してヘルプのURLを変更
日本語は"ja"
あとはunity標準のローカライゼーションに乗るならUnity Cs Reference見るといいと思います。
assembly definitionの配下にpoファイルを置いて、http://UnityEditor.L10n.Tr("code")するとエディタ指定の言語にローカライズできます
L10nを使う場合、Unityの言語設定が参照される
Unityを英語UIで使っている場合は英語が選択されてしまう
そのあたりを解決しているのがCL4EEやNDMFのLocalizer
MAの言語ファイルはpoではなくjson
ScriptableObjectだとgitでの取り回しが悪いので、jsonの方がいいかも
NDMFはpo
UnityEngine.LocalizationAssetとして読み込めるならpoでもjsonでもいい
ローカリゼーションで外部依存したくない気持ち
VRC非依存環境で表情エディタだけ使われるケース
そんなことある？
大部分コピペしてコード内にライセンス表記する？
でもフォント関連の機能に乗っかりたいな…
2022のUIElementsのフォントがなんか汚い問題
これの「パッチ適用前」みたいな感じになる
使われ方
VisualElementの初期化時に実行する
あとエラーレポートにも乗っかりたいな…
これはビルド時の処理だけなので、根幹から依存するわけではないのでは？
AAOがErrorReportを呼び出している例
ビルド時ではなく適用時のエラーレポートは自前で持ちたいので、コードを読み込んでおく
ビルド時以外にNDMFのレポートウインドウを開けないこともないが、だいぶ目的外の使用なのでやめておく
NDMFのローカリゼーションに乗っからない場合、ビルド時のエラーレポートをローカライズできない
というか、Localizerのインスタンスがないとエラーを渡せない？
辞書の形式を共通にして、ビルド時以外のローカライザは自前で持つのが丸いかも