> Source: https://www.ymotongpoo.com/works/goblog-ja/matchlang/


# Goにおける言語とロケールのマッチング
[Language and Locale Matching in Go](https://blog.golang.org/matchlang) By Marcel van Lohuizen

## はじめに
ウェブサイトのような、ユーザーインターフェースで複数の言語をサポートするアプリケーションを考えてみましょう。
ユーザーが望む言語のリストがある場合、アプリケーションはどの言語を表示すべきか決めなければなりません。
このとき、アプリケーションがサポートする言語とユーザーが好む言語の間で最適な組み合わせを選ばなければなりません。
この記事ではなぜこの決定が難しいか、そしてどうやってGoがそれを手助けできるかを説明します。

## 言語タグ
言語タグ（あるいはロケール識別子）は、使用されている言語や方言をコンピュータが理解できる形にした識別子です。
もっともよく知られたものとしては IETF BCP 47 という標準で、Goのライブラリもこの標準に準じています。
BCP 47 で定義されている言語タグと、それらが表す言語や方言をいくつか例を挙げてみましょう。

| タグ   | 説明        |
|:------|:------------|
|en     |英語         |
|en-US  |アメリカ英語   |
|cmn    |標準中国語    |
|zh     |中国語（通常は標準語）|
|nl     |オランダ語    |
|nl-BE  |フラマン語    |
|es-419 |ラテンアメリカスペイン語|
|az, az-Latn |ともにラテン文字で書かれたアゼルバイジャン語|
|az-Arab |アラビア文字で書かれたアゼルバイジャン語|

言語タグは一般的に言語コード（上記での“en”, “cmn”, “zh”, “nl”, “az”）が来た後に付加的な文字に関する副タグ（“-Arab”）や
地域に関する副タグ（“-US”, “-BE”, “-419”）、バリアント副タグ（オックスフォード英語大辞典でのスペルのための “-oxendict”）、あるいは
拡張副タグ（電話帳順のための “-u-co-phonebk”）が続きます。
副タグが省略された場合には、もっとも一般的な形式が想定されます。たとえば “az” は “az-Latn-AZ” とみなされます。

言語タグがもっとも使われる場所は、システムがサポートしている言語の一覧からユーザーが好みの言語を選択するときでしょう。
たとえば、アフリカーンス語を望むユーザーに対して（アフリカーンス語が選択できない場合には）オランダ語を表示するとシステムが決定する場合です。
このような対応は言語間の相互理解可能性に関するデータを参照するというプロセスが関わってきます。
この対応から得られたタグは、その後言語特有のリソース、例えば翻訳、並び順、タイトルなどの大文字小文字を自動で変えるアルゴリズムを
取得するために使われます。これらの処理はまた別の対応を必要とします。たとえば、ポルトガル語には決まった並び順がないため、
並び順を処理するパッケージはデフォルトのもの、すなわち「ルート」の言語の並び順にフォールバックすることになるでしょう。

## 言語の対応に関する厄介な性質
言語タグを扱うには注意が必要です。その理由としては、自然言語の境界があいまいであることや、言語タグの標準が変遷してきた歴史などが挙げられます。
この節では言語タグを扱う際の厄介な側面をいくつかご紹介します。


### 異なる言語コードのタグが同じ言語を表している

歴史的かつ政治的な理由で、多くの言語コードは時とともに変遷していて、古い言語コードと新しい言語コードが共存していました。
しかし、たとえ両方とも現在使われているコードであっても、同じ言語を参照していることがあります。たとえば、標準中国語を表す公式な言語コードは “cmn” ですが、 “zh” がずっと
広く使われています。 “zh” は公式にはいわゆるマクロ言語として中国語全般を表すために予約されています。
マクロ言語用の言語タグは、しばしばその言語群の中でもっとも良く話されている言語のコードとして使われます。

### 言語コードの対応だけでは不十分

たとえばアゼルバイジャン語（“az”）は国によって異なる文字で書かれています。"az-Latn" はラテン文字（デフォルトの文字体系）、"az-Arab" はアラビア文字、
“az-Cyrl” はキリル文字です。もし “az-Arab” を単純に “az” に置き換えてしまうと、結果としてラテン文字が表示されて、
アラビア文字で書かれたアゼルバイジャン語しか理解できない人には意味のないものになってしまうでしょう。

異なる地域であることも異なる文字が使われる可能性を示唆します。たとえば “zh-TW” と “zh-SG” はそれぞれ繁体字中国語、
簡体字中国語であることを示しています。他の例としては “sr” （セルビア語）はデフォルトではキリル文字ですが、
“sr-RU” （ロシアで書かれるセルビア語）はラテン文字なのです！似た例はキルギスや他の言語でも見られます。

副タグを無視すると、ユーザーにとって意味の分からないものが表示されるかもしれません。

### ユーザーが選択していない言語が最適な場合もある

もっとも普及したノルウェー語（“nb”）は、デンマーク語と見分けが付きません。もしノルウェー語が選択できないのであれば、
デンマーク語が次点として選ばれるべきでしょう。同様に、スイスのドイツ語（“gsw”）を選択したユーザーに
ドイツ語（“de”）が表示されても問題無いでしょう。しかし、その逆はまったく当てはまりません。
ウイグル語を選択したユーザーに対しては英語よりも中国語にフォールバックさせたほうが良いでしょう。
他にも例はたくさんあります。
ユーザーが選択した言語がサポートされていない場合に、必ずしも英語にフォールバックすることが最適ではないのです。

### 翻訳よりも言語の選択の方が重要

あるユーザーがデンマーク語を第1の選択肢に、ドイツ語を第2の選択肢にしたとしましょう。
もしアプリケーションがドイツ語を選択するならば、コンテンツをドイツ語に翻訳するだけではなく、照合処理も（デンマーク語ではなく）ドイツ語の
ルールを使わなければいけません。そうしないと、たとえば動物のリストを並べるときに “Bär” （日：クマ）が “Äffin” （日：メスザル）よりも
前に来てしまいます。

ユーザーが選択した言語の中からサポートする言語を選択するというのは、ハンドシェイクアルゴリズムに似ています。
まずあなたがやり取りするためのプロトコル（言語）を決定し、そのあとはセッションが続く間はすべてのコミュニケーションを
そのプロトコルで行うことに終始します。

### フォールバックに「親」の言語を使うのは簡単なことではない

あなたのアプリケーションがアンゴラのポルトガル語（“pt-AO”）をサポートしているとしましょう。
[golang.org/x/text](http://golang.org/x/text) 内のパッケージでは、この方言に対しての、照合や表示といった、特別なサポートはありません。
そのような状況で採るべき正しい行動は、もっとも近い親の方言に対応させることです。言語は階層的な関係にあり、特定の言語には、
より一般的な親の方言があります。たとえば、“en-GB-oxendict” の親は “en-GB” であり、その親は “en” で、さらにその親は未定義の言語を表す
“und” となります。これはルート言語としても知られています。照合においては、ポルトガル語には特定の並び順がないため、collateパッケージは
ルート言語の並び順を選択するでしょう。displayパッケージでアンゴラのポルトガル語に最も近い親は、ヨーロッパポルトガル語（“pt-PT”）で、
よりわかりやすい “pt” ではありません。こちらはブラジルのポルトガル語を表します。

一般的に、親子関係は簡単ではありません。もう少し例を挙げましょう。 “es-CL” の親は “es-419” で、 “zh-TW” の親は “zh-Hant”、その親は “und” です。
親を選択しようと単純に副タグを取っただけの処理をすると、ユーザーが理解できない「方言」を選択してしまうかもしれません。

## Goでの言語のマッチング

Goのパッケージ [golang.org/x/text/language](http://golang.org/x/text/language) は言語タグに関するBCP 47の標準を実装し、
共通ロケールデータレポジトリ（CLDR）にあるデータに基づいて、どの言語を使うべきかを判断するサポートを追加しています。

ユーザーが選択した言語を、アプリケーションがサポートする言語に対応させるサンプルプログラムを示します。

```go
package main

import (
    "fmt"

    "golang.org/x/text/language"
    "golang.org/x/text/language/display"
)

var userPrefs = []language.Tag{
    language.Make("gsw"), // Swiss German
    language.Make("fr"),  // French
}

var serverLangs = []language.Tag{
    language.AmericanEnglish, // en-US fallback
    language.German,          // de
}

var matcher = language.NewMatcher(serverLangs)

func main() {
    tag, index, confidence := matcher.Match(userPrefs...)

    fmt.Printf("best match: %s (%s) index=%d confidence=%v\n",
        display.English.Tags().Name(tag),
        display.Self.Name(tag),
        index, confidence)
    // best match: German (Deutsch) index=1 confidence=High
}
```

## 言語タグを作成する

ユーザーが選択した言語コードの文字列から `language.Tag` を生成するもっとも単純な方法は `language.Make` を使うことです。
これを使うと、不正な形式の入力からであっても意味のある情報を抽出できます。たとえば “en-USD” はたとえ `USD` が不正な副タグ
であっても、“en”の形に直してくれます。

`language.Make` はエラーを返しません。エラーを返したとしてもデフォルト言語を使うのが普通なので、エラーを返さないというのは
より便利な形と言えます。自分でエラーを扱うのであれば `Parse` を使いましょう。

HTTPの `Accept-Language` ヘッダはしばしばユーザーが望む言語を渡す方法として使われます。 `ParseAcceptLanguage` 関数は
そのヘッダをパースして言語タグのスライスへ変換し、望ましい順番に並べます。

デフォルトでは、languageパッケージはタグを正規化しません。たとえば、ある文字体系がその言語の話者の「圧倒的大多数」に使われているのであれば
その文字体系の副タグを省略するという、BCP 47が推奨する規則には従いません。同様に、CLDRの推奨する形も無視します。
つまり “cmn” は “zh” に置換されませんし、“zh-Hant-HK” は “zh-HK” に簡約化されません。言語タグを正規化してしまうと、
ユーザーの意図などの役に立つ情報まで捨ててしまいかねません。かわりに正規化は `Matcher` で扱われます。
プログラマが望めば、正規化に関するオプションもすべて利用できます。

## ユーザーが望む言語をサポートしている言語に対応させる

`Matcher` はユーザーが望む言語をサポートしている言語に対応させます。ユーザーは言語の対応に関するすべてのややこしい事柄に
関わりたくないのであれば、 `Matcher` が選んだ言語を利用することを強く推奨します。

`Match` メソッドはユーザーが望む言語タグを（BCP 47の拡張からなる）ユーザー設定を経由してサポートされている言語タグへと渡します。
それゆえ、`Match` から返されたタグを言語特有のリソースを取得するために使うことが重要です。たとえば “de-u-co-phonebk” は
ドイツ語での電話帳の並び順を要求します。この拡張は対応時には無視されますが、collateパッケージがそれぞれの並び順のバリアントを選択するときに使われます。

`Matcher` はアプリケーションがサポートする言語で初期化されます。これらの言語は通常翻訳先となる言語です。
この言語のセットは通常は固定されていて、これによって `Matcher` がアプリケーション起動時に作成できます。
`Matcher` は初期化のコストを犠牲にして `Match` のパフォーマンスを改善するために最適化されています。

languageパッケージはもっともよく使用される言語タグの事前定義済みセットを提供しています。これはアプリケーションがサポートする言語セットとして
使えます。ユーザーは一般的に、サポートされる言語にピッタリと合致するタグを選ばなければいけないという心配をしなくてすみます。
たとえば、アメリカ英語（“en-US”）は、デフォルトでアメリカ英語となる、より一般的な英語（“en”）と相互互換的に使えます。
`Matcher` にも同様のことが当てはまります。アプリケーション側では両方の言語に対応してもよく、特有のアメリカのスラングを “en-US” 用に追加できます。

## マッチングの例

次の `Matcher` と、サポートする言語のリストを考えてみましょう。

```go
var supported = []language.Tag{
    language.AmericanEnglish,    // en-US: first language is fallback
    language.German,             // de
    language.Dutch,              // nl
    language.Portuguese          // pt (defaults to Brazilian)
    language.EuropeanPortuguese, // pt-pT
    language.Romanian            // ro
    language.Serbian,            // sr (defaults to Cyrillic script)
    language.SerbianLatin,       // sr-Latn
    language.SimplifiedChinese,  // zh-Hans
    language.TraditionalChinese, // zh-Hant
}
var matcher = language.NewMatcher(supported)
```

様々なユーザー設定とそれに対応するサポート言語のリストの対応を見てみましょう。

ユーザー設定で "he"（ヘブライ語）を選択した場合、最適な対応は "en-US"（アメリカ英語）です。
良い対応がないため、matcherはフォールバック先の言語（サポート言語のリストの先頭）を使用します。

ユーザー設定で "hr"（クロアチア語）を選択した場合、最適な対応は "sr-Latn"（ラテン文字で書かれたセルビア語）です。
理由は、同じ文字で書かれている場合、セルビア語とクロアチア語はお互い理解できる言語だからです。

ユーザー設定で "ru, mo"（ロシア語、次点でモルダビア語）を選択した場合、最適な対応は "ro"（ルーマニア語）です。
理由はモルダビア語は正規化すると "ro-MD"（モルドバでのルーマニア語）に分類されるからです。

ユーザー設定で "zh-TW"（台湾での標準中国語）を選択した場合、最適な対応は"zh-Hans"（簡体字で書かれた標準中国語）ではなく、
"zh-Hant"（繁体字で書かれた標準中国語）です。

ユーザー設定で　"af, ar"（アフリカーンス語、次点でアラビア語）を選択した場合、最適な対応は "nl"（オランダ語）です。
どちらの設定も直接はサポートされていませんが、オランダ語は、フォールバック言語の英語の設定された言語に対する近さよりも、
アフリカーンス語にずっと近く対応しています。

ユーザー設定で "pt-AO, id"（アンゴラのポルトガル語、次点でインドネシア語）を選択した場合、最適な対応は "pt-PT"（ヨーロッパのポルトガル語）
であり、 "pt"（ブラジルのポルトガル語）ではありません。

ユーザー設定で "gsw-u-co-phonebk"（スイスのドイツ語で、照合は電話帳の順を使用）を選択した場合、最適な対応は
"de-u-co-phonebk"（ドイツ語で、照合は電話帳の順を使用）となります。ドイツ語はサーバーの言語リスト内ではスイスのドイツ語に最適な対応であり、
電話帳順の照合というオプションは持ち越されます。

## 信頼スコア

Goではルールベースの消去法を使った粗い信頼スコアを使っています。
言語の対応は Exact、High（Exactではないが明確な曖昧さはない）、Low（おおよそ対応しているかもしれないし、していないかもしれない）、Noに
分類されます。複数の言語が対応した場合には、タイブレークのルールが順番に実行されます。同等の対応が複数ある場合には、
最初の言語が返されます。これらの信頼スコアは、たとえば比較的弱い対応を拒否するときに役に立ちます。
ほかにも、たとえば言語タグから最適な地域や文字のスコアを付けるときにも使われます。

他のプログラミング言語での実装では、より細やかな、変数スケールのスコアリングをしています。
私たちは、Goでの実装は粗いスコアリングにすることで、より簡潔な実装で、よりメンテナンスしやすく、より速くなることがわかり、
それにより、より多くのルールを扱えることとなりました。

## サポートされた言語を表示する

[golang.org/x/text/language/display](http://golang.org/x/text/language/display) パッケージは、言語タグの名前を
多数の言語で表示できます。このパッケージには「自分自身」のタグ名を自分の言語で表示できるようにもなっています。

たとえば

```go
    var supported = []language.Tag{
        language.English,            // en
        language.French,             // fr
        language.Dutch,              // nl
        language.Make("nl-BE"),      // nl-BE
        language.SimplifiedChinese,  // zh-Hans
        language.TraditionalChinese, // zh-Hant
        language.Russian,            // ru
    }

    en := display.English.Tags()
    for _, t := range supported {
        fmt.Printf("%-20s (%s)\n", en.Name(t), display.Self.Name(t))
    }
```

というコードは次のように表示します。

```text
English              (English)
French               (français)
Dutch                (Nederlands)
Flemish              (Vlaams)
Simplified Chinese   (简体中文)
Traditional Chinese  (繁體中文)
Russian              (русский)
```

2番めの列で、大文字化に違いがあることに注目してください。個々の言語のルールを反映しています。

## 結論

ぱっと見では、言語タグはきちんとした構造化データに見えますが、自然言語を表現するものなので、言語タグ間の関係を表す構造は実際には非常に複雑です。
特に英語話者のプログラマは、しばしば言語タグの文字列を操作した、独自のアドホックな言語の対応処理を書きたくなる衝動に駆られます。
この文章で述べたように、その結果はひどいものになりえます。

Goの [golang.org/x/text/language](http://golang.org/x/text/language) パッケージは、この複雑な問題を解決しつつも、
シンプルで使いやすいAPIを提供しています。このパッケージでGoプログラミングを楽しんでください。

By Marcel van Lohuizen