日報 #43 - 言語切替について

俺の扶養は大学授業料免除ほぼ確定のサンクチュアリです。

さて、今日も今日とて話題がないので、
ちょっとsmartyとDB連携の辞書の話でも簡単に。

多言語対応は中々厄介でございます。
csvや辞書ファイルのようなもので管理してもいいのですが、
それだと追加変更の管理が煩雑で、しかも不必要な文字列を大量に保持する必要が生じたりしますね。
ちょっとした変更ですらリポジトリレベルでの書き換えが必要になるのも避けたいものです。
やっぱりDB管理がいいんじゃないかな、と僕は思っていますが、
実際のところどうなんでしょうね。

僕が今のところやっている手法は、smartyに独自block要素、例えば{t}のようなものを突っ込んで、
DB連携で翻訳するというものです。
{t}こんな感じ{/t}
でsmarty上に書き込むと、DB上の「こんな感じ」キーを探しだしてそのキーがあるレコードの言語カラムをレンダリングする。こうすればSEO的にもHTMLとして書き出された結果を正しく取得できますね。
それに、翻訳しようとしたキーがDB上になければ自動的にインサートする仕組みを入れておけば、
翻訳作業は後でDB上で補完すればいいだけです。
一度使った辞書はキャッシュしておけば何度も走査する必要もなくなり、
実行速度も問題ありません。
%s的なフォーマットも関数に仕込んでおけば、
{t var=array('tom')} %sの部屋 {/t}
こんな感じで変数を仕込んだ上での辞書登録も簡単です。

ま、つまり、
「辞書ファイルの管理をしない」、ということを設計思想のトップにおいております。
便宜上dictionaryのようなテーブルは出来ますが、
大型更新の度に別に最悪ドロップしたってかまいません。
全ページをクロールすれば「使われているワード」のテーブルが自動的に生成され、
翻訳はそのままクラウドソーシングすればいいだけですね。
HTMLコーダーは文字列を{t}で囲うだけで翻訳を完了できるし、
今のところ問題なく扱えております。
ま、smartyがどうなんだって話はありますけどねｗ

じゃぁ実際そのlocalizeクラスはどうなってんのかって、
公開したいんですが、まぁ若干気まずい部分があるんで、まだ今度。。。