はじめに
Lookerで二か国語対応(日本語/英語対応)をやってみた内容についてご紹介いたします。
Lookerはドキュメントがしっかりしていますので、関連するドキュメントをたどりながら、自分が二か国語対応するときに迷った部分をちょっとだけ補足していくというスタイルで進めさせていただきます。
ちなみに、執筆時点のLookerバージョンは6.22.18です。
Lookerの二か国語対応(環境設定)
Looker本体はユーザー属性にあるLocaleを設定するだけで二か国語対応できます。
ロケールの設定は管理者が設定する方法と、ユーザーが各自で設定する方法があります。
管理者がユーザーのLocaleを設定する場合はこちら
→ ロケールへのユーザーの割り当て
ユーザーが自分でLocaleを設定する場合はこちら
→ Changing Standard Account Settings
ただし、私の環境ではユーザーが自分ではLocale設定を変更できないようになっていました。
もし変更できないようになっているのであれば、以下の手順で変更できるようにすることができます。(設定変更にはAdmin権限が必要です)
- Admin > User Attributeをクリック
-
localeのAction「edit」ボタンをクリック
3. User Accessの設定を「edit」にして「Save」ボタンをクリック
LookMLの二か国語対応
LookMLで記述するモデルの二か国語対応はLookerのドキュメントにある通りに進めることで簡単にできました。
ドキュメントはこちら
→ LookMLモデルのローカライズ
設定は
- プロジェクトのマニフェストファイルへのローカライズ設定の追加
- ロケールストリングファイルの作成
- モデルファイルでのローカライズされた要素の使用
の順で進めると分かりやすいと思います。
1. マニフェストファイルへのローカライズ設定の追加
マニフェストファイルに以下の記述を追加します。
localization_settings: {
default_locale: en
localization_level: permissive
}
プロジェクトマニフェストファイルをまだ作っていない場合には、マニュアルの手順に従って作成しましょう。
→ マニフェストファイルの作成
default_localeの設定はお好みで。
localization_level設定はpermissiveがおすすめです。
きっちりしたい人はstrictにしても良いですが、strictにすると検証などのためにちょっとviewにdimensionを追加しようというときでもロケールストリングを設定しなければならず、開発がとても面倒になります。
2. ロケールストリングファイルの作成
ロケールストリングファイルは以下の手順で作成します。
- 開発モードになっていることを確認します。
- IDEで、[Add]の横にある[+]アイコンをクリックします。
- [Create Locale String File]を選択します。
ファイル名は「ロケール名 + .strings」にします。
例えば「en.strings」であればLocaleがenに設定されている時に表示される文字列を格納するファイルになります。
日本語と英語の表示をしたい場合には「en.strings」「ja_JP.strings」の2ファイルを作成します。
3. モデルファイルでのローカライズされた要素の使用
ここが肝心な部分、ローカライズされた要素の使用です。
とあるviewファイルのとあるdimensionでlabelを日本語で設定していますが、これをロケールに応じて切り替えたいとします。
dimension: user_id {
label: "ユーザーID"
type: string
sql: ${TABLE}.user_id ;;
}
先ほど作成したロケールストリングファイルに下記のように文字列を追加し、
"user_id_label" = "ユーザーID"
"user_id_label" = "User ID"
dimensionのlabelの記述をロケールストリングファイルで定義したもの(この例ではuser_id_label)に書き換えます。
dimension: user_id {
label: "user_id_label"
type: string
sql: ${TABLE}.user_id ;;
}
データ内容の二か国語対応
自分が取り扱っているデータでは以下のようなマスターデータがありまして、Localeの設定内容に合わせてname_ja_JPとname_enのどちらを表示させるか切り替えたい、という要望がありました。
| plan_code | name_en | name_ja_JP |
|---|---|---|
| 1 | Economy | エコノミー |
| 2 | Standard | スタンダード |
| 3 | Premium | プレミアム |
そこでdimensionの設定を下記のようにして対応しました。
dimension: name {
type: string
sql:
{% if _user_attributes['locale'] == 'ja_JP' %}
${TABLE}.name_ja_JP
{% else %}
${TABLE}.name_en
{% endif %} ;;
}
どんな環境でも使えるという訳ではありませんが、似たような要件に遭遇したときには参考にしてもらえたらと思います。
関連するマニュアルは下記の通りです。
{% if %}``{% else %}``{% endif %}について詳しく知りたい場合はこちら
→ Liquid Control flow
→ Liquid Operators
_user_attributes['locale']について詳しく知りたい場合はこちら
→ Liquid Variable Definitions
おわりに
以上で設定は完了です。
かなり簡単に二か国語対応を始められるという印象を持ちました。
実際に二か国語対応をしてみると、ラベルなどに表示する文字列を一元管理できるため、表記の揺らぎがなくなる(揺らぎに気づきやすくなる)というメリットもありました。
これによりデータの統制(データ表記の統制)が取れて運用しやすくなるのかなと思っています。
きっちり統制してしっかり運用するためにも、ロケールストリング設定をきちんと管理していく必要がありますので、文字列の定義やストリングファイル内の作りをどうするのがベストなのか、私も探りながら運用して行こうと思っています。