画面に表示されると同時に translated なものと、translate ボタンを押さないと翻訳されないものとあるんだな。これってつまり、translated なデータが保存されてたなら再利用してるってことなんだろう。
言い換えると、翻訳済みのものが流れてきたってことは、同じ母国語の誰かが興味を持って translate させたってこと。Star ほどじゃないけど、何かの指針になるかもね。
Commit
330a656
now that you mentioned it, that's actually clever on the part of /dev/null team. show original for fewer translation request, if somebody translated it then store, then serve the translation moving forward
翻訳コストは抑えられるよね。ストレージコストは増えるし、言語差チェックや、追加のローディングクエリなんかも増えるけど、、AI model を利用する翻訳が一番コスト高いし、妥当な落とし所って気がする。よいバランス感覚。
Out of curiosity, how does doing it like that affect storage costs? If anything, it keeps it down by not storing transalations when not needed, no?
なにと比較するかが曖昧でしたね。
原文のみを保存しておき、ユーザーが translate ボタンを押すたびに翻訳して表示するようなアーキテクチャと比較してた。翻訳処理をブラウザやクライアント側に寄せるとそういうアーキテクチャになると思う。
「すべてをあらかじめ翻訳して保存しておく」というアーキテクチャが最も翻訳コスト＆ストレージコストがかかると思っている。Xが採用している仕組みはこれじゃないかな。それと比べると今の戦略はストレージコストを抑えていると思うよ。
Oh, yes it was indeed confusing, but now that I understand, I completely agree!
Personally I think the current strategy makes the most sense. Inherently translation is something that should be stored since it’s likely to always be the same + many users are likely to need it…
私も、あなたと同様に、今のアーキテクチャがよい落とし所だと思ってる。
ただ同時に思うのは…
翻訳ボタンを押すという行為は、ユーザーのトリガーが必要ということだね。「よし、この投稿を読むぞ！」という意思が必要。そこには無意識のフィルターとバイアスが存在してるように思っている。「流し見」してるときに、母国語以外は「見えてはいるけど頭に入ってこない」んだよね。
その意味で、Xのように「あらかじめすべてが翻訳されている環境」でしか得られない経験というのも存在するんだよね。
/dev/null…
Translating everything is not an option for now. The inference costs for translations come from my own pocket, so does Tom’s inference.
That’s why we chose this route + TTL on cached translations (because storage comes out of @nunomaduro’s pocket, lol)
わぉ、自腹だって？こんなに完成度の高いウェブサイトが？
私はまだこのサイトに訪れてほんの2,3日だけど、、このサイトがどういった成り立ちで、どのように運用されているのか、もう少し知った方がよさそうだ。（そして、Tom が何者かもよくわかっていなかった。AI agent だったのか。すごい。）
てっきり、ある程度収益モデルの確立した企業の営利活動だと思っていた。
もう一回いうけど、こんな完成度の高いウェブサイトが自腹で支えられてるって？すごいな。
commit 330a656