JS多言語化話

kyo_ago @kyo_ago

言語リソースを事前にJSへ直接埋め込む場合、コードの中では文字列リテラルの中だけを考えればいいのか？

kyo_ago @kyo_ago

@tyanagida このへんに関してあまり正解が見えないのでなにかうまい方法がないかなーと思ってます

kyo_ago @kyo_ago

@tyanagida なるほどー　バージョン管理の問題もありますね（はてなの資料でも「gitにバイナリとして認識させてる」とありましたが。。。）

kyo_ago @kyo_ago

そもそもブラウザのフロントエンドで文言問題解決しても各アプリ内の文言どうするか問題解決してない

kyo_ago @kyo_ago

「アプリは事前ダウンロードするから言語情報全部入りで重くなっても大丈夫」ってことでブラウザのフロントエンドと別に考えていいんだろうか？ このへん、アプリの実装してて辛くなったりしないのか？ 誰が一番負担を負ってるんだ？

kyo_ago @kyo_ago

「アプリとJSでサービス実装してる時の多言語化必勝パターン」早く

kyo_ago @kyo_ago

明日、社内のアプリの人にも色々聞いてみるか。。。

kyo_ago @kyo_ago

ブラウザのフロントエンドだけにかぎって言えば一旦サーバサイドに集めた文言設定を毎回配信してもらうのがいい気がするな。 サーバサイドから文言設定引き上げるのは非常に難しいし、アプリ起動のフロー内にサーバサイドの処理が絶対入ってくるから

kyo_ago @kyo_ago

コード内の文言参照を事前に置き換えるかは微妙だな。文言変更よりコードの書き換えのほうが頻度高そうだからキャッシュが消える問題はそこまで大きな問題にならなさそう

kyo_ago @kyo_ago

コードの事前書き換えはあんまり一般的じゃない気がするし、なにか穴がありそうなんだけど特に問題ないようにも思える。 テンプレートの事前書き換えはClosure Toolsでもあるっぽいしコードも同じようにやったらまずいのか？

kyo_ago @kyo_ago

でも、結局「事前置き換えができる」のは単純に「参照がコード内にわかりやすく書かれてる」ってことだから普通に自分で参照しても変わらないか。 「被参照が取れる」ってのには意味ありそうだからその部分だけにした方がいいか（コンパイルの段数増えても辛いだけだし）

kyo_ago @kyo_ago

SASSとかで多言語化するときのサポートとかあるのかな。。。

kyo_ago @kyo_ago

CSSの多言語化事情知りたい

kyo_ago @kyo_ago

以前の経験だと「テンプレート固有の文言と汎用的な文言を分けて管理して、出来る限りテンプレート固有文言に追いやる」ってやると後々そこまで辛くなかった。 でも、あとでテンプレート名変えたり、使うテンプレート名が変わったり、「2つのテンプレートからだけ使う文言」とかは辛い感じだった

kyo_ago @kyo_ago

あとこれは直接JSに埋め込んでたから.po化してなかったのもあれだ。 .po化しなくてもいいけど、他の管理する仕組みと合わせて考えると言語設定の階層化は難しい。 __とかを区切り文字にしてフラット化させてもいいけど。。。

kyo_ago @kyo_ago

あれ？結局結論が、「定期的にコードgrepして使ってる言語キー集めて突き合わせる」になったけどいいのか？

kyo_ago @kyo_ago

翻訳リソース内からテンプレート固有文言とコード内で使用する文言の切り分けはどうやってやったらいいんだ？ そもそもエンジニアが切り出すのが間違い？ デザインから直接翻訳のワークフローに流してその時点で翻訳対象に翻訳キーが付けられているべき？

kyo_ago @kyo_ago

今だとマークアップからテンプレートへ切り出すときに翻訳対象一覧にまとめてそこにエンジニアが翻訳キーを付けて翻訳してもらったものを言語内でまとめてるけど、そもそもこのワークフロー前提なのがまずいのか？

kyo_ago @kyo_ago

でも、外部に委託する場合何度もやりとりできないので翻訳フローをは出来るだけ後にしたい

kyo_ago @kyo_ago

現状のワークフローと問題点と改善案まとめて話せばいいのかな