6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

LookerAdvent Calendar 2019

Day 2

Lookerでの二か国語対応のはじめかた

Last updated at Posted at 2019-12-01

#はじめに
Lookerで二か国語対応(日本語/英語対応)をやってみた内容についてご紹介いたします。
Lookerはドキュメントがしっかりしていますので、関連するドキュメントをたどりながら、自分が二か国語対応するときに迷った部分をちょっとだけ補足していくというスタイルで進めさせていただきます。
ちなみに、執筆時点のLookerバージョンは6.22.18です。

#Lookerの二か国語対応(環境設定)
Looker本体はユーザー属性にあるLocaleを設定するだけで二か国語対応できます。
ロケールの設定は管理者が設定する方法と、ユーザーが各自で設定する方法があります。

管理者がユーザーのLocaleを設定する場合はこちら
  → ロケールへのユーザーの割り当て

ユーザーが自分でLocaleを設定する場合はこちら
  → Changing Standard Account Settings

ただし、私の環境ではユーザーが自分ではLocale設定を変更できないようになっていました。
もし変更できないようになっているのであれば、以下の手順で変更できるようにすることができます。(設定変更にはAdmin権限が必要です)

  1. Admin > User Attributeをクリック
  2. localeのAction「edit」ボタンをクリック
UserAttributes_locale.png 3. User Accessの設定を「edit」にして「Save」ボタンをクリック UserAttributes_locale_UserAccess.png

#LookMLの二か国語対応
LookMLで記述するモデルの二か国語対応はLookerのドキュメントにある通りに進めることで簡単にできました。

ドキュメントはこちら
  → LookMLモデルのローカライズ

設定は

  1. プロジェクトのマニフェストファイルへのローカライズ設定の追加
  2. ロケールストリングファイルの作成
  3. モデルファイルでのローカライズされた要素の使用
    の順で進めると分かりやすいと思います。

1. マニフェストファイルへのローカライズ設定の追加

マニフェストファイルに以下の記述を追加します。

manifest.lkml
localization_settings: {
  default_locale: en
  localization_level: permissive
}

プロジェクトマニフェストファイルをまだ作っていない場合には、マニュアルの手順に従って作成しましょう。
  → マニフェストファイルの作成

default_localeの設定はお好みで。
localization_level設定はpermissiveがおすすめです。
きっちりしたい人はstrictにしても良いですが、strictにすると検証などのためにちょっとviewdimensionを追加しようというときでもロケールストリングを設定しなければならず、開発がとても面倒になります。

2. ロケールストリングファイルの作成

ロケールストリングファイルは以下の手順で作成します。

  1. 開発モードになっていることを確認します。
  2. IDEで、[Add]の横にある[+]アイコンをクリックします。
  3. [Create Locale String File]を選択します。
CreateLocaleStringFile.png

ファイル名は「ロケール名 + .strings」にします。
例えば「en.strings」であればLocaleenに設定されている時に表示される文字列を格納するファイルになります。
日本語と英語の表示をしたい場合には「en.strings」「ja_JP.strings」の2ファイルを作成します。

3. モデルファイルでのローカライズされた要素の使用

ここが肝心な部分、ローカライズされた要素の使用です。
とあるviewファイルのとあるdimensionlabelを日本語で設定していますが、これをロケールに応じて切り替えたいとします。

user.view.lkml
  dimension: user_id {
    label: "ユーザーID"
    type: string
    sql: ${TABLE}.user_id ;;
  }

先ほど作成したロケールストリングファイルに下記のように文字列を追加し、

ja_JP.strings
"user_id_label" = "ユーザーID"
en.strings
"user_id_label" = "User ID"

dimensionlabelの記述をロケールストリングファイルで定義したもの(この例ではuser_id_label)に書き換えます。

user.view.lkml
  dimension: user_id {
    label: "user_id_label"
    type: string
    sql: ${TABLE}.user_id ;;
  }

#データ内容の二か国語対応
自分が取り扱っているデータでは以下のようなマスターデータがありまして、Localeの設定内容に合わせてname_ja_JPname_enのどちらを表示させるか切り替えたい、という要望がありました。

plan_code name_en name_ja_JP
1 Economy エコノミー
2 Standard スタンダード
3 Premium プレミアム

そこでdimensionの設定を下記のようにして対応しました。

view.lkml
  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

#おわりに
以上で設定は完了です。
かなり簡単に二か国語対応を始められるという印象を持ちました。

実際に二か国語対応をしてみると、ラベルなどに表示する文字列を一元管理できるため、表記の揺らぎがなくなる(揺らぎに気づきやすくなる)というメリットもありました。
これによりデータの統制(データ表記の統制)が取れて運用しやすくなるのかなと思っています。

きっちり統制してしっかり運用するためにも、ロケールストリング設定をきちんと管理していく必要がありますので、文字列の定義やストリングファイル内の作りをどうするのがベストなのか、私も探りながら運用して行こうと思っています。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?