matsuand

最近 ``docker-compose`` コマンドではなく ``docker compose`` コマンド（合間にハイフンなし）が登場していますので、改めて ``docker-compose run`` コマンドに対する one-off を考え直しているところです。ふと思いついた訳として「ワンタッチ」を思いつきました。電化製品のボタンにありそうな表現で、突拍子もなく響くかもしれません。ただ原語と同等の語数で、すっと表現できる語感で、なおニュアンスが近いこの語が、伝えたい原義をしっかり伝えられそうな気がします。当初に考えた「特別な」とか「独特な」とは、かけ離れてしまいました。とりあえず私個人は、この訳で進めてみたいと考えています。いかがでしょうか。

課題にかこつけて一つ教えて頂けますか。既にpull requestを挙げていますが、私 matsuand の git commit のコメントには長々と翻訳改正理由を書き連ねています。本当はこれをしたくありません。git commit のコメントには端的な内容を書くに留め、その詳細な理由説明は、別途 github 上にでも書き表わしたく感じています。こういうことは出来るのでしょうか？ github の操作がまだまだよく分かっていないための質問です。よろしくお願いいたします。

なかなか返信をいただけないことは、残念に思っています。返信のない間は、私の自由裁量でできる範囲で、私の思う方向で進めさせていただきます。 お忙しいところかと思いますが、簡単にできること（そしてさしあたって私が望むこと）を書かせていただきます。 1. issue の方向性、大方針、お考えについて、お示しいただくこと。 確定した決定事項でなくて構いません。何となく思うことや机上の理想論でも構いません。議論および issue 解決、進展の糸口を切り開くものが必要と考えます。 2. 作業振りを（私に向けて）行っていただくこと。 私はかなり気合を入れて、翻訳に取り組んでいます。私のこの意欲を、当プロジェクトにうまいこと取り入れるコントロールをしてください。さらに言うならば、もっとたくさんの人への呼びかけを行って、issue コーディネーターとか、翻訳担当、翻訳レビュー担当、コード管理担当、統括管理などなど、人を増やして担当を増やして、効率よく組織的に、ボランティアを募って進めていきたいと願っています。

返信ありがとうございます。 > 個人的には、サーバ側でレビューなりCIの仕組みも必要と認識しています（今は自分しか本番環境への反映ができないため）。 本番環境とは docs.docker.jp を指しているのでしょうか？・・・ そこがどのようなものか承知していませんが、GitHub 上で成果物HTMLを公開する形としても良いように思います。 それがどうであれ、最終公開部分で、zembutsuさんの権限のみで進行するものであるとしても、その直前をすべて GitHub 上で、issue 管理、コード管理を出来さえすれば（さしあたっては）それで良いと感じます。 > 今日今すぐは動けなく申し訳ないのですが、少しずつ取り組みますので、お時間をください。 諸々お待ちしています。その間、訳提案などは鋭意進めます。 なお当 issue のみでなく、他の issue へも、一言二言コメントをいただけましたらありがたく。 よろしくお願いします。

2019/4/17 に行ったプルリクエスト https://github.com/zembutsu/docs.docker.jp/pull/186 の時点より、訳修正案を挙げると同時に、md 化したドキュメントソースを構築していくべく、作業を同時並行して行っていくことにしました。その成果は、 - ドキュメントソースは https://github.com/matsuand/docs.docker.jp/tree/v18.09.local に - 処理結果は https://matsuand.github.io/docs.docker.jp.onthefly/ に それぞれ挙げることにしました。コメントを頂戴いたしたく思います。上記は処理結果ページから見て頂くと一目瞭然ですが、1% も訳出完了していません。これまでの rst ファイルの日本語訳文を、内容精査しつつ、md ファイルに移し変えている状態です。 なお当方からのプルリクエストは、我ながら(?)辛辣なものが多いと思います。その分、ご気分を害されているのではないかと危惧しています。ただし目指すところは適切な日本語訳であり、そのために私 matsuand は作業進めたく思っています。このプロジェクトにて、多大な日本語訳を提供して頂いていることに感謝しています。それをさらに盛り上げたい思いでおります。

manzyun さん、 コメントいただいていたことに気づいていませんでした。かなり遅い返信ですが、コメントします。お気に障るかもしれませんが、否定的な意見です。 まず Python公式ドキュメントを例にあげて頂きましたが、根拠として信頼を置くことはしませんし、できません。そのプロジェクトは、どれだけの配慮、考慮、熟慮をした上でそう表現されているのでしょう。それをご存知でしたらお知らせください。今のところ私は懐疑的です。 また知人の翻訳家の方にお話を聞いたそうですが、それではその翻訳家の方の意見をお示しください。ご本人が投稿して頂いてもかまいません。 なお私はコロンなどの意味を議論しているのではありません。コロンを日本語文の中でどう「訳す」べきかを問題としています。お間違いないように。

@manzyun 順不同ながら > 「英語圏の人達の文書での常識」 英語圏の方たちは理解していて当然ですから、この指摘や理由づけは無意味です。問題はそれを日本語翻訳する日本人の理解です。少なくともコンピューターシステムの翻訳に携わる、主にボランティアの翻訳担当者たちにおいて、その常識（コロンにこれこれこういう意味がある）を解釈しているかというと、その数は相当少ない、ひょっとすると皆無かもしれない、とつくづく感じています。本issueは、それが背景にあるからこそ、取り上げたといっても過言ではありません。 > 「日本語圏のプログラマが英文ドキュメントを訳すときの慣例と暗黙の了承」として、あえて書き換えない方針であったり、 慣例があるなどとは到底感じられません。誰も慣例や暗黙の了承など考えず、ただそこにあるコロンをそのまま表記しているに過ぎないと推察します。だからこそ、本issueなのです。 私の案は「コロンを句点に、セミコロンを読点に、といった画一的に決められるものではない。その時々で適切に訳す。ただし **コロンやセミコロンは取り除く** 」です。 参考リンク： JTF日本語標準スタイルガイド https://docs.google.com/document/d/1DLtNC3c1fbm9gJRd5N_xIeQ8Mu0AKQLSQgiDMlMNUc0/edit#heading=h.z0hc1dt12rm

@revsystem コメントありがとうございます。JTF に関して種々情報ありがとうございます。正直 JTF に関してはこれまで承知していませんでした。一つの情報源になると思います。 一方、当プロジェクトは「翻訳」ではあるものの、カタカナ表記に関して「翻訳」時の基準に従うだけでは不十分であり JTF だけに準拠するのは拙速と捉えます。翻訳した後はレッキとした日本語文になるわけで、つまりは日本語としての表記基準を捉えるべきです。文化庁の「外来語の表記」が、良くも悪くも最も基準とすべきものであり、JIS基準やMicrosoft社の"MicrosoftTermCollection"も大いに参考とすべきです。 JTF の前提がまだ分かっていませんが、文学作品なのか報道文書なのか科学技術論文なのか一般ユーザー向けマニュアルなのかにより、表記基準は変わって構わないと私は考えています。少なくとも同一著者、同一発行体、同一分野においては、統一されているべきです。 と語り始めるときりがないので、表記基準というものは、それ専門の部隊に策定をお願いし、どれが一番自分たちの提供文書や表明姿勢に合致するのかを、ある程度検討を加えた上で、当面これで行こうという一つを定めるのが極めて現実的であり、効率的に目的を為しうる賢明な対応であると思います。はてさて各位はどのように捉えますか？ なお -y の末尾を「つけない」という感覚は私も同感です。では policy, privacy, telephony はつけずに訳しますか？ 悩ましいでしょう？ Microsoft はこれをつけるとしています。

ご対応ありがとうございます。 > コマンドとしての swarm の場合は、原文でも ```swarm`` と記述するケースが多いと思いますので、 コマンドのことをまったく考えていませんでした。コマンドはすべて小文字でよいですよね（逆に大文字はNGです）。 気づいたら修正という点、Wiki への展開について、了解です。 ところで issue の運用として、この場合、誰が close したら良いですか？ close で良いと思ったものがするのか、（常に）管理者zembutsuさんがするのか、（常に）起票者がするのか、いろいろかと思います。 取り決めてください。

Github の issue についてまだまだ理解が不足しています。一方、私個人は Trac や Redmine を実運用した経験があり、これらの課題管理システムにおける重要ポイントを理解している（つもり）でおります。それは何かというと、(1)課題項目の設定の仕方・粒度を適切に行うこと、(2)担当者と、できれば実現めどを定めること、この２点が最も重要だと理解しているところです。 何を言いたいかと申しますと、すべての issue に関して、適切な課題設定と担当割り当てが必須と思っておりまして、当issueについても、課題設定を必要に応じて細分化することや担当決めを行う必要があると考えます。当issueの現状では、課題としてあまりに大きな粒度で漠然としており、たぶん管理できないし進行しないと懸念します。割り振って頂ければ私がやりますが、いかがですか？ 他にどのような方が担当を引き受けて頂けそうなのか、全く承知していませんので、出すぎた意見であればご指摘ください。