翻訳指針の構築に向けての提案

[matsuand]

以下の commit を拝見しました： https://github.com/zembutsu/docs.docker.jp/commit/6a8bd294075045e1cfe9393da24d1090acbb5c16#diff-f98146989f8c44bf5222cf647d50ffa2

ここにおいていくつか、翻訳指針に関わる私の見解を述べさせて頂きます。非常に事細かな部分ではありますが、翻訳全体の統制を図る意味では欠かせない内容と考えます。この件は、ゆくゆく当 github 内の Wiki にでも取りまとめるべきではないかと考えますが、さしあたり以下の具体例を提示することで、問題提起とさせていただきます。

語句の訳出に関して(私見)： (上記 commit 内)

1. 賛同事例 (上記 commit 結果に賛成するもの)

• ×全サービス、×全てのサービス ＝＞ ○すべてのサービス （ひらがな表記とすべき)
• ×仕組みに使う為、＝＞ ○ 仕組みに使うため (ひらがな表記とすべき)
• ×指定が無ければ、＝＞ ○ 指定がなければ (ひらがな表記とすべき)

2. 反対事例 (上記 commit 結果に反対するもの)

• ×正に「本番環境に、＝＞ ○まさに「本番環境に (ひらがな表記とすべき)
• ×例えば、何番のポートを、＝＞ ○たとえば、何番のポートを (ひらがな表記とすべき)
• ×初めての、＝＞ ○はじめての (ひらがな表記とすべき)
• ×直ちに再起動、＝＞ △ただちに再起動、＝＞ ○すぐに再起動 (ひらがな表記とすべき)
• ×以下の通りに、＝＞ ○以下のとおりに (ひらがな表記とすべき)

上記私見に関しては、ほぼ接続詞など平易なものを対象とし、それらをすべてひらがな表記とすべきという考えを示しているものです。賛否は当然あろうかと思います。ただしマニュアルという性格上からは、平易な文面を目指すことが不可欠なことと捉えます。「である調」でなく「ですます調」をもとから採用されている点は、ごく自然で至極適当と思います。同様の観点で、ひらがな表記を積極的に推し進めるべきとの考えを持っています。嘘のような実は真剣な話として、ひらがなにすると文書全体が黒ずむことなく白んで見えるので、それだけでも読みやすくとっつきやすくなるという見解(?)も、どこかで見聞きしたことがあります。その考えに感化されている意識です。

以上、よろしくお願いいたします。

[zembutsu]

こちらの方針についえは私は問題ないと思っています。 取り組んだ時期がバラバラのため、その時の気分なり感覚的に書いていたのが現状です。 今後は校正時の指標として、どこかガイドラインの整備をしようと思います。

[matsuand]

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