matsuand
matsuand
one-off という単語に関して、訳語を統一するべきかと思い、ここに課題としてあげるとともに、私の意見を示します。これは当プロジェクトにとどまらず、英単語解釈、英米文化、時評に関わる話です。どうぞお近くにネイティブな方がおられましたら、是非お考え、捉え方を尋ねてみて頂きたいと思います。どのような形ででも翻訳に携わる方の知見やご意見を頂けたらありがたく思います。 結論から言いますと、one-off というと、第一義的には「単発の」とか「１回限り」という意味がありますが、これがコマンド ``docker-compose run``に対する説明において用いられ、このコマンドは one-off command である、と説明されています。これを「単発のコマンド」、「１回限りのコマンド」と訳すことおよびそう解釈することは、とてもできず誤っていると思います。私の結論は、意義的には「唯一無二の」つまり他単語でいえば unique の意味と捉えます。ですから ``docker-compose run`` コマンドは、Docker の中でも「非常にユニークな特別な」コマンドである、というのがその意味であって、訳す場合には、長々とした説明修飾はあまり適当ではありませんので、簡易にするべく少々意訳すると (1)特別な、(2) 特殊な、そして意義に近づけるなら (3) 独特な、ということになるかと思います。(1), (2), (3) のいずれでも私は良いと思います。皆様の意見を頂戴したく思います。無難に (3) で良いかとも思います。 上に至る情報をいくつか示します。 one-off は通常の英和辞典で引くと、だいたい adj.「ただ１回限りの」、n.「１つだけ[１回限り]のもの」(ライトハウス)となります。ただし上で示しているように、``docker-compose run`` コマンドを「１回限りのコマンド」と訳したのでは、全く意味が通じません。もっと根源を調べる必要がありそうです。英英辞典を調べても、adj....
ここで言うコロンとは、たとえば以下のような英文でのコロンの利用のことです。 > Here is the example output: 行末がコロンで終わる英文独特の表現です。これを **どう訳すか** です。訳出をしている際に、原文をコピーして、必要な箇所を日本語化していくと、何も考えずにいると、このコロンは行末に残すことが多くなるかと思います。私は日本語には無い文化（？）あるいは文章表現のように感じられるので、取り除くのがふさわしいと考えています。いかがですか？ なお同様なものとして、セミコロンを用いる英文も存在しますが、圧倒的に出現頻度は少ないかと思います。これがもし Docker ドキュメントに出てきたら、こちらも取り除くべきと考えています。 参考 https://www.grammarbook.com/punctuation/colons.asp
Swarm をどう訳すかです。単純には (1) 英単語のまま Swarm とする、(2) スウォームとカタカナ語で訳す。 持論として (2) でも良いと思いますが、もっともっと Docker Swarm が活用され、当たり前のものになったときに、このカタカナ表記を取るべきと思います（そう判断する時点が難しいですが）。当面は (1) で良いと思います。現状訳は (1) であることを承知しており、とりあえず良いかと思います。 ただし要注意です。原文内にてこの語は Swarm（頭文字が大文字）とも swarm（小文字）とも表記されており、つまり一般名詞扱いであり、技術用語扱い、製品名扱いではありません。問題となるのは、英文冒頭がこの語から始まれば、大文字 Swarm となりますが、文中であれば 小文字 swarm となるわけで、日本語訳でこれをそのまま受け継ぐのは不自然です。現状訳では原文のまま引き継いでいる様子です。どちらかに統一すべきであり、日本語訳では技術用語扱いにして（そう扱っても扱わなくてもよいのですが）、大文字 Swarm で統一するのが良いと考えます。 まとめると Swarm に関して、カタカナ表記であれば英単語表記に、英単語表記は頭文字を大文字に、といった対処が必要と考えます。いかがですか？
カタカナ用語の語末に長音符号をつけるかどうかについては、各所でいろいろ議論されるところかと思います。私個人はこの件に関して、経緯(内閣告示やJIS慣例、報道分野の姿勢、昨今の「つける」派への動きなど)や評価に関しての知識があり持論があり、結論としては例外なく「つけるべき」という意見を持っています。 現行訳は「つけない」派であり、そこは今後も変えるおつもりはないでしょうか。時流からすると「つけるべき」と思っております。各位のご意見を頂けたら幸いです。
カタカナ用語が名詞語句として複数連なったとき（例えばコンテナ・インスタンス）、本訳は全般に中黒（・）を置いています。これも各所で是非があるように思います。さらに中黒を置く方針のように見受けながら「コンテナインスタンス」のように、中黒を書いていない訳例も見かけました。 他所では空白を入れるとする取り決めもあるようですが、私は中黒も空白も共に不要と思っています。いかがですか？
matsuand と申します。 Docker に興味を抱き、また英文翻訳に相当の興味を頂いていることから、是非 Docker 日本語化プロジェクトに参加して作業を進めたく思っています。 どのように参加させて頂いたら良いのか、皆目見当がついていません。この点を issue として挙げさせて頂きます。初めはざっくりし過ぎる課題かもしれませんが、適宜、細分化できれば、それに応じて当 issue を close、新たな issue を open していくことになるかと思います。 さしあたり当 issue では、次の観点を挙げさせて頂きます。 - プルリクエストの適正な(推奨する)やり方 - 現状バージョン v17.06 での完成度が不明；２、３の rst ファイルを見ると、訳漏れが発生している様子。どう対処すべきか。気付いた者に委ねるのか、能動的に issue に挙げるなどして明確化すべきではないか？ -...
## 思うところ概要 訳出を進めていくためには、どう訳すかという方針を定めることが適当です。ただしそういった方針を定めるには、どんなレベルまでどのように、誰がどうやって定めるのか、といったように、議論や努力は果てしなく続きます。どこかに模範となる訳出方針などというものがあれば、「それに準じる」だけでも、相当な前進であり目安になります。たぶんそのようなものは、なかなか見つからないでしょうけれど。少なくともこれが必要である、という認識のもと、これを課題意識として持ちたいものと思っています。 ## なすべきと思う方向 上のような理想論は、達成できればそれに越したことはありませんが、現実的ではありません。そこで現実に取り掛かれることは、日々の訳出の中で、こうした方がいい、こういうことで悩んだ、これについては皆さんどう思うか、といった具体的内容を伴った議論を活性化する、しかもそれは、そんなに大層な大上段に構えるものではなく、より具体的にピンポイントの、単語レベル程度のものを議論していくのが良いと思っています。 前 issue として「one-off の訳し方について」 と題して取り上げた内容も、そういったものの一つです。 そしてこういった方向性の議論や試行錯誤を、まずは issue 上で行い（メーリングリストなどがあれば、そういったものでも良い）、その成果（とりあえずの結論でも良い）を Wiki にまとめる、という方法を提案したいと思います。 常々私は申し上げることですが、提案だけを放り投げることはしません。そういった方向でよろしければ、そしてそれを試しに私がやって良いのであれば、私がやります。 ## 具体的項目「Where to go next」 上に示した内容に従って、私が取り上げたいトピックがあります。 Where to go next という節タイトルに用いられる表現です。ここかしこにあります。この訳出を統一したいと考えています。 かつて私は、どこかのプルリクエストにて、旧訳として「次はどこへ行きますか」というのがあって、これは不適切と指摘し、提案訳として「次は何を読みますか」をあげました。と言っておきながら、どうするのが良いかなぁ、と今も悩んでいます。 どう思われますか？...
日本語化ファイルが rst ファイルであるのに対して、Upstream は md であるという点、かつては rst ファイルを用いた Sphinx ドキュメントとして構成されていたのでしょうか？ 以下に rst ファイルを削除した履歴を見出しました。https://github.com/docker/docker.github.io/commit/adf04681b4bd7293675b77b2397d87a5361b383b そうであるなら、md 化が必要ですよね？ さらにそれは日本語現行 v17.06 に適用するのか、日本語化最新対応 v18.09 に向けて行うかなど、取り決め（と覚悟？）が必要になるかと思っていますが、いかがでしょうか？ 初めて本プロジェクトを知り、何も分からずに結果として、日本語現行 v17.06 を訳修正し始めましたが、これで良いのでしょうか？ 先に md 化することを優先するのかどうか、と思いあぐねています。 md 化をやるならやるで、ご用命頂けましたら私がやりますが、いかがですか？
以下の commit を拝見しました： https://github.com/zembutsu/docs.docker.jp/commit/6a8bd294075045e1cfe9393da24d1090acbb5c16#diff-f98146989f8c44bf5222cf647d50ffa2 ここにおいていくつか、翻訳指針に関わる私の見解を述べさせて頂きます。非常に事細かな部分ではありますが、翻訳全体の統制を図る意味では欠かせない内容と考えます。この件は、ゆくゆく当 github 内の Wiki にでも取りまとめるべきではないかと考えますが、さしあたり以下の具体例を提示することで、問題提起とさせていただきます。 語句の訳出に関して(私見)： (上記 commit 内) 1. 賛同事例 (上記 commit 結果に賛成するもの) - ×全サービス、×全てのサービス ＝＞ ○すべてのサービス （ひらがな表記とすべき) - ×仕組みに使う為、＝＞ ○ 仕組みに使うため (ひらがな表記とすべき) - ×指定が無ければ、＝＞...
現状の git-scm.com 日本語版の「クロスリファレンス」およびそれによるハイパーリンクが、(1) リンク先非存在によりエラー、となり (2) リンク先表記が適正な日本語表記になっていない、という問題があります。(1)についてはまだよくわかっていないのですが、(2)に関して、あるいは (2)そのものではないかもしれませんが、一つ提案があります。（この提案が上述の (1)、(2) の解決になるかどうかが、まだわかっていません。git-scm.com に準拠した処理を実践してみないとよくわかりません。） セクションタイトルに対して、現状は明示的な ID づけが為されていないため、たとえば「バージョン管理に関して」という章立てタイトル箇所に対して、（HTMLの） ID は "_バージョン管理に関して" という日本語を含む ID となっています。これは改善の余地があり、英語表記、正確には英語版とまったく同じ ID を採用すべきと思います。その方法は後述します。 改善理由としては以下です。 1. 訳出編集観点から。そのセクションタイトルが原文変更となった場合、原文ではタイトル変更と同時に ID 参照箇所も変更をかけるはずです。その際に日本語版でも当然、セクションタイトルの訳変更が発生する可能性が大いにあり、であると ID 参照箇所も変更しなければなりません。しかし ID を英語版どおりに揃えておけば、セクションタイトルの訳変更をするだけで済み、ID...