多言語対応しました
日本語環境以外からアクセスした場合には英語表示になりました。
多言語対応
アメリカや中国など海外からのアクセスもわずかながらあったのですが、そのあたりの取りこぼしをなくすため、またターゲットユーザーをひろげるため多言語対応しました。
多言語対応の仕組み
nuxt-i18nというモジュールを使って実装しました。Vue.js用のi18nライブラリであるvue-i18nにいくつかの機能を追加したものになっています。
ちなみに国際化（internationalization）を示すのがなぜ「18」なのかは次のとおりです。
i18nは数略語であり、その「18」は、internationalization の先頭の i と語尾の n の間に nternationalizatio の18文字があることに起因する。1970年代か1980年代かにDECで作られた用法といわれる[1]。大文字の I は数字の 1 と間違いやすいので一般的には小文字の i が使用される。
同様にして地域化（localization）は「L10N」と表記されます。18ヶ国語あるいは10ヶ国語にに対応とかという意味ではありません。
nuxt-i18nでできることとしてはそれぞれの言語での表示はもちろん、言語に応じた自動ルート生成、言語の切り替えにも対応をしています。
例えば日本語をデフォルトにした場合、以下の4つのパターンを選択することができます。
パターン1
https://example.com にアクセスするとブラウザの言語設定に応じた言語で表示がされる。（各言語共通のURL）
パターン2
https://example.com にアクセスすると日本語で表示される。
https://example.com/en/ にアクセスすると英語で表示される。
パターン3
https://example.com/ja/ にアクセスすると日本語で表示される。
https://example.com/en/ にアクセスすると英語で表示される。
https://example.com/ にアクセスすると /ja/ にリダイレクトされる。
パターン4
https://example.com/ja/ にアクセスすると日本語で表示される。
https://example.com/en/ にアクセスすると英語で表示される。
https://example.com/ にアクセスすると（リダイレクトされずに）日本語で表示される。
上記のパターン2〜4だとプルダウンなどで言語の切り替えをすることで表示される言語を自動的に切り替えることができるようになっています。
LGTM GENの場合はパターン1を採用しています。言語を切り替える必要性もほぼなく、用意されている言語も英語と日本語だけなので同じURLでブラウザの言語設定で自動的に表示される内容を切り替えたほうが妥当であろうということでこのパターンを採用しています。
nuxt-i18nの使い方やできることについての解説はこちらのサイトが詳しくてわかりやすかったです。
エラーページの対応
ページが見つからないときなどのエラーページのデザインが用意されていなかったため、用意しました。
を見て実装しました。今まで存在しないURLにアクセスした際にNuxtのエラーが表示されていましたが、この対応により正常にエラー画面が表示されるようになりました。
自動ビルド・デプロイ対応
Cloud Buildを使ってビルドとデプロイを自動化しました。
Cloud Buildは1日120分まで無料で使うことができ、Node.js, Java, GoやDocker, Packerを利用したVMのビルド、App EngineやFirebaseなどへのデプロイに対応をしています。
ビルドの設定はyamlかjson形式で記述することができます。他のCIツールなんかと一緒かと思います。
LGTM GENではそれぞれ以下のようなトリガーを用意しています。
1. master以外のブランチにpushがあった場合
Node.js のビルドを実行します。ビルド時間はだいたい5〜10分程度かかります。
steps:
- name: node
entrypoint: npm
args: ['install']
- name: node
entrypoint: npm
args: ['run', 'build']
- name: node
entrypoint: npm
args: ['run', 'lint']
- name: node
entrypoint: npm
args: ['run', 'generate', '--fail-on-error']ビルドが成功するとGitHub上でこのようにチェックが表示されます。
masterにマージする際のPull Requestは
のように「All checks have passed」と表示されるようになります。マージの時点でビルドエラーになっていないかチェックをした上でマージすることができます。
2. masterブランチにpushがあった場合
テスト環境へデプロイします。
steps:
- name: gcr.io/{TEST-PROJECT}/firebase
args: ['deploy', '--project={TEST-PROJECT}', '--only=hosting']GitHub上でmasterにマージすると自動的にテスト環境へデプロイされるようになります。
3. 新しいタグにpushがあった場合
本番環境へデプロイします。
テスト環境で動作の確認を行って問題なければGitHub上でタグを切ります。そうすると自動的に本番環境へのデプロイが開始されます。
CIツールを導入したことでのメリット
今までデプロイはお手製のコマンドを用意して実行していましたが、fireabse login し直さないとうまく本番環境にデプロイできないという手間が発生していました。テスト環境と本番環境のデプロイコマンドを間違えてしまう危険性もはらんでいました。
Cloud Buildによるビルドとデプロイの自動化でそのあたりの手間がかなり軽減されました。
プロダクション環境へのデプロイごとにタグを切る形になるため、どのバージョンが本番稼働しているのかわかりやすくなったのも良い点です。
お仕事でやっているプロダクトのビルド・デプロイのリリースフローに近くなりました。
この記事が気に入ったらサポートをしてみませんか？