Decide on translation of some terms
smikitky opened this issue · comments
While reference-glossary.md is helpful, translators need to agree on words that are commonly used throughout the document but are less React-specific. Let me continue this in Japanese.
1年半ほど前に書いたReact日本語版ドキュメント翻訳者用メモがあり、Crowdinの訳はだいたいそれに基づいているのですが、ちょっと幾つかの用語について不安になってきました。特に新しい人もいらっしゃっているので意見を聞ければと思います。
- imperative code は「手続き型コード」とすべきでしょうか「命令型コード」とすべきでしょうか。Wikipediaによれば両者ほぼ同義らしいですが、個人的には「手続き型」の方に圧倒的に馴染みがあるため、そっちでもいいのかなという気もしています。
- reconciliation と reconciler の訳についてご意見はありますか。初歩的な記事で「リコンシリエーション」を使いまくると意味不明になりそうですが、一方で、内部実装系の記事 (fiber reconcilerの新機能とか) では避けて通れない用語でもあります。最初は「突き合わせ処理 (reconciliation)」か「擦り合わせ処理 (reconciliation)」から始めて、踏み込んだ記事で「リコンシリエーション」「リコンサイラ」に移行するような感じが無難なのかなと感じています。
- render / rendering は「レンダー」で、renderer は「レンダラ」で、それぞれ統一してよさそうでしょうか。「3音以上の語は原則伸ばさない」というJISの法則に従えば「レンダ」になるはずですが、感覚的にあまり馴染みがない感じがしています。
- higher-order component を「高階コンポーネント」」ではなく「高次コンポーネント」とすべきというご意見の方はいらっしゃいますか。
- render prop を「レンダープロップ」とカタカナにするのは如何でしょうか。（HoCと並んで言及されることが多いので片方だけアルファベットなのは収まりが悪いことが多く、割といつも歯がゆい感じがしています）
- controlled component / uncontrolled component について、「制御されたコンポーネント」「非制御コンポーネント」はちょっとダサいなと思いつつも、「コントロールドコンポーネント」も長すぎるなと感じています。良い案はありますでしょうか。
- 別の所でも書きましたが、囲み枠の見出しの訳は「Tip → ヒント」「Note → 補足」でいいでしょうか。「Note → メモ」でもいいかもしれませんが。
- その他全般的な訳語統一に関するご意見はありますか。
@smikitky I added a TRANSLATION.md fie including a style guide: https://github.com/reactjs/ja.reactjs.org/blob/master/TRANSLATION.md
Feel free to edit with what you decide for these terms.
I'll probably end up creating a TRANSLATION.md page on the English site that will serve as an instruction guide for starting up a new translation project. I'd love your advice on it!
@smikitky 一点、
reconciliation と reconciler の訳についてご意見はありますか。初歩的な記事で「リコンシリエーション」を使いまくると意味不明になりそうですが、一方で、内部実装系の記事 (fiber reconcilerの新機能とか) では避けて通れない用語でもあります。最初は「突き合わせ処理 (reconciliation)」か「擦り合わせ処理 (reconciliation)」から始めて、踏み込んだ記事で「リコンシリエーション」「リコンサイラ」に移行するような感じが無難なのかなと感じています。
reconciliationについてはgistでも言及されていますが、Reactの特徴を表す専門用語に近いものとして扱い、Reactに特化したイメージしやすい訳語を割り当ててもいいのかなと感じました。
ドキュメントでは、主に差分を検出するアルゴリズムのことを指しているため、「差分検出処理」などは如何でしょうか？
踏み込んだ記事で「リコンシリエーション」「リコンサイラ」に移行するような感じが無難なのかなと感じています。
この点は同意です。
@koba04 ありがとうございます。差分検出だけでなくそのあとの実際の更新も役割の一部のはずですから、「差分更新処理」か、それが分かりづらいなら「差分による更新処理」「差分検出・更新処理」などの方が少しベターかなと思いますが、如何ですか。
…あ、いや、本当の実更新は ReactDOM などの担当なので reconciler はどんな差分があるかの検出しかしていないということなのかも…
…あ、いや、本当の実更新は ReactDOM などの担当なので reconciler はどんな差分があるかの検出しかしていないということなのかも…
ですです。
実際に差分を適用するのは、各ホスト環境毎にあるrendererの役割なので、reconcilerはrendererに更新内容を伝えるところが役割と言えると思います。
（厳密には、reconcilerが伝えるのはComponent単位での変更・追加・削除などの単位までで、props単位の比較はそれを受けてrendererが行うのですが、それはまぁ詳細過ぎるので...）
了解です。「差分検出処理 (reconciliation)」から始めて詳細記事で「リコンサイラ」にも適宜併用する、みたいな感じがよさそうですね。ありがとうございます。
render / rendering は「レンダー」で、renderer は「レンダラ」で、それぞれ統一してよさそうでしょうか。
renderingは全てレンダリングではなくレンダーに統一しますか？
その場合、すでにレンダリングが使われているのでどこかのタイミングで一括に変換してtextlintでチェックするのがよさそうですね。そのままだとレンダリングと訳す人が多いと思うので。
render は「いわゆる render() の実行(フェーズ)」「DOMへの変換」「ブラウザの描画」のいずれも指していることがあり、個人的には1番目のことだけをレンダーと呼んでおきたい感じです。これに限らず禁止用語のtextlint化はよさそうですね
というわけで訳語統一ルールの仮案を作りました。いかがでしょう。だいたい落ち着いたら TRANSLATION.md にコミットします。
https://github.com/reactjs/ja.reactjs.org/wiki/%E8%A8%B3%E8%AA%9E%E3%81%AE%E7%B5%B1%E4%B8%80
訳語統一、良さそうですね！
一旦今回の一次翻訳が行われるまでは wiki に逐次追加とし、 TRANSLATION.md からもリンク。今回の翻訳が終わった段階で出てきた追加用語などもまとめた上で、 TRANSLATION.md にコミットするような形でどうでしょう？
私も訳語で気になるものがあったのでここで共有します。
child / children
文脈によって「子」「子要素」「子コンポーネント」がありえます。現状私は Crowdin を参照しつつ、「子要素 / 子コンポーネント」のどちらかを選ぶ方針をとっていますが、この点に規約はありますか？
context
「コンテキスト」「コンテクスト」で迷いがちです。一般的には「コンテキスト」かもしれませんが、 export を「エクスポート」にしている点から、後者に揃えるのも理があると考えられます。
@smikitky
訳語統一ルール、いいと思います！
他にも気になる用語があれば取り上げますね。
@fsubal childはケースバイケースで補っていいと思います。thisを「この関数」などとするのも同様です。
Contextは迷いますね。個人の好みはコンテクストです（なんかアカデミックな響きがする気がします）が、他の方のご意見を聞きたいです。
crowdin の方が「コンテキスト」になってたのですが、私も最初は無意識に「コンテ ク スト」で打ってしまったのもあり、個人的には「コンテクスト」に +1 です
自分もコンテクストで良いと思います。
そういえば今日のお昼過ぎに翻訳希望者が名乗り出ていましたが Fragment もドキュメントの随所に見られるので決めておきたい気も。特に日本語にするメリットもなさそうなので「フラグメント」あるいは「Fragment」で良いかなという印象です。
コンテクスト・フラグメントについて記入しました。
コード中内のコメントの翻訳ですが、「基本はやらなくていい、が、（本当は本文に書いたほうがいいほどの）重要な情報が含まれていると感じる場合は、翻訳してもいい」という方針でいいですかね。
訳語の統一に載せたほうがよさそうというのが1つあったので取り上げます
ref
refはReact用語として「ref」として英語のままでいいですかね？ それともカタカナで「リファレンス」にします？
カタカナにすると「reference」と混乱しそうなので、React用語としての「ref」は英語のまま、「reference」は文脈に応じて「参照」などと使い分ける感じがよいかと思いますが、いかがでしょう？
key や state と同様、React用語として使っているところは ref でいいと思います。
後 ancestor (component/node) は「先祖」「祖先」あるいは（意訳して）「上位」あたりが候補になりますが、MDNを眺めた感じ「祖先」がよさそうなのでそちらに統一しようかなーと思っています。原文でも owner, parent, ancestor を記事によって割とちゃんぽんで使っているので「親」とかにしても問題はないのかもしれませんが、流石に怖いのでこれはナシで…
いわゆる redux や Immutable.js 辺りのコンセプトを語る時の mutate / mutation / immutability などの訳はどうしましょうか。特にチュートリアル (#144) と Optimizing Performance (#122) に関連しています。（現時点のPRは統一されていません）
- mutation: 「破壊的変更」「ミューテート」「ミューテーション」「変更」
- mutate: 「破壊的変更(を行う)」「ミューテート(する)」「ミューテーション(する)」「変更する」
- immutability: 「不変性」「イミュータビリティ」「immutability」
私個人としては、これは該当記事を読んで理解する上でも React を使いこなす上でも他のオンライン記事を読む上でも、英単語レベルで知っておくべきキーワードなので、破壊的変更 (mutate), イミュータビリティ（immutability; 不変性） などとドキュメントで明示し、何回か日本語で説明的に使ったのち、さりげなくカタカナの「ミューテートする」「イミュータビリティ」に置き換えていく感じがいいかなと思っています（「差分検出処理」をさりげなく「リコンシリエーション」にしていくの同じ戦略）。
念のためですが、いわゆるイミュータビリティの文脈外で出てくる "mutate DOM" などは、「変える」なり「いじる」なり、厳密に統一せず適宜やっていけばよいと思います。
チュートリアルの方は @koba04 さんに見ていただいた結果、mutate は「書き換え」という日本語から始めて、徐々に「ミューテート」にしていく感じになりました。