Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tani #9

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Tani #9

wants to merge 10 commits into from

Conversation

maabou512
Copy link
Collaborator

・とりあえず「PREFACE」部分までレビューしてみました。(ソースはOpen_Source_Compliance_in_the_Enterprise_2016-1.txt)。私が修正した分節はメモ欄に[tani]と冒頭に記載するようにしたので、こちらをフラグとして使えればと思います。
・翻訳の内容の取捨はメイントランスレータにお任せします。
・これもトライアルだと思うので、MLでの連絡などは「しない」で行きたいと思います。

以上です。

@hfukuchi
Copy link
Collaborator

福地担当部分について:
・Preface 「はじめに」 と Foreword 「前書き」 の日本語訳の使い分けについては、採用させていただきます。
 良い提案をありがとうございます。
・Forewordに出てくる著者名ですが、英語表記するかどうかについては、継続検討します。
・他の訳の部分は、好みなので、今回はいったん却下します。

・第1章部分は、江川さんに判断をお任せします。

Pull Request全体をMergeできないので、どう反映させるか、相談したいです。
・福地のほうで変更を入れる。
・谷口さんに上記採用部分だけを再度Pull Requestしてもらう。

@maabou512
Copy link
Collaborator Author

maabou512 commented Jul 24, 2017

・Preface 「はじめに」 と Foreword 「前書き」 の日本語訳の使い分けについては、採用させていただきます。 良い提案をありがとうございます。

ありがとうございます。(メモ欄を確認いただけたということでしょうか?)

・他の訳の部分は、好みなので、今回はいったん却下します。

・基本的にメイントランスレータの権限なので、大きく異論はないのですが、好みの部分そうでないところがあります。(たぶん好みは2ヶ所ぐらい)。
・ 好み以外のところをごっそり却下するのはちょっともったいない感じがします。
・なぜならレビュー前の段階で日本語としてだいぶ読みづらい、というのが正直な印象で、日本語としてだいぶ意識して読みやくする工夫が必要ではないかと思いました。(若い人も意識して)
・また、PREFACEは最初のIbrahimの執筆のモチベーションの説明であり、「だから読んでくれ」というメッセージになるので、最初のつかみという意味では、最初に読者が躓かないようもう少し丁寧にレビューした方がよいように思いました。(といってもあくまで私見です^^)

Pull Request全体をMergeできないので、どう反映させるか、相談したいです。
・福地のほうで変更を入れる。
・谷口さんに上記採用部分だけを再度Pull Requestしてもらう。

プロセスとして誰が負荷を負うか、という問題になりそうですね。個人的な意見ではなく、一般論として前者の方が良いと思います。レビュワに負荷を負わせることは以下のようなネガティブインパクトが出るように思います。

  1. レビュワ人数分のオーバーヘッドが生じうる(全体として非効率)
  2. レビュワのスキルによって更なるオーバーヘッドが生じたり、品質へ影響する可能性もある
  3. なにより、レビュワにやさしくないと参加障壁になってしまう

以上ご参考までに。

@hfukuchi
Copy link
Collaborator

>・なぜならレビュー前の段階で日本語としてだいぶ読みづらい、というのが正直な印象で、日本語としてだいぶ意識して読みやくする工夫が必要ではないかと思いました。(若い人も意識して)

具体的には、どの提案になりますでしょうか。
読みにくいというのは、同意します。そもそも原文が読みにくい構造になっているのをそのままにしている部分もあり、読みやすくするという提案は受け入れたいです。

>プロセスとして誰が負荷を負うか、という問題になりそうですね。個人的な意見ではなく、一般論として前者の方が良いと思います。レビュワに負荷を負わせることは以下のようなネガティブインパクトが出るように思います。

では、今回は、メイン翻訳者が拾うというプロセスで進めてみたいと思います。変更を入れる際に、どのPull Requestを反映させたかを明記するようにしたいと思います。

>ありがとうございます。(メモ欄を確認いただけたということでしょうか?)

GitHub上でDiffを表示させると、メモ部分も表示されるので、そこで理由等を理解しました。

@maabou512
Copy link
Collaborator Author

具体的には、どの提案になりますでしょうか。

PREFACE(はじめに)を分節1として、好みといえるのは以下の分節2なので、分節2以外ですね。

  • 分節2:Throughout my journey~ →ここは意識的に雰囲気だして分節3につなげたかったということです。

分節3(My interest grew ~)も若干好みの部分が入ったので("ボツやむなし")と書かせていただきましたが、ここはPREFACEの核になるパラグラフなので、きちんとニュアンスやIbrahimが言わんとしていることをくみ取って表現する必要があると思います(私の案は記載のとおりです)

では、今回は、メイン翻訳者が拾うというプロセスで進めてみたいと思います。

ありがとうございます。ただ、ちょっと気になっているのは私の次のPull Requestまでの作業です。
福地さん側で修正してPull Mergeした後でないと、当方は次のレビューに移れない、つまりボトルネックが生じることになりそうです。(たぶん以下の手順)

  1. masterブランチPull Merge後、master内容を当方ローカルにfetchする
  2. レビューを再開
  3. レビュー内容を当方のリモートレポジトリにpush
  4. masterにPull Request発出 (以降のレビューも1から繰り返し)

あとついでになりますが、

どのPull Requestを反映させたかを明記するようにしたいと思います。

これ、意外と要らないのかな、と思いました。そもそも;
「レビュワに却下/採用の理由を説明し、納得してもらう必要があるのか?」
ということが疑問としてあります。

結局今回のケースのように却下するケースが多々でてくると思いますが、それを連絡するだけでメイントランスレータ―のオーバーヘッドになります。レビュワだけではなく当然メイントランスレータについても参加障壁を上げない工夫は必要だと思います。

一度masterでコミットした箇所が他ブランチで修正できないようになれば、この辺連絡不要で進められるような気もしますがそういう機能がないのであれば、ルールとして「一度レビューしおわった箇所には修正を加えないこと」ぐらいは作った方がいいのかもしれないですね。

@hfukuchi
Copy link
Collaborator

Prefaceの翻訳提案については、誤訳ではない、読みやすさを改善している、という点ですので、課題として認識して、受諾するかは継続検討とします。
できれば、最初のうちは、誤訳や、翻訳した用語の適切性を早めに修正したいです。

「はじめに」と「前書き」は直接コミットする形で反映させます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants