JSアプリの多言語対応アーキテクチャについて

JSアプリを多言語化するには、色々な悩みがあります。現場で開発している方のコメントが興味深いのでまとめました。
0
kyo_ago @kyo_ago

多言語対応時の文字リソースの持ち方、誰か正解教えて。。。

2014-11-18 18:26:03
kyo_ago @kyo_ago

複数アプリ、フロントエンド、バックエンドあった場合、共通化するの?しないの?

2014-11-18 18:26:35
kyo_ago @kyo_ago

複数アプリ、フロントエンド、バックエンドあった場合、共通化するの?しないの?

2014-11-18 18:26:35
Teppei Sato @teppeis

@kyo_ago 伝統的なgettext系のワークフローだと、共通化するのは文言リソースレイヤーではなくて、翻訳レイヤーですね。いわゆる翻訳メモリ。

2014-11-18 22:22:15
kyo_ago @kyo_ago

@teppeis 「全体を共通化して翻訳してから各モジュール毎に必要な単位にバラす」みたいな感じなんでしょうか? 「使ってない文言を削除できない」って点なんですが、「不要な文言の把握や各モジュール間の重複文言の扱い、文言から使用箇所の把握」とかどうしたらいいんでしょうか?

2014-11-18 22:35:33
kyo_ago @kyo_ago

文言リソースはサーバサイドに置いて毎回フロントに渡すのがいいの? ネイティブアプリも考えるとそもそもサーバサイドには文言置かずにクライアントサイドに置いてサーバからメッセージ出したい場合は文言idで指定するのがいいの?

2014-11-18 22:39:47
Teppei Sato @teppeis

@kyo_ago 前提として、翻訳やドキュメントの専任者がいる場合とそうでない場合で違うと思います。うちは専任者がいて、基本的にはコード側では文言が共通とかそうでないとか考えない。翻訳側が適宜やる。前のツイートのはそういう意味です。

2014-11-18 22:41:36
kyo_ago @kyo_ago

@teppeis なるほど。割とUIそのまま翻訳してるんですね。

2014-11-18 22:43:34
Teppei Sato @teppeis

@kyo_ago はい。コード側のリソース切り出し方で文言を共通化すると、PG的にはDRYっぽい気がするんですが、あとからコード変更無しで一部だけ文言変更とかができません。規模と人員体制とワークフローによると思いますが。

2014-11-18 22:47:59
kyo_ago @kyo_ago

翻訳を外部に依頼する場合、何でやり取りするのがいいの? やっぱり翻訳キーに日本語はまずい? 翻訳キーはUIと関連づけるべき?

2014-11-18 22:50:00
kyo_ago @kyo_ago

@teppeis うーん。理想ではあるんですが、外部に依頼する場合だとワークフローをどうするか悩ましいですねー (ツールの問題な気もしますが。。。)

2014-11-18 22:52:16
Teppei Sato @teppeis

@kyo_ago 外注でも同じようなものかなと。基本は文言キーリストとどのUIのどの文言かを図示した資料または動く実物を提出することになると思います。事前に文言キーが共通にされたりしてると面倒になると思います。

2014-11-18 22:58:14
Teppei Sato @teppeis

@kyo_ago フォーマットは外注業者によるので、まずは業者を探して見積もり&相談してみては。ピンキリですし、Word形式を要求してくるとこもありますよw

2014-11-18 23:00:00
Teppei Sato @teppeis

“はてなにおける Web アプリケーションの国際化” htn.to/dK9DKXRLhpq

2014-11-18 23:01:28
kyo_ago @kyo_ago

@teppeis うーん。どちらかと言うと翻訳フローというより、こっち系の話で悩んでたりします twitter.com/kyo_ago/status…

2014-11-18 23:01:41
kyo_ago @kyo_ago

「諦めましょう」というメッセージしか受け取れない。。。 // はてなにおける Web アプリケーションの国際化 wakaba.github.io/packages/slide…

2014-11-18 23:03:28
Teppei Sato @teppeis

「翻訳システム「Hatena::Translator(はてな翻訳)」を自社で開発し、国際化に挑みました」 / “国際化を果たした「うごメモ」の世界での盛り上がりと自社開発翻訳システム「Hatena::Translator」 - は…” htn.to/yS7hn5

2014-11-18 23:03:46
Teppei Sato @teppeis

ちなみに弊社では翻訳文言管理にkintoneを使っております。

2014-11-18 23:04:51
kyo_ago @kyo_ago

今まで毎回.po使って破綻してるんだけど、みんなほんとにあれ使ってるの?

2014-11-18 23:08:25
Teppei Sato @teppeis

@kyo_ago それもアーキテクチャによるとしか。。うちは基本JSでHTMLレンダリングするのででかい文言.jsonみたいなのを出してます。サーバー側で必要なのはサーバーに。

2014-11-18 23:10:46
Teppei Sato @teppeis

Closure Compilerの場合はJSとHTMLテンプレートに国際化済み文言埋め込むところまでやると尊敬される。

2014-11-18 23:13:15
kyo_ago @kyo_ago

@teppeis やっぱり文言.jsonなんですね。。。 アーキテクチャによるのはもちろんなんですが、多分みんな困ってるし、少なくとも「この辺を考慮するとこの部分はこうなる」的なベストプラクティスはほしいと思ってます

2014-11-18 23:13:22
kyo_ago @kyo_ago

「でかい.poをサーバサイドに置いて、まんま変換した文言.jsonを毎回クライアントに渡す」は全員が不幸になるのでもうやめたい

2014-11-18 23:15:36
Teppei Sato @teppeis

@kyo_ago ですね。大規模化すると文言.json内の使わない文言の割合が高まるので、埋め込みの方がベター developers.google.com/closure/templa…

2014-11-18 23:17:05