Crowdinを導入してwebページを国際化(i18n)したい

[Hiroshiba]

内容

結構海外からの需要もあるので、webページの国際化を視野に入れています。
特に歌は国境を余裕で超えるので。

i18nサービスはCrowdinを考えています。
OSS向けにいろんな機能が解放されていて、VOICEVOXもOSS審査に通ったので使わせてもらおうかなと。
（あとMisskeyも採用していて知見が集まりやすそうだったので）
実際にCrowdin内でVOICEVOXプロジェクトも作ってます。 https://crowdin.com/project/voicevox

進捗を一覧化したいのと、ちょっといくつか知りたいことがあってissue化しました。
知っている方がいたらぜひ助言ほしいです！　調査結果もぜひ知りたい！

迷っていること

• 翻訳ファイルのファイル形式
• 翻訳ファイルのディレクトリ構造

翻訳ファイルのファイル形式は２つありそう：

• すべてのページでレイアウトファイルを作り、markdownのfrontmatterでテキストを注入する
  • Misskey Hub（VuePress？）がこの形
  • 元がmarkdownなページも結構あり、等しく扱える
  • markdownの中でyamlを書く感じになり、フォーマッターやリンターなどと相性が悪そう？
  • Crowdinのmarkdown翻訳はWYSIWYGにも対応してそうで便利そう･･･？
    • CrowdinのWYSIWYG機構がなんなのか、Astroでも動くのか、そもそもどういうUXなのか不明
  • 翻訳ファイルとページファイルの行き来でコードジャンプが使えなそう
    • とはいえファイル名でジャンプすれば良いのでそんな問題ではなさそう
• yamlかjsonファイルでテキストを管理し、ページ.astroから読み込む
  • よくある形？
  • リンター等との相性は良さそう
  • JSの範疇でimportするので、ページ→翻訳ファイルへはコードジャンプできそう
  • ページによってyamlになったりmdになったりしそう
    • そんな問題ではなさそう？
  • CrowdinがWYSIWYGに対応してなそう
• yamlかjsonとmdごちゃまぜを試してみるのが良さそう･･･？

翻訳ファイルのディレクトリ構造も２つありそう：

• 翻訳用のファイルを１ディレクトリに集約する
  • ページと同じディレクトリ構造にする
  • ページURLが変わらない限り場所が変わらないので、Crowdin連携がしやすそう
  • 翻訳ファイルとレイアウトファイルを行き来するのが少し面倒そう？
    • ファイル名でジャンプすれば良いからそんなでもないかも
• ページファイルの近くに翻訳ファイルを置く
  • 行き来しやすそう
  • 静的サイトジェネレータによってファイル構造が変わるなど、Crowdin連携は不利そう
    • マッピングとか管理できれば良いけど、できるのか不明なのと少し管理が面倒そう
  • Astroならこれも可能だけど、他のサイトジェネレータでサポートされないかも
• これはメンテ性考えてディレクトリに集約したほうが便利そう。
  • （追記）astroはページ.mdがそのままURLになるので別ディレクトリに集約は無理そう！

あと転ばぬ先の杖として知っておきたいこと：

• Crowdinはmarkdownファイルを行ごとに翻訳可能なのか
  • 翻訳されてないとこはソース言語のものが勝手に採用されてほしいけど、できるのか
  • 例えば英語記事の中で未翻訳のとこが一部だけ日本語になってる、みたいなのが可能か

その他

Crowdin導入に興味ある方も募集中です。一緒に作りませんか。

[Hiroshiba]

動作確認しようとしています。
やったことメモを追加していきます。

org全体にsecrets.CROWDIN_GITHUB_TOKENを設定。PATの権限はこれ、対象はVOICEVOX/voicevox_blogのみ。
secrets.CROWDIN_PROJECT_IDを設定。
secrets.CROWDIN_PERSONAL_TOKENを設定。必要な権限がわからない。Projects全部のR&Wを設定。

[Hiroshiba]

実際にいろいろ試してみて大体わかりました。
導入しても良さそうな直感です。

---

Crowdinはmarkdownファイルを行ごとに翻訳可能なのか

可能。

例えば英語記事の中で未翻訳のとこが一部だけ日本語になってる、みたいなのが可能か

可能。

---

所感やメモ：

翻訳は（設定次第だけど）誰でも提案できる。
提案が一括りになっているのではなく、翻訳対象のテキストごとに提案が一覧表示される。
誰でも提案に対してvoteできる。
権限を持っている人はapproveもできる。approveされたものだけがPRに含まれる。（ように設定した）

ファイル移動はたぶん相当不便。Githubで翻訳元のファイルを移動してもCrowdinは追従してくれない。
Crowdin側でリネームすれば追従してくれるかも。でもしっかりしたファイラーUIはなさそうなのでしんどそう。
なのでパスが変わらないよう、すべてのページ.mdファイルは/ページ/index.mdとしたほうが良さそう。

ちなみにGithub側の翻訳をCrowdin側に送るようにもできる。
けど事故りそうなのでオフにしたほうが良さそう。

どのファイルでも翻訳元の文章を変えると、自動的に翻訳がリセットされる。
jsonファイルの場合はキーが同じであれば、crowdinがweb UI上でサジェストしてくれる。ちょっとわかりづらいけど。
mdファイルの場合はキーがないのでほとんどサジェストは見込めなそう。crowdin側で過去の翻訳を検索すれば参考になりそうだけど、だいぶ不便そう。

approveの仕組みはあるけど、レビューの仕組みはない。（あるらしいけどenterprise限定）
機械翻訳した大量の提案が届いたりしたらどうすれば良いのか不明。届いてから考えるで良さそう。

VSCodeアドオンがあるらしい。 https://marketplace.visualstudio.com/items?itemName=Crowdin.vscode-crowdin
慣れている人はこれでライブ編集するととても便利そう。
自由にキーや行を追加できる気がするけど、そのあたりどうなるのかは未調査。

Astro側にもi18nの仕組みがある。
https://docs.astro.build/en/guides/internationalization/
https://docs.astro.build/ja/recipes/i18n/
けど、実装コストに比べて将来的な移行コストがしんどそうなのを考えると依存しないほうが良さそう。

i18n加味したアセット（キャラ名・呼び方・記事など）のimportをどうすべきかは思いついてない。
_strings.jsonもそうかも。
vite.import.globで**/path/to/_strings.jsonなどとして全部取ってきて、後はターゲットlocale一覧を元にフィルタするしかなさそう？
jsonの型は･･･ちょっと不格好になるかもだけどなんとか得られそう。
画像のローカリゼーションとか入るとなかなか大変なことになりそう。

言語切替はスイッチャーをヘッダーに追加して、URLに従ったページが案内される形で良さそう。
crowdinの仕様的にすべてのターゲット言語のすべてのファイルは一応揃うので、ページが存在しないことはなさそう。
この仕様ならクッキーだとかリダイレクトだとかを考えなくて良さそう。

ただそうすると記事などはほとんど翻訳されないだろうから、HTMLの言語設定と違う言語が表示されることが多そう。
SEO的に大丈夫か不明。完全に未翻訳なものはnoindexになるようにしても良いかも。翻訳率はCrowdinのAPIで取得できそうだけど、Github側のファイルと突き合わせるのに少し実装が必要そう。
SEOというか検索エンジンに優しいようにhreflangは設定すると良さそう。
https://developers.google.com/search/docs/specialty/international/localized-versions?hl=ja