[Ja] configration #3827
[Ja] configration #3827
Conversation
|
Looks like there is a build error. |
| .. | ||
| Configuration | ||
|
|
||
| 構成管理 |
There was a problem hiding this comment.
configure, configuration は、「設定する」「設定」と訳すことが多く、
「管理」よりも「設定」の色合いが強いので、「構成設定」あたりでいかがでしょうか？
(2.x のドキュメントも変えようと思います。）
There was a problem hiding this comment.
ご指摘ありがとうございます。おっしゃる通りと思いますので、早速修正したいと思います。
こんな感じでコメントいただけると、本当に助かります。翻訳メンバーにも共有しますね！
# Conflicts: # ja/development/configuration.rst
|
There hasn't been any progress for months. Any plans in finishing this PR for merge? Or do you want to close it? |
|
@dereuromark i continue translation. Maybe same as you, i can't see progress for few month by this conversation tab. but click Commits tab, we can see progress. last commit was yesterday. this document is long and i have to organize translation group for japanese, it take so long time. |
| An example configuration file would look like:: | ||
|
|
||
| 素の PHP として保存された設定ファイルを読み込むことができます。 | ||
| あなたのアプリの設定ファイル、もしくは :term:`plugin syntax` を使用してプラグインの設定ディレクトリから読み込むことができます。 |
There was a problem hiding this comment.
":term:`plugin syntax`" is translated to ":term:`プラグイン記法`".
|
@junichirojp Please fix the build error. Also, please remove original text from your translation. I am guessing that you removed the |
|
|
||
| .. _additional-class-paths: | ||
|
|
||
| Additional Class Paths | ||
| .. | ||
| Additional Class Paths |
There was a problem hiding this comment.
ラベルとタイトルの間にコメントがあると、ラベルが機能しません。
ここも含め、原文のコメントは全て削除してください。
There was a problem hiding this comment.
了解です。試してみます。
原文の更新があった時、差分をチェックする方法って何かいいやり方ありますか？僕は原文残しておいたおかげで差分の箇所をすぐに特定できて助かったことがあります。 @okinaka さんはどうやってその箇所を確認していますか？僕もコメントアウトしない方が訳すのが楽なので、いい方法があれば知りたいです。あ、enの差分をチェックすれば解決？
１年くらい前（？）、過去に似たやり取りをしたことを思い出しました。原文を残すってのはCakePHPの2系を訳していた @waterada さんから教えてもらった方法です。残しておけば、自分はもとより第三者が原文の差分チェックを行うときに単純なdiffで確認することができて便利とのことです。この時のコアメンバーとやり取りされて方針を決められたらしいです。
@chinpei215 さん、多分同じこと指摘されているかと思うので合わせてのレスにさせてください。
ちなみに、まだ未翻訳のページがあってbuildするとそれが参照できずにwarning吐いてますが、ご指摘されている内容はそれと無関係ってことですかね。warningとは関係なくこれが問題なら、今後の翻訳はwarning気にせず進めれるので、もしよろしければ教えて頂けると助かります。
@okinaka さん、 @chinpei215 さん
色々ご指示いただくのも恐縮なので、こうやって翻訳やってくれってのがあれば教えてもらえるとありがたいです。僕ら（翻訳チーム）は過去の例に踏襲しているだけで、特にこだわりはありません。あ、僕らってのは週１回渋谷で集まって翻訳しているメンバーです。
お二人から翻訳の仕方についてのコメントが多く、非常に申し訳ないです。原文残すやり方でメンバーみんなに伝えちゃったので、おそらく複数回似たような内容でコメントされているかと思います。会えなくなっちゃった人には新しい方法を伝えられないですが、来てくれるメンバーには何か新しい方法が決まればそれを伝えようと思います。ちなみにきちんと確認していないけど、翻訳メンバーはのべ20人くらいいるかもなので、この話は引き続きちょくちょく発生するかもしれません。
なお、原文残すってのはdiffチェックする時、マニュアルを保守するときの話かと思うので、そもそも気にしなくていいって事であれば話は早いかもしれません。
最後ですが、翻訳の仕方よりも翻訳の内容について議論する方が、訳した本人はもとよりそれを見ている人たちも勉強になるかと思いますので、なるべくそっちのにシフトできるよう心がけます。
There was a problem hiding this comment.
enの差分をチェックすれば解決
そうですね。日本語版が翻訳された時の英語版と、最新の英語版の差分を取ってみてください。
第三者が原文の差分チェックを行うときに単純なdiffで確認することができて便利
残っている原文が正しいのかどうかが問題になります。誤って消してしまっているかもしれませんし、書き換えてしまっているかもしれません。マージに失敗して古い原文を翻訳しているかもしれません。
ですので、レビューの際には最新の原文と比較することになります。ですが、この時にコメントアウトされた原文が残っていると、翻訳と最新の原文を左右に並べて見比べることができないのです。
この時のコアメンバーとやり取りされて方針を決められたらしいです。
このメンバーがどなたかわかりますか？ 私も以前に junichirojp さんがそう書かれていたのを読み、それが正式なのだと思って一度試したのですが、効率が悪すぎて以後やめています。(#4027)
また、履歴から古い翻訳も見てみたのですが、原文を残してはいないようでした。もしもどこかの時点で正式に残すことに決まったというのであれば、私からその方に非効率である旨をお伝えして、改めて正式に残さない方針にしたいと思います。
未翻訳のページがあってbuildするとそれが参照できずにwarning吐いてますが、ご指摘されている内容はそれと無関係ってことですかね。
少なくとも今上がっている警告は、すでに翻訳済みの他のページから、このページにあったセクション _additional-class-paths を参照できなくなったために上がっています。参照できなくなった理由は @okinaka さんのご指摘の通りですね（私は誤って消してしまったのかと思っていましたが）。
もちろん、本当に未翻訳ページを参照して警告が出ることはあります。その場合は、私たちはとりあえずその未翻訳ページに空のセクションを追加してビルドを通しています。
来てくれるメンバーには何か新しい方法が決まればそれを伝えようと思います。
今後いらっしゃる方には残さない方法でお伝えいただけると幸いです。
よろしくお願いいたします。
There was a problem hiding this comment.
翻訳だけでなく、わざわざコメントまで忠実に更新したくありません。
なので、コメントを見つけたら率先して削除しています。
2系では、原文のコメントが多く残っていたのですが、更新するときに苦痛でした。
実際やってみるとわかると思うのですが、コメントのインデントミスったりとか
読みづらくなったりとか本来の目的とは違う部分で神経を使うので大変です。
1系は、sphinx への移行前なので、そういった原文コメントはなさそうですね。
未訳が多いので、折を見て、こちらも修正したいと思っています。
There was a problem hiding this comment.
@junichirojp 英文とその翻訳の差分をどうやって管理しているかですが、
私は、コミットや PR ごとにどのファイルが更新されているかをマークしています。
今なら、PR の needs-ja-translation ラベルが役に立つと思います。
ただし、PR の内容は最新ではない場合もあるので、差分を翻訳する際には、
最新の英文を参考にしています。
There was a problem hiding this comment.
@chinpei215 了解しました。
過去のやり取りは教えてくれた人と会えてない＆何年も前の話と思うので、確認しづらいです。
これからはご指摘の方法に従うので、それで根本を解決とさせてください。
@okinaka 保守をしやすくする方法を踏襲したつもりが、
かえって煩雑にしてしまったようですいません。
@okinaka @chinpei215
他に何か気になる点があれば、このタイミングでみんなに伝えようと思うので、
ご指摘いただけると助かります。
There was a problem hiding this comment.
あまりいろいろ指摘してもとは思ったのですが、あえてお尋ねとのことなので私から思ったことが一点あります。
Finish!!!!!!!!!!!!! のようなコミットメッセージは OSS に残すものとしては適切ではないと思いました。私自身もまだ駆け出しだった頃に、職場でこうした冗談めかしたコメントを残してしまったことがあるのですが、今では後悔しています。
英語でコメントをするのはたいへん難しいことで、私も毎回悩んではいますが、たとえ変な英語になったとしても考えて書くのがよいと思います。
この点も含めて、コミット量も多くなっていますので、一度 git rebase -i ですべてのコミットをスカッシュしていただいた方がよいかもしれません。マージの際にもできるそうなのですが、試したことがないのと、忘れてしまうかもしれませんので。
There was a problem hiding this comment.
そうですね。 @chinpei215 さんのおっしゃる通り、
作業が完了したらコミットを１つにまとめていただけるとありがたいです。
あと、細かいことですが、 cakephp/docs から作業中のブランチへのマージは
基本的には不要です。コンフリクトが発生した場合のみ必要ですが、
その際もリベースで対応した方が綺麗です
(もちろん安全対策のためマージでも結構です）。
There was a problem hiding this comment.
@chinpei215 @okinaka
gitの操作は自信がないので、今回はこのままやらせてください。
次回からは翻訳開始から終了までを１コミットにするようにします。
個別のことは別として、全体に共通する内容は上記のみでしょうか。
もろもろご指摘ありがとうございます。
There was a problem hiding this comment.
@junichirojp
git の操作に自信がないのでしたら、3.0 ブランチから新たに別ブランチを作成し、
PR しても良いです。そうすれば、この PR のブランチをマージせずに close できます。
|
Closing, as I sent another pull request. |
Start translation