JSアプリの多言語対応アーキテクチャについて
@kyo_ago 伝統的なgettext系のワークフローだと、共通化するのは文言リソースレイヤーではなくて、翻訳レイヤーですね。いわゆる翻訳メモリ。
2014-11-18 22:22:15@teppeis 「全体を共通化して翻訳してから各モジュール毎に必要な単位にバラす」みたいな感じなんでしょうか? 「使ってない文言を削除できない」って点なんですが、「不要な文言の把握や各モジュール間の重複文言の扱い、文言から使用箇所の把握」とかどうしたらいいんでしょうか?
2014-11-18 22:35:33文言リソースはサーバサイドに置いて毎回フロントに渡すのがいいの? ネイティブアプリも考えるとそもそもサーバサイドには文言置かずにクライアントサイドに置いてサーバからメッセージ出したい場合は文言idで指定するのがいいの?
2014-11-18 22:39:47@kyo_ago 前提として、翻訳やドキュメントの専任者がいる場合とそうでない場合で違うと思います。うちは専任者がいて、基本的にはコード側では文言が共通とかそうでないとか考えない。翻訳側が適宜やる。前のツイートのはそういう意味です。
2014-11-18 22:41:36@kyo_ago はい。コード側のリソース切り出し方で文言を共通化すると、PG的にはDRYっぽい気がするんですが、あとからコード変更無しで一部だけ文言変更とかができません。規模と人員体制とワークフローによると思いますが。
2014-11-18 22:47:59@teppeis うーん。理想ではあるんですが、外部に依頼する場合だとワークフローをどうするか悩ましいですねー (ツールの問題な気もしますが。。。)
2014-11-18 22:52:16@kyo_ago 外注でも同じようなものかなと。基本は文言キーリストとどのUIのどの文言かを図示した資料または動く実物を提出することになると思います。事前に文言キーが共通にされたりしてると面倒になると思います。
2014-11-18 22:58:14@kyo_ago フォーマットは外注業者によるので、まずは業者を探して見積もり&相談してみては。ピンキリですし、Word形式を要求してくるとこもありますよw
2014-11-18 23:00:00@teppeis うーん。どちらかと言うと翻訳フローというより、こっち系の話で悩んでたりします twitter.com/kyo_ago/status…
2014-11-18 23:01:41「諦めましょう」というメッセージしか受け取れない。。。 // はてなにおける Web アプリケーションの国際化 wakaba.github.io/packages/slide…
2014-11-18 23:03:28「翻訳システム「Hatena::Translator(はてな翻訳)」を自社で開発し、国際化に挑みました」 / “国際化を果たした「うごメモ」の世界での盛り上がりと自社開発翻訳システム「Hatena::Translator」 - は…” htn.to/yS7hn5
2014-11-18 23:03:46@kyo_ago それもアーキテクチャによるとしか。。うちは基本JSでHTMLレンダリングするのででかい文言.jsonみたいなのを出してます。サーバー側で必要なのはサーバーに。
2014-11-18 23:10:46Closure Compilerの場合はJSとHTMLテンプレートに国際化済み文言埋め込むところまでやると尊敬される。
2014-11-18 23:13:15@teppeis やっぱり文言.jsonなんですね。。。 アーキテクチャによるのはもちろんなんですが、多分みんな困ってるし、少なくとも「この辺を考慮するとこの部分はこうなる」的なベストプラクティスはほしいと思ってます
2014-11-18 23:13:22「でかい.poをサーバサイドに置いて、まんま変換した文言.jsonを毎回クライアントに渡す」は全員が不幸になるのでもうやめたい
2014-11-18 23:15:36@kyo_ago ですね。大規模化すると文言.json内の使わない文言の割合が高まるので、埋め込みの方がベター developers.google.com/closure/templa…
2014-11-18 23:17:05