オープンソースドキュメント翻訳プラットフォームとしての GitHub (React 日本語ドキュメントの例)

はじめに

ひょんなことから React 公式ドキュメント日本語版のメンテナをやらせていただいています smikitky です。

この記事は、React 公式ドキュメントの翻訳作業が GitHub ベースでどのように行われているのかを解説したものです。ドキュメントの翻訳には色々な方法がありますが、React の現アプローチは非常に上手く行っていると個人的に考えています。部分的には似たアプローチを説明している既存記事も探せばありますが、少し詳しめに書くことで事前の不安を取り除き、「思ったより簡単そうだから、自分もあのライブラリのドキュメント翻訳をやってオープンソースに貢献してみよう」と思えるようになることを目標にしています。

想定読者は Git、GitHub、Markdown（ないし類似の軽量マークアップ言語）、および基本的な HTML の仕組みがわかる開発者です。何らかの静的サイトジェネレータを使った経験があればなお良いです。React や JavaScript 特有の知識は特に必要ありません。

前置きが長くなっていますので、結論だけ知りたい方はページの中央くらいまで飛ばしてください。

念のためですが、React 「公式」ドキュメント日本語版は、有志 3 人のメンテナと多数のボランティアによるコミュニティ翻訳で運営されています。メンテナはいずれも Facebook とは雇用関係になく、この記事は React チームの意見を代表するものではありません。

望ましい翻訳作業とは

「オープンソースプロダクトのドキュメント翻訳」の作業環境として、どんなものが望ましいでしょうか。Git を日常使っている開発者であれば、きっと理想的には以下のような感じだと思います。

• HTML などではなく Markdown ベースで処理をしたい。 ビルド成果である HTML をベースにしての翻訳はいろいろ面倒です。（本記事では Markdown で説明していますが、reStructuredText や AsciiDoc や Wiki 記法など類似のマークアップ言語なら同様です。）
• ライブデモやシンタックスハイライトなどの便利機能は残したい。 最近のドキュメントには、デザインに凝ったものや、自分でコードをタイプしながらリアルタイムに試せるものも多くあります。Zenn や自前ブログや自前 Wiki に翻訳を載せても文字だけなら読めますが、読む側の体験は損なわれてしまいます。
• 原文の更新にタイムリーに追従したい。 これは非常に重要です。ドキュメントはある時点のバージョンで 1 回翻訳して終わりではありません。React もそうですが、人気のライブラリであるほど、2 年も経てば使い方が大きく変わります。原文の各ファイルのうち、どれがいつどのように変更されたのか、翻訳で追従できていないのはどのファイルのどの行か、といった情報がすぐに手に入らないといけません。
• 使い慣れたテキストエディタを使いたい。 Wikipedia や MDN には自前のオンラインエディタがありブラウザ上で編集作業ができますが、やはり自分の好きなエディタで作業をするのが一番です。ブラウザしかない時でも、今やオンライン IDE がごく普通に使える時代ですし、そちらの方が多機能で快適です。
• 翻訳結果をローカル環境でプレビューしたい。 翻訳を書いて結果が見えるのが 1 か月後とかだったりすると、モチベ維持は困難です。
• 翻訳結果は Git で管理したい。 Wiki や MDN にも簡単なバージョン管理や差分表示はありますが、その辺はやっぱり Git が最強です。GitHub に草を生やす達成感が得られるか否かでやる気が違ってくる人は多いと思います。
• 文書校正機能が欲しい。 カッコの対応ミス検出、表記揺れを防止するための NG ワード設定機能、全角・半角文字混在の防止機能など。必須ではありませんが、あれば助かります。
• レビューを行いたい。 1 人で作業するなら不要ですが、何十ページもあるドキュメントを離れた複数人が翻訳する場合には、ブラウザ上でレビューやディスカッションする仕組みも欲しくなります。

これらを全部実現できるよ、それもみんなが使い慣れた GitHub 上でね！ というのが本記事の趣旨です。Git やコマンドラインが使える開発者なら、これらのうち大半は 10 分ほどで実現できます。

React チームの過去の失敗

React の公式日本語ドキュメントが無事公開されたのは 2019 年 2 月 26 日です。ぶっちゃけ結構遅かったですよね。「React は日本語のドキュメントがないから採用しづらい、Vue.js の方がいい」みたいな空気がずーっとあったと思います。（まあ今でも React 関連ライブラリのドキュメントはほぼほぼ英語なので同じような空気があるかもですが、それはこの記事を見ているモニタの前のあなたが改善できます。これはそのための記事です。）

実は、翻訳がなかなか出てこなかったのは、React チームが翻訳プロセスの立ち上げに一度失敗したからです。現在の仕組みを説明する前に、先にその話をし、何故ダメだったのかについて自分の考えを説明したいと思います。

React が翻訳プロジェクトを立ち上げて翻訳者を（控えめに）募集したのは、上記より 1 年半も前である 2017 年 8 月のことです。この Issue のこのコメントです。そしてそのわずか 1 ヶ月後には、自分も含む数名の日本人ボランティアの手により、ドキュメント主要部分の日本語訳が、後述する某所で密かに一度完了していました。

しかしそこから 1 年以上、その成果が公式サイトに統合できることはついぞなく、翻訳はほぼ誰の目にもとまることはありませんでした（一部の訳は今のサイトで再利用されているので全くの無駄ではありませんでしたが）。2017 年終わりから 2018 年末まで、「React には日本語ドキュメントがないからダメ」みたいなツイートを見ては、私は「いやもう翻訳はあるんだよ、後は Facebook の React チームが対応して公開してくれるだけなんだよ～」と心を痛めていたのでした。一体何があったのでしょうか。

当時の React チームが選んだのは、Crowdin という SaaS の翻訳プラットフォームです。こういう感じのブラウザアプリです。

大雑把に言うと、Markdown などをこのシステムに放り込むと文の単位に分割してくれ、ブラウザ上で誰かが 1 文ずつ翻訳文を入力していくことでいずれ翻訳が完成する、という仕組みです。複数人が同じ文に別の翻訳を投稿することもでき、その場合は投票で採用するものを決める機能なんかもあります（翻訳右側の「＋」「－」のボタンがそれです）。成果は API を使ってダウンロードする形のようでした。

しかし一見よさそうな Crowdin ですが、使っていると問題が山積みでした。（以下は当時の話であり、現在は改善されている部分もあるかもしれません。また特にインテグレーションの部分は私が担当したところではないので想像も含まれています。）

• まず、翻訳対象の文字情報を準備する作業が大変そうでした。React 公式サイトは最初から翻訳を念頭に作られたサイトではないため、本文は Markdown ですがそれ以外のメニュー項目やらの英語は JavaScript コード内にベタ書きされていました（React ドキュメントは当然 React ベースなので特にそういう傾向が強い）。それらを Crowdin で翻訳できるようにするには何らかのテキストファイルに抽出する必要があり、ドキュメントのリポジトリ構成に大きく手を入れる必要がありました。結局これは実現しませんでした。
• 翻訳後のインテグレーションも面倒そうでした。ビルドシステム（React チームは Gatsby を使っています）に翻訳成果を API 経由でダウンロードさせる追加コードを新たに書く手間がかかります。また、原文に更新があった時に Crowdin にそれをアップロードするのも、少なくとも当時は誰かの手作業でした。
• 最初に Crowdin に翻訳対象のソースを投入した React チームの担当者が、何故か Markdown ではなくビルド後の HTML を放り込みました。お陰で我々翻訳者は <code></code> や <em></em> などを手で何度も書きながら翻訳する羽目に。当時からすごく疑問だったのですが、当時の自分は「React チームなんだから高尚な考えがあるに違いない」と思い込み、問いただすことができませんでした。多分ですが、これは単純ミスでそうなったというより、結局のところ Crowdin を既存のビルドプロセスに統合するのが面倒でこうなったんだろうと思っています。「HTML ベースなら静的に公開しとけば最低限動くんじゃね？」という発想だったのでしょう。
• 翻訳結果を翻訳者がローカルでビルドして確認する手段が一切なく、タグミスなどがあっても気づきにくい状態でした。
• 「ドキュメントを文に分割する」の挙動が不安定でした。流石に "Mr." とか "etc." とかのピリオドで間違うほどではありませんけど、<code></code> 中のピリオドなどで誤反応して 1 文が中途半端に分割され、「どうすりゃいいの」みたいな状況にしばしば陥りました。
• ファイル内でどれが翻訳対象なのかの区別も曖昧でした。Markdown の中にはコードサンプルやフロントマター内の ID など、翻訳してはならない場所も結構あり、その辺の区別は人が見れば自明でも機械には困難です。未翻訳で残していると進捗表示が 100% にならず気持ち悪いため、原文と同じコードサンプルを翻訳文欄にコピーして翻訳済みとして保存する、みたいな無駄な作業を強いられました。
• 校正機能も日本語特有の事情を考慮したものではなくイマイチでした。例えば「原文にカッコがあるのに翻訳文にカッコがないと警告を表示する」みたいなチェック機能があるのですが、全角カッコというものを Crowdin が知らないため警告だらけに。
• 同一文検出機能もお節介でした。同じ表現が 2 度現れると翻訳済みとしてマークして翻訳不可にしてくれる機能があったのですが、英語で同一の表現でも日本語だと文脈により訳し分けることはザラにあります。例えば product の訳語が「製品」「生成物」「プロダクト」のどれになるかは文脈を見ないと分かりません。
• 編集したい人が勝手に編集する Wiki 的なアプローチのため、メンテナがレビューして質を確認するみたいなフローは実現が困難でした。

個別に見れば絶対無理というほどの問題ではありませんが、総合的には慣れない Crowdin を使って React のような長文ドキュメントを翻訳するのはツラかったです。React チーム側も「見切り発車で Crowdin 始めてみたけど、この方針に自信がないので前に進めない、でも地味にとはいえ貢献者募集しちゃったし戻れない」みたいなジレンマに直面して動きが止まっているようでした。

念のためですが Crowdin が常にダメというわけではなく、Git を使えない翻訳者と作業する時や、最初からローカリゼーションを意識して数十カ国語対応のアプリを構築する場合などには有力な選択肢だと思います。後付けでポンと導入すれば楽できる、みたいなものではなかったよ、という話です。

本家のドキュメントリポジトリ内に言語別のディレクトリを作って管理するというのもよくある手法だと思います。React 界隈だと react-hook-form がそういうアプローチを採用しています。しかし React 公式ドキュメントサイトの規模になると、本家ドキュメントリポジトリにはすでに多数の Issue やプルリクが溜まっている状態（常に 500 個を超えています）であり、そこにさらに数十言語分の Issue やプルリクが集結して多言語でやりとりするという状態は、管理不能に陥ることが容易に想像されました。

現在の React ドキュメント翻訳プロセス

ここから本題です。結局 2019 年 1 月に、React チームは Crowdin とのインテグレーションをすっぱり諦め、全く別のアプローチをとることに決めました。そのアプローチとは、これです。

ドキュメントの Git リポジトリを単にフォークして「ja.reactjs.org」などと名付け、Markdown や JavaScript 内の原文を単に翻訳します。yarn build とかで単にビルドし、その成果を単に別サイトとして公開します。以上。

今時、公式サイトがある規模のオープンソースプロダクトなら、ドキュメントはほぼ間違いなく静的サイトジェネレータで作成されており、package.json やそれに類するものを眺めればビルドできるようになっているはずです。作者や言語次第で Jekyll だったり Docusaurus だったり Sphinx だったり GitBook だったり Gatsby だったり Nuxt だったりすると思いますが、基本どれも同じ要領です。なのでフォークしてクローンしてお好みのエディタで開けば、ドキュメント原作者とほぼ同じ環境で翻訳をすることが可能です。Markdown や JavaScript ファイル上の翻訳すべき英語を、ただ日本語に置き換えていくだけで構いません。コメント等で原文を残したりする必要すらありません。ローカルでのライブプレビューも（普通は）全部ありますし、リアルタイムデモなどのユニークな機能も、同じ物が手元で動きます。

これはとてもシンプルですが、逆にシンプルすぎて「本当にこれでいいの」みたいな疑問が湧いてきそうです。そもそも GitHub は翻訳専用のプラットフォームでは決してありません。色んな面で無理や問題が出てきたりしないのでしょうか。

結論を言えば、びっくりするくらい問題ありませんでした。

原文への追従

本家サイトの原文に変更があった場合に日本語版で追従するという作業、一見難題のように思えます。が、何のことはなく、Git の基本機能がほぼ完璧に仕事をしてくれます。フォーク元である原文リポジトリ (upstream) を定期的にマージするだけでいいのです。

https://qiita.com/xtetsuji/items/555a1ef19ed21ee42873

# フォーク側で原文リポジトリ(upstream)をマージする
git fetch upstream
git checkout master
git merge upstream/master

そもそも翻訳対象でないファイルや、翻訳済み記事の翻訳不要な部分（コードサンプルなど）は、これ一発でさくっと原文の最新版に同期します。既に翻訳済みの場所で原文に変更が起きた場合、コンフリクトが発生します。そこが翻訳を更新しないといけない場所だということです。

この git merge の方法は、普通のソースコードのパッチ版とかをメンテする時に上手く動くことは知っていたのですが（上記リンク参照）、翻訳でもうまく動くのかどうか、自分はよく分かっていませんでいた。なにしろ翻訳の場合、原文ファイルと翻訳後のファイルでは中身のほぼすべての行が書き換わっています。Git のマージがそんな状況でも果たして使い物になるのか。

これは全くの杞憂でした。Git のマージ機能は自分が思っていたよりずっと優秀です。英語だけで書かれたファイルと 9 割以上日本語に書き換わっているファイルをマージしても、ほぼ間違いなく原文と訳文を対応づけて正しい位置にコンフリクトを発生させてくれます。多分空行の位置や翻訳していない関数名などのキーワードまで見てくれているのかなと思いますが、日本語のことなど何も知らない Git が機械的なマージだけでここまでやってくれるというのは驚きでした。

マージ絡みの詳細

• どのくらい有効なのか詳しく検証はしていませんが、妙な空行や改行があるとそこで位置ズレが生じそうなので、「翻訳前と翻訳後で行の数や位置を厳密に一致させる」というルールにし、レビュー時にチェックするようにしています。例えば原文で 120 行目にある見出しが翻訳後に 121 行目に来ていたらミス扱いにしています。
• 大量の記事が新たに追加されたような場合は、一旦翻訳せずとりあえずマージして公開しておき、後から翻訳することもできます。
• 原文のページ途中に新しく段落が追加されたような場合、マージが賢すぎて「訳文中の正しい位置にその英文が挿入されるけどコンフリクトは生じない」、ということが起きます。コンフリクト部分だけ作業していると気付かず未翻訳のままになりがちなので注意が必要です。

原文への追従を bot で行う（オプション）

上記のマージを定期的に手作業でやるのでも構いませんが、git commit/pull/push 以外のコマンドをろくに覚えていない私のような人間は頭がわりと混乱しがちです。また未マージの作業がどのくらい残っているのか可視化されていないため、「いざマージしてみたら大量のコンフリクトがあってうんざり」「いざ時間を作ってマージしてみたらしょうもないコミット（英語側の誤字修正とか）だけでがっかり」みたいなことになりがちで、案外つらさを感じると思います。

というわけで React ドキュメントサイトでは、マージ作業の一部を週に 1 度ブランチ上で行ってプルリクを作ってくれる、素敵な bot が走っています。ソースコードはこちらです。現在この bot は毎週月曜日に起動し、概ね以下のような動作を行っています。

• フォーク側の master から新しいブランチを生やし、
• git merge upstream/master して本家のコミットを取り込み、
• コンフリクトが起きてもお構いなしにコンフリクトマーカーごとコミット（git commit -a）し、
• そのブランチを push してプルリクエストを立てる。コンフリクトがあったファイル（≒翻訳後に原文に更新があったファイル）をプルリクの概要欄にリストし、人間の対応を促す。

実際のプルリクは以下のような感じになります。

コミットグラフは以下のような感じになります。赤がフォーク（日本語版）、水色が bot による自動コミット。上記のプロセスが 2 回発生したときの例です。

一旦ブランチ上でコンフリクトマーカーごとコミットしてしまうというのがミソです。チェックアウトした時点で既にコンフリクトマーカー付きというのは、ちょっとタブー感あって自分には思いつかない発想ですが、実用上はこれがとても便利でした。原文にどんな変更があり、どこでどのように原文とのコンフリクトが発生しているのか、GitHub のプルリクページで簡単に一覧できるのです。

われわれ人間は、コンフリクトマーカー入りのプルリクをチェックアウトし、翻訳を原文に合わせて更新してコンフリクトマーカーを剥がし、コミット・プッシュし、Web 画面上でプルリクをマージします。原文の誤字訂正などの場合は翻訳文を変える必要がないのでただマーカーを剥がします（VS Code なら 1 クリック）。これで本家コミットがフォークに無事取り込まれたことになります。個人的には、普段の追従作業が git checkout → git commit → git push だけで完結し、git merge を手で打たなくて良いというのは精神衛生上かなり良いです。

誤字修正など重要でないコミットしかなかった週のプルリクは単に放置しておけば、次の週に未処理分を含んだ新たなプルリクが作成されますので、古いものはクローズして構いません。作業をサボった場合、bot が作った最新のプルリクには本家に追いつくまでにその時点でやるべき作業が一覧表示されており、それが少しずつ増え続けてプレッシャーを与えてくれます（むしろこのプレッシャーが bot の最大の存在意義かもしれません）。

この bot は Heroku で無料で動いているのですが、今なら GitHub Actions で動かす方が遙かに楽で使いやすいと思います。理想的には .github/workflows/merge.yml のようなファイルをリポジトリに 1 個置くだけでセットアップが完了するはずです。

成果物の公開

翻訳した新サイトは、Netlify や Vercel のようなビルド＆ホスティングサービスを使って公開し、GitHub にプッシュするだけで自動でデプロイされるように構成しましょう。React 公式ドキュメントは Netlify を使っています。使い方は簡単ですし検索すれば幾らでも出ますので割愛します。余程のことがない限り無料で運営できると思います。ドメインは hogehoge-ja.netlify.app のようなもののままでもいいですし、hogehoge-ja.js.org のような js.org のカスタムドメインを取るのも良いでしょう。

React の場合は React 本家が音頭を取って作られたフォークでしたが、自分でフォークしたものの場合はオリジナルの作者に連絡を取り、翻訳サイトをリンクしてもらうことも忘れないようにしましょう。相手に理解してもらうために React ブログのこの記事を紹介するのもいいかもしれません。

校正機能を追加する（オプション）

React 日本語版フォークでは独自に、textlint という校正システムを導入しています。「和文と欧文の間に半角スペースを入れる」「ハンドラー ではなく ハンドラ と表記する」みたいな、参加者が多いと守ってもらうのが難しい細々とした固有ルールの面倒を見てくれます。手でコマンドとして起動することもできますが、husky を使ってコミット前フックをセットアップしていますので、参加者全員が自動で確認できる仕組みになっています。

これを導入して以降、レビューの手間が激減しました。textlint のデフォルト設定や既存プラグインだけだと過剰検出や足りない機能もあるのですが、そこは自分たちでコードを書くことで幾らでも調整可能です。

なにしろフォークなので、ソースコードは全部手元にあっていざというときに自由自在にできるというのは、この仕組みの強みです。他の日本語版独自の調整として、日本語を <em> で囲んでもイタリックで表示されない件への対応も入っています。アラビア語などの RTL 言語もそれぞれの事情に応じて頑張っています。

スラグ ID の調整（オプション）

Markdown の見出し (#, ##, ...) からは通常パーマリンク用の ID が自動生成されています。## Example App が <a id="example-app"><h2>Example App</h2></a> になる、みたいなものです。React のように記事間での相互参照が多いドキュメントでは、この ID が変わってしまうとリンクの維持が面倒です。何より日本語の見出し文字列から自動生成されるスラグは解読不能です。

どうすべきか議論があったのですが、結局ここだけは原文のリポジトリに手を入れ、原文 Markdown ファイル内で常に ID を固定で指定してもらうことにしました（プルリク）。フォーク前に原文 Markdown の ## Example App という行をスクリプトで ## Example App {#example-app} にするような一括置換をやっておけば、各言語の翻訳者は見出し文字列（前半部分）を単に翻訳して ## アプリの例 {#example-app} のようにすることで ID が保たれます。React のドキュメント翻訳で、唯一あらかじめ原文リポジトリに手を加える必要があったのはここです。

完璧を期すならこの作業は必要ですが、手作業で何とかなるレベルならそれでもいいかもしれません。

このワークフローの利点と欠点

「好きなエディタが使える」「ローカルプレビューできる」「自在にカスタマイズできる」などの利点は既に述べましたが、この方針の最大のメリットはとにかく立ち上がりが速く、Git さえ分かっていればプロセスがとても理解しやすいことだと思います。変にビルドに躓いたりしない限り、10 分で翻訳作業が開始できます。1 年以上にわたって Crowdin との統合ができず悩んでいた React チームでしたが、方針転換してからあっという間に多くの貢献者が集まり、最初の日本語版公式サイトが公開できるまで、わずか 1 ヶ月しかかかりませんでした。

今のところ欠点として思いつくのは以下のような感じです。

• Git やコマンドラインを扱えない人にはこのワークフローは厳しい。
• Crowdin と違って作業の進捗状況をリアルタイムにグラフ化してくれたりまではしないので、進捗状況は別途管理する必要がある。（メンテナが GitHub Issue や Google Spreadsheet などで手作業で管理するだけで大抵は問題ないはず）
• 翻訳成果が複数のリポジトリに分散しているため、どの記事が翻訳済みかなどが一元管理しづらく「この記事を他の言語で読む」みたいな機能は実現が難しい。（原理的には git submodules などを使って一元的なビルドも可能だと思いますが）
• 複数のリポジトリによる分割統治なので、各言語のメンテナが追従をサボると悲しいことになる。例えばある時点で React 17.0 が出てそれなりに経過していたのに、カタルーニャ語とベンガル語とギリシャ語とインドネシア語版の React サイトに行くとトップはいまだに 16.x のままだった、などということがありました。
• サボってなくても本家への即座の追従はできない。React サイトはブログ記事も他のドキュメントと同じように Markdown で管理・ビルドされているので、bot のスケジュールに合わせて作業をしていると 1 週間はラグが生じます。「未翻訳でいいから最新のブログ記事をすぐ読みたい」という人には問題です。React はそこまでできていませんが、速報性が重要な部分だけヘッドレス CMS を使って動的に取得するようにするなど、他の技術と適宜組み合わせるのが良いと思います。

（おまけ）React ドキュメントの現在と今後

2019 年 1 月に日本語版のメンテナを引き受けた時点では、内心「誰も翻訳には興味なさそうだし、何だかんだまた極少数の人で作業する感じかな」と思っていました。私にはエンジニアの人脈などほぼなく、何しろその時点で既に 1 年以上放置プレイ食らっていた状況でした。

ところが、同じくメンテナとなった koba04 さんや potato4d さんがツイートで呼びかけた瞬間、何十人もの翻訳者が集まってくださいました（あとで 2 人が有名人だと知りました）。私は翻訳作業ではなく、レビューしたり環境を整えたりという真にメンテナ的な役目に回ることになり、上記の通りわずか 1 か月でドキュメントの翻訳がほぼ完成し、公開されることになりました。2020 年以降は余裕も出てきたので新着ブログ記事の翻訳も行っています。

まあ今になって思うのは、繰り返しですが「やっぱみんな使い慣れたエディタと GitHub で作業したいんだね」ということです。Git ベースでなかったら、あんなに沢山の人が集まって一気呵成で作業が進むようなことは、きっとなかっただろうと思うのです。

さて今後の話です。今の React ドキュメントは、React 自体の進化に合わせて昔の記事をベースに増築を重ねた結果、大変見通しが悪くなってしまっており、「わかりづらい」「今のベストプラクティスが反映されていない」という不満が出る状態となっています。チュートリアルもいまだにクラスベースですし。フックの書き方を理解するためにあらかじめクラスでの書き方を分かっていないとドキュメントが理解できないというのはそろそろ悲しいです。

本家でもその辺は認識しており、2021 年内を目標に、フックと関数コンポーネントをもっと前面に押し出し、いろいろ古くて微妙になっている記載も新しくした完全な新ドキュメントに移行することが発表されています。自分もチラ見させてもらっていますが既存ドキュメントはほぼ何も残らないレベルの大改変になります。その際にはまた皆さんの翻訳の協力が必要になる可能性が高いので、よろしくお願いします。

最後に

この翻訳の仕組みは、React オリジナルではありません。フォークベースの翻訳自体は結構されていますし、元々 Vue.js のドキュメントもフォークベースだったのを React チームがパクｒ参考にしたものです。というかうちのメンテナである potato4d さんは Vue.js 公式ドキュメントのメンテナでもあり、「bot で原文の翻訳に追従する」「textlint を使う」などは元々 Vue 日本語ドキュメントチームのアイディアです。

「React チームが設計上の問題に直面した時に最初にやることは、Vue がどうしているかを調べることである」 ー Nat Alison, "Is React Translated Yet?" at React Conf 2019