がんばらない多言語化 @ FuelPHP＆CodeIgniter ユーザの集い #7 2015年1月17日 CodeIgniter ベースのGist風コードスニペットツール「Stikked」に日本語ファイルを追加したときのことを題材にいろいろ思うところをしゃべりました。

1. がんばらない多言語化
2015年1月17日 戸田広

2. 自己紹介
• 戸田 広（とだ ひろし）
@hiroshitoda
• 1979年生まれ
35歳
• ここ2年くらいは
JavaとJavaScriptくらいしか書いてません。
• PHPは5.2くらいで止まってます。
• 外国語、別に得意じゃないです。
• 大学受験のとき、英単語ターゲット1900は
400語までしかおぼえてませんでした。
• 大学の第2外国語はドイツ語でした。
いまでもおぼえてる単語は「ドイチュ！！！」くらい
• だめじゃん！！！

3. 今日話すこと
そんな私が、CodeIgniter
ベースの
Gist風コードスニペットツール「Stikked」に
日本語ファイルを追加したときのことを題材に
いろいろ思うところをしゃべります。
※PHPのコードの話はしません。
1. Stikked
への日本語ファイル追加までの経緯
2. 正確でない訳語を選ぶ理由
3. CodeIgniter
の多言語サポートで楽をした話・苦労した話
4. 主要Webアプリケーションフレームワークの多言語サポート状況
5. どうなっていれば「多言語サポート」と言えるのか？
6. クライアント側 JavaScript
との言語データの共有
7. 「Selenium」を利用した、各言語の対応確認の自動化

4. Stikked
への
日本語ファイル追加までの経緯

5. Stikked
への日本語ファイル追加までの経緯
• ローカルな GitHub
っぽいものが欲しくて、
職場で GitBucket
を導入した。
https://github.com/takezoe/gitbucket
• GitLab
を最初に検討したけど環境作るのがつらいのでやめた
• GitHub
っぽいものがあるなら
Gist
っぽいものも欲しくなった（コピペ共有の場として）。
• サンプルコードはなんとなくMLで共有されていたけど
シンタックスハイライトが無くてつらかった
• Gist
っぽいものの中で
Stikked
がいちばん環境作りやすかった。
https://github.com/claudehohl/Stikked
• Gistub
を最初に検討したけど環境作るのがつらいのでやめた

6. Stikked
への日本語ファイル追加までの経緯
• Stikked
は多言語対応してたけど、
当時 日本語ファイルが無かった。
• チーム内には英語に抵抗ある人もいる。
特に英語を勉強する気無い人もいる。
• いわゆる「意識低い人」
• チーム内の意識低い人にも浸透してほしかったので
言語障壁を無くしたかった。
• そもそも「コピペ共有基盤」のコンテキストって
「意識低い人」と同じ、気軽な方向にあるはず。

7. Stikked
への日本語ファイル追加までの経緯
• はっきり言って意識低い動機
• 作るのつらくない環境を、
自分のいるチーム向けに作りたかっただけ。
• オープンソースプロジェクトでよく言われる気がする
「社会貢献」の要素は無い。
• でも、別にそれで悪いこともないんじゃないですかね。
• 最終的に成果がコミュニティーに共有されるのであれば
動機は意識低くたって全然問題無いと思います。
• 立派な人につられないで、
みんなもっと自分のノリでやろう。

8. Stikked
への日本語ファイル追加までの経緯
• 当時、毎日22時くらいに仕事が終わった後、
家に帰ってからちょっとずつ愚直に翻訳。
• 3日くらいはかけたんだろうか…
• 2014年2月に pull
request
して
翌日 master
ブランチにマージされた。
• 速くね？
• 翻訳そのものへのレビューが無かったっぽい。
• 2014年10月に次バージョン 0.9.0
がリリースされ、
これにバンドルされた。ワーイ。

9. 正確でない訳語を選ぶ理由

10. 正確でない訳語を選ぶ理由
• Stikked
は「pastebin」系のツールと言われてて
各記事のことを「paste」と呼んでいるけど、
これをあなたなら日本語で何て表現する？
• かんたんな言葉のようで難しくね？
• 1語で対応する訳語が無い場合、
無理に直訳するとなんかノリが変わってくる。
• 今回は意識低い人でも使いやすいように
心理障壁を下げた、軽いノリ重視にしたかった。
• 「paste」→「コピペ」でよくね？

11. 正確でない訳語を選ぶ理由
• 他にも、ちょっとだけですが
英語の語順で単語が組み合わせられている場合
そのまま日本語の単語に変えても
自然になるような工夫をしたりしました。
• これはそのまま言語データのアンチパターンなのかも？
• 言語によって文章構造が異なるので、
言語データの構造はたぶん、
単語ではなく文を単位とした方が
多言語化をスムーズに進められそうです。
• あたりまえか…

12. CodeIgniter
の多言語サポートで
楽をした話・苦労した話

13. CodeIgniter
の多言語サポートで楽をした話・苦労した話
• Stikked
は CodeIgniter
ベース。
CodeIgniter
には、多言語サポートがあります。
• language
の配下に言語名のディレクトリー作っておくと
configで指定した言語名と対応するファイルを
デフォルト言語として読み込んでくれる。
• コードで明示的に言語指定することも可能。
• FuelPHPもだいたい同じ仕組みですよね？
• 言語データは、ただのPHPの連想配列。
英語データの連想配列を日本語に翻訳するだけでOK。

14. CodeIgniter
の多言語サポートで楽をした話・苦労した話
• CodeIgniter
には
日本ユーザー会による日本語ファイルがあるんでしょ？
流用できなかったの？
• 実装としては、確かに一部に流用可能だったが、
ライセンス上の問題で再配布上の制限を注入してしまう
懸念があったので、全部翻訳し直した。
• 日本ユーザー会日本語ファイルのライセンス:
修正 BSD
ライセンス
• Stikked
のライセンス:
CC0
(明示的なパブリックドメイン)

15. 主要Webアプリケーション
フレームワークの
多言語サポート状況

16. 主要Webアプリケーションフレームワークの多言語サポート状況
※最近PHPやってないんで間違ってたら教えてください…
• Laravel
• CakePHP
• 作成した言語ファイルのうち、デフォルト言語を1つ設定。
• コードで明示的に言語指定できる。
• Symfony
• 作成した言語ファイルのうち、デフォルト言語を1つ設定。
• URLにロケール文字列を入れて言語選択できる。

17. 主要Webアプリケーションフレームワークの多言語サポート状況
※最近PHPやってないんで間違ってたら教えてください…
• Zend
Framework
• Phalcon
• クライアント側の HTTP
リクエストを都度解析して
最適なロケールを得るAPIがある。
フレームワークによっては、
単語の複数形をきめこまかく設定できたり
特定のデフォルト言語をベースに
一部翻訳するようなアーキテクチャになってたりします。

18. 主要Webアプリケーションフレームワークの多言語サポート状況
• CodeIgniter
の多言語サポートは
他のフレームワークに比べて薄い方だと思います。
• でも、フルスタックの多言語サポートを
ちゃんと活かすのは、
それなりに手間がかかってたいへん。
• CodeIgniter
にはがんばらない余地があって、
それが良いところだと思います。

19. どうなっていれば
「多言語サポート」と
言えるのか？

20. どうなっていれば「多言語サポート」と言えるのか？
• PHPの主要フレームワークを見るだけでも、
「多言語サポート」という言葉が指す範囲は
けっこう広い気がします。
• 「○○フレームワークは多言語サポートしてるから
余裕っスよ（ドヤァ」
とかやらないように気をつけた方が良いです。
• 多言語サポートの仕組みは、
クライアント／サーバーシステムの枠で考えると
大きく2つに分けられるように思います。
• クライアントによらず、1つの言語を静的に選択可能
• クライアントによって、複数の言語を動的に選択可能

21. どうなっていれば「多言語サポート」と言えるのか？
• クライアントによらず、1つの言語を静的に選択可能
• 特定の地域からアクセスされるWebシステムで有効
• サーバー側で固定的に持つ設定情報によって言語を切り替える。
日本語
サーバー
日本の
クライアント
日本の
クライアント
英語
サーバー
英語圏の
クライアント
英語圏の
クライアント
ハナモゲラ
サーバー
ハナモゲラ
ハナモゲラ

22. どうなっていれば「多言語サポート」と言えるのか？
• クライアントによって、複数の言語を動的に選択可能
• 不特定の地域からアクセスされるWebシステムで有効
• クライアント側から自己申告される情報により言語を切り替える。
サーバー
日本の
クライアント
英語圏の
クライアント
ハナモゲラ
英語

23. どうなっていれば「多言語サポート」と言えるのか？
• クライアント側から自己申告される情報？
• Accept-­‐Language
(HTTP_ACCEPT_LANGUAGE)
• ブラウザーによっては必ずしもOSの言語設定を引き継がず、
ユーザーの実際の言語と異なる場合がある点に注意しましょう。
• ユーザーの明示的な選択処理
• ユーザーアカウントの設定で言語指定する、などのことです。
• Accept-­‐Language
などによる自動判定処理が
正しく動作しなかった時の救済処置としても用意すべきですね。
• URLの一部
• http://hoge.com/ja-­‐JP/foo/bar
みたいな感じ
• フレームワークによってはこれが標準になっていることもあります。

24. どうなっていれば「多言語サポート」と言えるのか？
どんな
「多言語サポート」が
求められているのか
ユーザー目線で
よく考えましょう！

25. クライアント側
JavaScript
との
言語データの共有

26. クライアント側 JavaScript
との言語データの共有
• みなさん JavaScript
で
MVVM/MVC
してますか！！！
• AngularJS
• Backbone
• KnockoutJS
• Vue
• …
…
…
• JavaScript
側で表示メッセージを扱うことも
前より多くなってきてるのでは？

27. クライアント側 JavaScript
との言語データの共有
• だいたいこういう感じになってくる。
• HTMLにメッセージを直接書かないケースも
出てきてるのでは！
var
Lang
=
{};
Lang.ja
=
{
‘foo’:
‘ふー’,
‘bar’:
‘ばー’
};
Lang.en
=
{
‘foo’:
‘foo’,
‘bar’:
‘bar’
};
var
ViewModel
=
{
this.lang
=
Lang.ja;
};
<div
id=“foo”
data-­‐bind=“text:
lang.foo”></div>

28. クライアント側 JavaScript
との言語データの共有
• 意識高い人 その1
• PHPとJavaScriptは違う言語なんだから
それぞれ言語ファイルを持って
別々に管理すべきだよね！ やるやる！
• 意識高い人 その2
• 言語とかView側の責務なんだから
すべての言語データをJavaScriptのオブジェクトに持たせようよ！
なんでも動的！

29. クライアント側 JavaScript
との言語データの共有
やめた方が
いいんじゃね？

30. クライアント側 JavaScript
との言語データの共有
• 意識高い人 その1
• PHPとJavaScriptは違う言語なんだから
それぞれ言語ファイルを持って
別々に管理すべきだよね！ やるやる！
→似たような言語データの二重管理つらいです。
片側しか更新しない手違いとかあるある…
• 意識高い人 その2
• 言語とかView側の責務なんだから
すべての言語データをJavaScriptのオブジェクトに持たせようよ！
なんでも動的！
→Viewで処理例外走るとメッセージが出なくなっちゃうので
ユーザーがつらいです。

31. クライアント側 JavaScript
との言語データの共有
• 意識低い人
• 言語データはサーバー側(PHP)でだけ持ってればいいんじゃね？
• JavaScript側に言語データほしかったら
PHPの言語データをJSONにシリアライズする単純なAPI用意すれば
いいんじゃね？
<script
src=“/lang.php?format=json”></script>
みたいな…
• 動的生成はリソースコスト高い？
キャッシュすればいいんじゃね？
※CodeIgniterは静的キャッシュを生成する機能があります。
• 動的生成だとminifyできない？
もともとpublicなプロパティばっかでminify効率低いんじゃね？

32. 「Selenium」を利用した、
各言語の対応確認の自動化

33. 「Selenium」を利用した、各言語の対応確認の自動化
• 多言語対応の最終確認は、見た目で判断するしかない。
• 言語によって改行位置とかってけっこう変わります。
• 見た目で判断するにしても
作業コストを減らせないかな？
• Webブラウザーの自動操作ライブラリー
「Selenium」を利用した
スクリーンショットの自動取得とかどうでしょうか？
• Selenium
• Webブラウザーをリモート操作するライブラリー
• リモート操作用のコードはPHPでも書ける。

34. 「Selenium」を利用した、各言語の対応確認の自動化
• スクリーンショットを取得するために
サイト内巡回だけする自動テストコードを作成するの
けっこうおすすめです。
• 全体の死活確認の仕組みを低コストで作れる。
毎回 人力でやってるとけっこうかったるい。
• 最近、日本Seleniumユーザーコミュニティーの伊藤さんが
「Sahagin」というSelenium向けの
レポーティングツールを公開しました。
https://github.com/SahaginOrg/sahagin-­‐java
• 特にスクリーンショットのコード書かなくても、
すべての操作アクションにスクリーンショットをつけてくれます。
便利！！！
• でも悪いな、このツールまだPHPバインディングが無いんだ！
• みなさんJavaもやりましょう！！！！！

35. ご静聴
ありがとうございました。