がんばらない多言語化 @ FuelPHP＆CodeIgniter ユーザの集い #7

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

自己紹介

• 戸田　広（とだ　ひろし） @hiroshitoda •  1979年生まれ 35歳 • ここ2年くらいは JavaとJavaScriptくらいしか書いてません。 •  PHPは5.2くらいで止まってます。

• 外国語、別に得意じゃないです。 • 大学受験のとき、英単語ターゲット1900は 400語までしかおぼえてませんでした。 • 大学の第2外国語はドイツ語でした。いまでもおぼえてる単語は「ドイチュ！！！」くらい •  だめじゃん！！！

今日話すこと

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

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


• ローカルな GitHub っぽいものが欲しくて、職場で GitBucket を導入した。 https://github.com/takezoe/gitbucket •  GitLab を最初に検討したけど環境作るのがつらいのでやめた

• GitHub っぽいものがあるなら Gist っぽいものも欲しくなった（コピペ共有の場として）。 •  サンプルコードはなんとなくMLで共有されていたけどシンタックスハイライトが無くてつらかった

• Gist っぽいものの中で Stikked がいちばん環境作りやすかった。 https://github.com/claudehohl/Stikked •  Gistub を最初に検討したけど環境作るのがつらいのでやめた


•  Stikked は多言語対応してたけど、当時日本語ファイルが無かった。

• チーム内には英語に抵抗ある人もいる。特に英語を勉強する気無い人もいる。 •  いわゆる「意識低い人」

• チーム内の意識低い人にも浸透してほしかったので言語障壁を無くしたかった。

• そもそも「コピペ共有基盤」のコンテキストって「意識低い人」と同じ、気軽な方向にあるはず。


• はっきり言って意識低い動機 •  作るのつらくない環境を、自分のいるチーム向けに作りたかっただけ。

•  オープンソースプロジェクトでよく言われる気がする「社会貢献」の要素は無い。

• でも、別にそれで悪いこともないんじゃないですかね。 •  最終的に成果がコミュニティーに共有されるのであれば動機は意識低くたって全然問題無いと思います。

•  立派な人につられないで、みんなもっと自分のノリでやろう。


• 当時、毎日22時くらいに仕事が終わった後、家に帰ってからちょっとずつ愚直に翻訳。 •  3日くらいはかけたんだろうか…

•  2014年2月に pull request して翌日 master ブランチにマージされた。 •  速くね？ •  翻訳そのものへのレビューが無かったっぽい。

•  2014年10月に次バージョン 0.9.0 がリリースされ、これにバンドルされた。ワーイ。

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


•  Stikked は「pastebin」系のツールと言われてて各記事のことを「paste」と呼んでいるけど、これをあなたなら日本語で何て表現する？ •  かんたんな言葉のようで難しくね？

•  1語で対応する訳語が無い場合、無理に直訳するとなんかノリが変わってくる。 •  今回は意識低い人でも使いやすいように心理障壁を下げた、軽いノリ重視にしたかった。

• 「paste」→「コピペ」でよくね？


• 他にも、ちょっとだけですが英語の語順で単語が組み合わせられている場合そのまま日本語の単語に変えても自然になるような工夫をしたりしました。

• これはそのまま言語データのアンチパターンなのかも？

• 言語によって文章構造が異なるので、言語データの構造はたぶん、単語ではなく文を単位とした方が多言語化をスムーズに進められそうです。 •  あたりまえか…

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


•  Stikked は CodeIgniter ベース。 CodeIgniter には、多言語サポートがあります。 •  language の配下に言語名のディレクトリー作っておくと configで指定した言語名と対応するファイルをデフォルト言語として読み込んでくれる。

•  コードで明示的に言語指定することも可能。 •  FuelPHPもだいたい同じ仕組みですよね？

• 言語データは、ただのPHPの連想配列。英語データの連想配列を日本語に翻訳するだけでOK。


•  CodeIgniter には日本ユーザー会による日本語ファイルがあるんでしょ？流用できなかったの？ •  実装としては、確かに一部に流用可能だったが、ライセンス上の問題で再配布上の制限を注入してしまう懸念があったので、全部翻訳し直した。 •  日本ユーザー会日本語ファイルのライセンス: 修正 BSD ライセンス

•  Stikked のライセンス: CC0 (明示的なパブリックドメイン)

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


※最近PHPやってないんで間違ってたら教えてください… •  Laravel •  CakePHP •  作成した言語ファイルのうち、デフォルト言語を1つ設定。 •  コードで明示的に言語指定できる。

•  Symfony •  作成した言語ファイルのうち、デフォルト言語を1つ設定。 •  URLにロケール文字列を入れて言語選択できる。


※最近PHPやってないんで間違ってたら教えてください… •  Zend Framework •  Phalcon •  クライアント側の HTTP リクエストを都度解析して最適なロケールを得るAPIがある。

フレームワークによっては、単語の複数形をきめこまかく設定できたり特定のデフォルト言語をベースに一部翻訳するようなアーキテクチャになってたりします。


•  CodeIgniter の多言語サポートは他のフレームワークに比べて薄い方だと思います。

• でも、フルスタックの多言語サポートをちゃんと活かすのは、それなりに手間がかかってたいへん。

•  CodeIgniter にはがんばらない余地があって、それが良いところだと思います。

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


•  PHPの主要フレームワークを見るだけでも、「多言語サポート」という言葉が指す範囲はけっこう広い気がします。

• 「○○フレームワークは多言語サポートしてるから　余裕っスよ（ドヤァ」とかやらないように気をつけた方が良いです。

• 多言語サポートの仕組みは、クライアント／サーバーシステムの枠で考えると大きく2つに分けられるように思います。 •  クライアントによらず、1つの言語を静的に選択可能 •  クライアントによって、複数の言語を動的に選択可能


• クライアントによらず、1つの言語を静的に選択可能 •  特定の地域からアクセスされるWebシステムで有効 •  サーバー側で固定的に持つ設定情報によって言語を切り替える。

日本語サーバー

日本のクライアント


英語サーバー

英語圏のクライアント

英語圏のクライアント

ハナモゲラサーバー

ハナモゲラ

ハナモゲラ


• クライアントによって、複数の言語を動的に選択可能 •  不特定の地域からアクセスされるWebシステムで有効 •  クライアント側から自己申告される情報により言語を切り替える。

サーバー


英語圏のクライアントハナモゲラ

英語


• クライアント側から自己申告される情報？

•  Accept-‐Language (HTTP_ACCEPT_LANGUAGE) •  ブラウザーによっては必ずしもOSの言語設定を引き継がず、ユーザーの実際の言語と異なる場合がある点に注意しましょう。

•  ユーザーの明示的な選択処理 •  ユーザーアカウントの設定で言語指定する、などのことです。 •  Accept-‐Language などによる自動判定処理が正しく動作しなかった時の救済処置としても用意すべきですね。

•  URLの一部 •  http://hoge.com/ja-‐JP/foo/bar みたいな感じ •  フレームワークによってはこれが標準になっていることもあります。


どんな「多言語サポート」が求められているのかユーザー目線で

よく考えましょう！

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


• みなさん JavaScript で MVVM/MVC してますか！！！ •  AngularJS •  Backbone •  KnockoutJS •  Vue •  … … …

•  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>


• 意識高い人その1 •  PHPとJavaScriptは違う言語なんだからそれぞれ言語ファイルを持って別々に管理すべきだよね！やるやる！

• 意識高い人その2 •  言語とかView側の責務なんだからすべての言語データをJavaScriptのオブジェクトに持たせようよ！なんでも動的！


やめた方がいいんじゃね？


• 意識高い人その1 •  PHPとJavaScriptは違う言語なんだからそれぞれ言語ファイルを持って別々に管理すべきだよね！やるやる！

→似たような言語データの二重管理つらいです。　片側しか更新しない手違いとかあるある…

• 意識高い人その2 •  言語とかView側の責務なんだからすべての言語データをJavaScriptのオブジェクトに持たせようよ！なんでも動的！

→Viewで処理例外走るとメッセージが出なくなっちゃうので　ユーザーがつらいです。


• 意識低い人

•  言語データはサーバー側(PHP)でだけ持ってればいいんじゃね？

•  JavaScript側に言語データほしかったら PHPの言語データをJSONにシリアライズする単純なAPI用意すればいいんじゃね？ <script src=“/lang.php?format=json”></script> みたいな…

•  動的生成はリソースコスト高い？キャッシュすればいいんじゃね？ ※CodeIgniterは静的キャッシュを生成する機能があります。

•  動的生成だとminifyできない？もともとpublicなプロパティばっかでminify効率低いんじゃね？

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


• 多言語対応の最終確認は、見た目で判断するしかない。 •  言語によって改行位置とかってけっこう変わります。

• 見た目で判断するにしても作業コストを減らせないかな？ •  Webブラウザーの自動操作ライブラリー「Selenium」を利用したスクリーンショットの自動取得とかどうでしょうか？

•  Selenium •  Webブラウザーをリモート操作するライブラリー •  リモート操作用のコードはPHPでも書ける。


• スクリーンショットを取得するためにサイト内巡回だけする自動テストコードを作成するのけっこうおすすめです。 •  全体の死活確認の仕組みを低コストで作れる。毎回人力でやってるとけっこうかったるい。

• 最近、日本Seleniumユーザーコミュニティーの伊藤さんが「Sahagin」というSelenium向けのレポーティングツールを公開しました。 https://github.com/SahaginOrg/sahagin-‐java •  特にスクリーンショットのコード書かなくても、すべての操作アクションにスクリーンショットをつけてくれます。便利！！！

•  でも悪いな、このツールまだPHPバインディングが無いんだ！ •  みなさんJavaもやりましょう！！！！！

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

Technology

がんばらない多言語化 @ FuelPHP＆CodeIgniter ユーザの集い #7