何処から手を付ければ良いか分かりにくい問題

[dynamis]

翻訳ステータス一覧ページ、未訳ページリストなどの機能が Yari 以降存在しない (参考 #593) し、タグによる検索機能も無くなってしまっているように思う (参考 #242) 現状、翻訳したいページが明確にあって参加する人手は無い、取りあえず簡単なところから翻訳に貢献してみようという人が何処から始めたら良いか分かりにくい状態になってしまっているように思う。

以前は Good First Translation タグを使って分かり易くする試みもしていた
https://github.com/mozilla-japan/translation/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+First+Translation%22
がそれが続いていないまたはメンテナンス出来ていない。

特に用語集とか Beginner タグのついたページなどは今でも最初はその辺りからどうぞといいたいのだけど、未訳リストを確認する簡単な方法がない (無さそうに見えている)。

Github を使った操作も色々慣れる必要もありその説明だけで結構一杯になっている https://github.com/mozilla-japan/translation/wiki/Get-started-with-translation-of-Mozilla-documentations 状況で、新規貢献者の参加障壁が高い状態になってしまっているように思う。

Meetup を毎月して個別フォローすることはしているが、もうちょっと何とか出来ないものか。

[debiru]

2022年2月から翻訳グループのSlackに参加した debiru ですが、必要性を感じて2月中に https://mdn.lavoscore.org/ の初版を公開しました（3月に毎日更新にしました）。

Yari が何なのかよく分かっていませんが（新しい何かという印象）、以前には MDN翻訳状況 なるスプレッドシートがあったことを教えてもらいました。

話は変わりますが、参考程度に、MDN翻訳グループに参加した「初めてさん」の立場で思ったことを書いてみます。

• 初めて翻訳グループに参加して思ったこと（作業手順について）
  • 2022年2月のオンライン開催が初参加です。以下はオンライン開催での流れについての話です。
  • 「みんなで MDN を翻訳しよう！ 翻訳コミュニティ月例ミートアップ」を読んで、作業を進めてくださいと言われた。
  • まず、content リポジトリと translated_content リポジトリの fork と clone をした。
  • 次に、yarn install と yarn start の手順をやるところで、yarn install をどのディレクトリでやるのか分からなくて迷った。
    • 参考：スライド 3-2
    • その後理解して、スライドの clone すべきリポジトリとそのディレクトリ構成を分かりやすく書き直した。
  • localhost:5042 でローカルプレビューができるようになった。
  • MDNが2022年3月2日にデザイン変更したけれど、ローカルプレビューで新デザインを適用する方法が分からなくてSlackで聞いた。
    • yari リポジトリを clone して .env を作成して CONTENT_ROOT と CONTENT_TRANSLATED_ROOT に各リポジトリのディレクトリパスを書いて、yari ディレクトリ内で yarn start ではなく yarn dev すれば localhost:3000 でプレビューできることを教えてもらった。
  • といったローカルでのプレビュー環境構築だけでも情報がまとまっていない印象を受けました。
    • チャットで丁寧にフォローしてもらえたのでメンバーに対する不満はないですが、マニュアルの整備という観点でもう少し体系的に整理したいなという思いが2月からあります。
• 翻訳すべきページを探す、翻訳作業について思ったこと
  • 冒頭の話ですが、無くて困ったので2月の当日作業を終えてから https://mdn.lavoscore.org/ を取り急ぎ作ってみました。
  • 「MDN の場合は対象ページが無限 (ではないが多すぎる) なので各自手を上げていく方式」というボトムアップ方式になっていて、それはそれで悪いわけではないですが、個人的には達成度や品質の統一を含めた計画的なトップダウン方式でやるべきではないか（つまり、多いとはいえ有限なのでページリストを作成して進捗率などを管理したい的な）という思いがあって、できる範囲で詳細なページリストを作ってみたという経緯です。
    • MDN翻訳状況 では計算されていたらしき「翻訳度」を算出したいなと思っているところです。
• その他、気づいたこと
  • ページリストのJSON作成だけでなく、裏で1日ごとに「MDNから削除されたページ」を導出しています。
  • MDNページ一覧監視表 最下部にある、C列が removed-* や deleted-en-* となっているURL
  • それを見ると、英語版のURLが変更になったり、ページがまとめられたりしていることが月あたり「30ページ 〜 300ページ」くらいあったりしていて、せっかく翻訳しても「日本語版にゴミファイルが残ってしまう」ことが起きたりしているなと思っています。（英語版のURL変更作業時に日本語版もきちんとメンテされていることもある）
  • 例えば https://mdn.lavoscore.org/removed/ は、たまたま3月にスナップショットを取ったときのページリストです。（これ全部がゴミになっているというわけではないです）

このスレッドの話のネタになればと思って書き出してみたので上記はまとまりがないですが、色々と改善できそうなところはもうちょっと何とかしていきたいと思っている所存です。

[debiru]

mdn/translated-content#7628 (comment)

People of the ja community wants to know which file should be updated, but no good way was found.

This applies to all the other locales from what I've heard. Right now, there's no good way to determine which files should be reviewed and updated first before others -- the only statistic everyone has to go on is the date of the last time the file was modified, or whether the file has been converted to Markdown.

（機械翻訳）

jaコミュニティの人たちは、どのファイルを更新すべきかを知りたがっていますが、良い方法は見つかりませんでした。

これは、私が聞いたところでは、他のすべてのロケールにも当てはまります。今のところ、どのファイルを他のファイルより先にレビューして更新すべきかを決定する良い方法はありません -- 誰もが持っている唯一の統計は、そのファイルが最後に変更された日付か、そのファイルがMarkdownに変換されたかどうかだけです。

我々がどのファイル（ページ）を新規翻訳あるいは（追従漏れ、翻訳漏れ、誤字脱字等について）更新すべきかを判断するための指標となる値の可視化ができない、できていないという状況があるようです。

例えば思いつくのは、MDNページにJavaScriptベースのアクセス解析があれば、「日本語ユーザのブラウザから、日本語版が存在せず英語版が参照されることの多いページ」などを導出したり、もっと直接的に「エンドユーザからのフィードバックを受け付けるフォームを用意して、新規翻訳あるいは更新が求められるページ」を導出できるようにするといった試みが（それが効果的かどうかは別として）考えられます。

現状だと上記でコメントされている通り、「そのファイルの最終更新日」や「html形式でなくmd形式になっているか」くらいしか指標がなく、更に、前者については軽微なフォーマットの一括修正などでファイルが更新されていると、本質的な更新日が古くとも最終更新日が新しくなってしまい、最終更新日という指標があまり参考にならないということもあります。

また、前のコメントでも少し触れましたが、以前には各ファイルについて「日本語版があるかどうか（翻訳されているかどうか）」だけでなく、各ファイルの翻訳率（点数）が計算されていたらしきことも気になっています。翻訳率が点数として可視化されれば、日本語ファイルが存在するページについても、修正の必要性が可視化でき有益そうに思います。

翻訳作業をすべきファイルを見つける方法について、何かアイデアはないでしょうか？

[mfuji09]

一応、いま mdn/mdn-community#129 で検討されている方法として、各記事のヘッダ部分に、翻訳時に下敷きとした英語版記事のコミットIDを加えるという方法が提案されています。
各ページのフロントマター部分に以下のようなタグを埋め込むことで、英語版のどのコミットに対する版であるかを明らかにし、そこから何コミット分進んでいるかなどを把握できるようにしようという考えです。

l10n:
  sourceCommits: <コミットID>

これについては、正式なドキュメントがないので、ドキュメント化をするようにお願いしています。

[debiru]

なるほど、そういうことでしたか。その sourceCommits の情報はある程度役に立ちそうですね。

ただ、英語版の軽微な修正の発生など、実際は日本語版が追従できているのにコミットIDが最新ではない、というような状況が頻発しそうな気がしていて、うまく運用できるものなのかなという気もしています。

（設計的に）本当に上手くいく方法が実現できればよいのですが。

[mfuji09]

BCD の件のように、少量の修正でも軽微な修正ではないという物もあるので悩ましいですね。
根本的には mdn/content の変更履歴を監視することが一番確実なのですが、あまりに回転が速くてとても追い切れませんし・・・。

[debiru]

browser-compat-data リポジトリと英語版だけ修正（変更）されていて、翻訳側が放置されるという形の不具合も起きているようです。

• Change browser-compat for individual input types mdn/content#16085
• Rename individual input types from input-* to type_* mdn/browser-compat-data#16295

browser-compat: html.elements.input.input-date

このようなBCD queryがありますが、上記はこのキーワードが変更されたというケースです。日本語ページでは変更前のキーワードになっているので既に機能していません。

こういうケースで日本語版が「追従漏れ」してしまう問題があるようですが、これに対応できるような運用方針も考えていきたいですね。

（余談ですが、上記の問題の修正については私が着手しようとしましたが、一括 Markdown 化が並行して作業されているので Block されている状況です）

[debiru]

こういうケースで日本語版が「追従漏れ」してしまう問題があるようですが、これに対応できるような運用方針も考えていきたいですね。

引数付きの Compat マクロを使っている箇所を全て引数なしに変える必要がありますが、このケースは mdn/translated-content#7858 のおかげで今後は発生しなくなりますね。