バックエンドの多言語対応の仕様を考えよう

[kakkokari-gtyih]

メール送信やサーバーサイドエラーなどでバックエンドのi18nは重要だけど、かと言ってサーバーサイドでしか使わない文言をフロントエンドに流すのも無駄なので具体的にどういう実装（ディレクトリ構造）にするか考えたい

関連Issue:

• Signup email not translated #11060
• Make the error page translatable so it can be localized #13472

[kakkokari-gtyih]

メール送信やサーバーサイドエラーなどでバックエンドのi18nは重要だけど、かと言ってサーバーサイドでしか使わない文言をフロントエンドに流すのも無駄なので具体的にどういう実装（ディレクトリ構造）にするか考えたい

ご意見募集中

[samunohito]

そもそも、ニーズがあるのかしら…

[Sayamame-beans]

どちらかといえば、バックエンドのエラー表示がそのまま表に出てきていること(何箇所かあったはず?)が問題なのではないかと推測…
(クライアント側ではなくサーバー側のログにだけ出るものに関しては、問題無いのではと個人的には思ったりします。Misskeyとしての第一言語が日本語なのであればそちらに移るのはアリかも?)

そのため、バックエンドではi18nせずに、返ってきた内容を元に、特に必要なものに関しては(エラーメッセージの一種として、他のテキストと同じ様に)フロント側でi18nして表示してあげた方が良さそう…ですかね?

[kakkokari-gtyih]

• Signup email not translated #11060
• Make the error page translatable so it can be localized #13472

[samunohito]

バックエンドのi18n化をする方法を考える前に、

• なぜバックエンドにi18nが必要なのか（課題は何処か）
• どこをi18n化すべきなのか

を整理したほうが良さそう…？

[kakkokari-gtyih]

• メール系の翻訳（メールを使用する機能の実装がいくつか提案されているので取り組んだほうが良さそう）
• エラーページ系の翻訳（サーバーエラー(fastifyのエラーハンドラ)の場合はフロントエンドでケアできない可能性がある）

[GrapeApple0]

個人的にはクライアントがまず見ないであろう部分を多言語化してもメリットはそんなに感じられませんし、エラーの部分はフロントエンドでカバーするかdocsにまとめればいいと思っています
メールについてはsignup時に言語を選択できるようにするか、クライアントの使用している言語をバックエンドに送信してそれに合わせてメールを送信すればいいと思います

[kakkokari-gtyih]

メールについてはsignup時に言語を選択できるようにするか、クライアントの使用している言語をバックエンドに送信してそれに合わせてメールを送信すればいいと思います

メール用の文言をどういうふうに保管するかを決めあぐねているんですよね…
メールの文面をフロント向けの言語ファイルに含むのって無駄じゃないですか

[GrapeApple0]

バックエンド直下にemail-templateというディレクトリを作ってそこにhtmlなどのテンプレートを置いてそれを都度呼び出すやりかたがあるかなって思いました