[JA] ファイル翻訳: content-create.txt

翻訳を提案させていただきます。どなたかレビューをお願いいたします。

はじめまして。
D8 ユーザーガイドの翻訳が始まったのを知って少し興味を持ったため、気まぐれで申し訳ありませんが、少しレビューをさせていただきます。
以下、好き放題書いておりますが、このプロジェクトのガイドラインも読んでいない状態ですので、何か見当違いのことを書いていた場合は、どうかご容赦いただければ幸いです。

> -How to create a content item for use as the home page.
> +ホームページとして使うコンテンツアイテムの作成方法。

「使う」ではなく「使用する」の方が良いと思います。
このプロジェクトでの細かな文体の基準がどうなっているのかは分からないのですが、文章全般が文語体寄りに書かれている文章全体で熟語が多用されているように見えますので、「使う」もそれに合わせた方が文が締まる気がします。
（8/2 編集： 「文語体」という表現が正しくないことに気づいたため、「熟語の多用」に変更しました。ただし、これも正しい表現かどうか、あまり自信がありません。提案の根拠として、文中に「作成方法」があるので、それであれば「使う」→「使用する」が適切だという考えです。反対に「使う」を使うのなら「作成方法」→「作り方」かな…という考えに基づいています。「単語の固さを合わせる」という感覚です）

> -Create and publish a content item that will be used as the home page of the -site.
> +サイトのホームページとして使うコンテンツアイテムを作成し公開する。

これも同様に「使う」ではなく「使用される」が良いように思います。

> -The _Basic page_ content type must exist. This is created on your site when you 
> -install with the core Standard installation profile.
> +コンテンツタイプ「基本ページ」が存在する必要すること。

「存在すること」か「存在する必要があります」のどちらかのタイポでしょうか？

> +基本ページは、コアの標準インストールプロフィールを使ってインストールをすると作成されます。

これもまた、カギ括弧の使用ルールがよく分かっていないのですが、同じ段落内で同じ単語に付いたり付かなかったりですと違和感を覚えます。
元々原文にはない言葉なので、「このコンテンツタイプは」や「これは」で置き換えれば、ひとまずカギ括弧問題を先送りにできるのではないかと思います。
また、他と同様に「使って」を「使用して」にする方が良いかと思います。
ちなみに私が訳した場合は、"Standard" もプロファイル名とみなし、次のようにすると思います。

コアの「標準」インストールプロフィールでインストールした場合は、このコンテンツタイプは作成されています。

> -. In the _Manage_ administrative menu, navigate to _Content_ > _Add content_ >
> -_Basic page_ (_node/add/page_). The _Create Basic page_ form appears.
> +. 管理用メニュー「管理」で、「コンテンツ」 > 「コンテンツを追加」 > 「基本ページ」（ _node/add/page_ ）へと進みます。
> +「基本ページの作成」フォームが表示されます。

『管理用メニュー「管理」』ですと「管理」という管理用メニューのような印象を受けますので、「の」か「にある」を入れた方が良いように思います。
また、2 文になっていることが冗長な気がするのと、「へと進む」の言い回しが少し気になりますので、次のようにすると、すっきりして良いように思います。

管理用メニューの「管理」から、「コンテンツ」 > 「コンテンツを追加」 > 「基本ページ」（ _node/add/page_ ）の順に進み、「基本ページの作成」フォームを表示します。

> +| タイトル | ページのタイトル。ソースコードのメタタグや URL エイリアス、管理用ページでのコンテンツアイテムラベルとしても使用される。 | ホーム 

「ソースコードのメタタグや URL エイリアス、」ですと 「URL エイリアス」が「ソースコード」にかかってしまうのと、「コンテンツアイテムラベル」が一括りであるような錯覚や読みにくさがあるので、次のようにすると良いかと思います。

+| タイトル | ページのタイトル。ソースコードのメタタグ、URL エイリアス、管理用ページでのコンテンツアイテムのラベルとして使用される。 | ホーム

> +| 概要 | 本文フィールドの値の概要。概要ページのティーザーとして使用できる。 | シティマーケットの営業時間と場所。

これもカギ括弧ルールに関するものでよく分かりませんが、「本文フィールド」ではなく『「本文」フィールド』なのかなと感じます。

> +| 本文 | ページの完全なコンテンツ | シティマーケットへようこそ - あなたの近くの農産物市場です！

一般的に「コンテンツ」という単語から受ける印象を考えると、「ページの完全なコンテンツ」ではなく「ページの完全な内容」、あるいは「ページの全文」の方が良いように思います。
うまく説明できませんが、個人的には「コンテンツ」というカタカナ言葉はもっと広義な印象を受けます。

> +営業時間: 4 月から 9 月の日曜日 午前 9 時 - 午後 2 時

"to" を、月は「から」、時刻は「-」にしているのでちぐはぐな印象を受けます。
個人的には「～」を使って次のようにすると思いますが、いずれにせよ統一した方が良いかと思います。

営業時間: 4 ～ 9 月の日曜日、午前 9 時 ～ 午後 2 時

> +リッチテキストエディターツールバーの「ソース」をクリックすると、編集中のテキストの HTML ソースコードを見ることができます。

先にも書いたように、「リッチテキストエディターツールバー」のようにカタカナ言葉を一括りにすると、錯覚や読みにくさを覚えます。
ですのでこの場合は「リッチテキストエディターのツールバー」か、「の」の連続を嫌うのであれば、次のようにすると良いかと思います。

リッチテキストエディターのツールバーにある「ソース」をクリックすると、編集中テキストの HTML ソースコードを見ることが表示できます。

(8/1 編集： "見ること" → "表示" の方が良いかと気づき変更しました。)

> +. 「プレビュー」をクリックして、想定したとおりにすべて表示されることを確認します。 

これですと「すべて表示されることを想定している」ように読めてしまいますが、実際に説明していることは「全フィールドが期待したとおりに表示されているかどうかの確認」なのと、ニュアンス的に「想定」ではなく「期待」の方が適しているように思いますので、「すべてが期待どおりに表示されること」にする方が良いかと思います。

> -. Follow the same steps to create an About page, with title "About", and a body
> -telling about the history of the farmer's market.
> +. 同じ手順でアバウトページを作ります。タイトルは「アバウト」とし、本文には農産物市場の歴史を記述しましょう。 

個人的な感覚なのかもしれませんが、"About" をカタカナに変換することに違和感を覚えます。
アプリケーションなどでも「About」のままか「～について」、あるいは「情報」などはよく目にしますが、「アバウト」となっているものはちょっと思いつきません。
ウェブ業界で「アバウトページ」という言葉が一般的であるのでしたら良いのですが、そうでなければ "an About page" は「About ページ」や「情報ページ」、"title "About"" は『タイトルは「シティマーケットについて」』で良いように思います。

レビューは以上です。

ここからは真面目にレビューしてみての個人的な感想ですが、この「レビュー」という作業は非常にハードルが高いように感じます。
あくまでも私の場合ですが、自分で翻訳するのと比較して、レビューの方が時間も労力も 1.5 ～ 2 倍かかる感覚でした。
このプロジェクト自体がまだ始まったばかりのようですが、無責任な意見として、全体的なワークフローや文体のルールをもう少し練った方が良い気がします。

re:#4

Takafumiさま

"さま" ではなく "さん" で結構です。（笑）

お久しぶりです、このプロジェクトのコーディネーターをしているkabetaniです。

こちらこそ、お久しぶりです。
もう d.o での活動には関わりたくないと思っていたのですが、このプロジェクトに興味を持ったのも、気まぐれにレビューしてみたのも、きっかけは kabetani さんが始めたという点が大きいです。
私がどこまで貢献できるか（あるいは傍観するだけに終わるか）は今のところ不明ですが、せっかく立ち上がったプロジェクトですので、どうか最後まで頑張ってください。

文体について等、これ以外の返信については、ここで行うのは適当ではないような気がしますので、g.d.o/documentation-japanese の方にポストさせていただこうと思います。
それでは、今後ともよろしくお願いいたします。

＃3 でのコメント内容に若干の修正を加えたパッチを作成いたしましたので、https://www.drupal.org/node/2885908 や https://www.drupal.org/node/2885928 と同様に添付させていただきます。

@Takafumi さん、はじめまして。

せっかくレビューしていただいたのに反応が遅くなってしまい申し訳ありません。。進め方などについては別の場所で議論させていただくとして、ここでは content-create.txt にいただいたレビューについてのみコメントさせていただきます。

細部まで丁寧にチェックいただきありがとうございます。どの点も概ね納得のご指摘です。

1.

-サイトのホームページとして使うコンテンツアイテムを作成し公開する。
+サイトのホームページとして使用する、コンテンツアイテムを作成して公開する。

熟語を使うべきというご指摘については納得です。そちらに加えて「使用する、」の「、」を加えることをご提案いただいていますが、こちらはどのような基準で付けるイメージでしょう？このような短文の場合はなくてもよいような気もしますが、「こういう場合にはつけた方がいい」という基準などあればお教えいただきたいです。

2.

-. 以下のとおりにフィールドに入力します。
+. 次のように、フィールドに入力します。

「推すか敲くか」ではありませんが、このあたりの言い回しはどちらも正解で、あとは好みの問題によるところが大きそうなので取り扱いが難しいですね。。レビュアーの方からこのような指摘があったときに、翻訳者の案を通すのかレビュアーの案を通すのかが悩ましいところです。

ここに関して私は「以下のとおりに」「次のように、」のどちらでもいいと思うので、ご提案いただいた「次のように、」で進められればと思いますが、このあたりをどう扱うのかについては一定のルールを作った方がよいかもしれませんね。

例えば、 d.o. のイシューのパッチのコード内コメントに関しては文意や文法によほどの間違いがないかぎりオリジナルのパッチ作成者の文章をそのまま使うことがほとんどのような気がするので（私の観測範囲での印象です）、ここもそうするのでもよい気がします。ただ、 User Guide の性質を考えると、 User Guide 翻訳ならではのプラスアルファの基準を議論してもよいかもしれません。

3.

+// Partly filled-in node/add/page, with Summary section open.

ここは「コメントだから原文のままにしよう」というご指摘だと理解しましたがこの理解で正しいでしょうか？

パッチだけだとどうしても意図の理解、解釈に時間がかかってしまうので、ご負担にはなると思うのですが一言コメントを添えていただだけるとうれしいです。

4.

+. 同じ手順で「情報」ページを作ります。タイトルは「農産物市場について」とし、本文に農産物市場の歴史を記述します。

「アバウト」がカタカナだと気持ち悪いのはご指摘のとおりですね。書いていて気づきませんでした（笑）。

「 about 」とアルファベットが残るのは気持ち悪い気もしますが、個人的な経験・観測では「 about ページ」という言い方で伝え合うことが多い気がしますし、「 about ページ」でいかがでしょうか。

その他の点についてはご指摘いただいた形に変更するのでよいと思いました。

>@Takafumi さん、はじめまして。

はじめまして、よろしくお願いいたします。

>せっかくレビューしていただいたのに反応が遅くなってしまい申し訳ありません。。進め方などについては別の場所で議論させていただくとして、ここでは content-create.txt にいただいたレビューについてのみコメントさせていただきます。

もしや気分を害してしまったのでは？ と不安でしたが、そうではないようで安心しました。
https://groups.drupal.org/node/517245 で、レビュー方法や文体についてを議論させていただいていますので、ご参加いただければ幸いです。

>1.

>熟語を使うべきというご指摘については納得です。そちらに加えて「使用する、」の「、」を加えることをご提案いただいていますが、こちらはどのような基準で付けるイメージでしょう？このような短文の場合はなくてもよいような気もしますが、「こういう場合にはつけた方がいい」という基準などあればお教えいただきたいです。

先の議論内で、たたき台となるガイドラインも提案する予定ですので、そこで議論しましょう。
私の感覚では、ドキュメントでこの長さの文に一つも読点がないのはちょっと読みにくいな…というのが率直な感想です。（この返信のように、会話であればそうでもないのですが…）

>2.
>
>-. 以下のとおりにフィールドに入力します。
>+. 次のように、フィールドに入力します。
>
>「推すか敲くか」ではありませんが、このあたりの言い回しはどちらも正解で、あとは好みの問題によるところが大きそうなので取り扱いが難しいですね。。レビュアーの方からこのような指摘があったときに、翻訳者の案を通すのかレビュアーの案を通すのかが悩ましいところです。
>
>ここに関して私は「以下のとおりに」「次のように、」のどちらでもいいと思うので、ご提案いただいた「次のように、」で進められればと思いますが、このあたりをどう扱うのかについては一定のルールを作った方がよいかもしれませんね。

これも今後の議論次第ですが、「以下、以上」を使うとレイアウトによっては正しくない場合が出てきますので、「次」を使う方が無難という考えでしょうか。これもガイドラインに書いてあります。
このガイドに限って言えば、おそらく「以下」の位置に表が来ると思いますので間違いだということではありません。
「のとおり」と「のように」の違いは、前者は「キッチリそのまま」で後者は「こんな感じで」といったニュアンスの違いがあるという私の感覚に基づいて提案したのだと思います。ですので、その時々で提案内容が変わる可能性があり、ルール化は難しいような気がします。

>例えば、 d.o. のイシューのパッチのコード内コメントに関しては文意や文法によほどの間違いがないかぎりオリジナルのパッチ作成者の文章をそのまま使うことがほとんどのような気がするので（私の観測範囲での印象です）、ここもそうするのでもよい気がします。ただ、 User Guide の性質を考えると、 User Guide 翻訳ならではのプラスアルファの基準を議論してもよいかもしれません。

パッチ内のコメントというと英文のことを仰っているのでしょうか？ もしそうであれば、ドキュメントの翻訳と同列で考えるのは少し違うような気がします。

>3.
>
>+// Partly filled-in node/add/page, with Summary section open.
>
>ここは「コメントだから原文のままにしよう」というご指摘だと理解しましたがこの理解で正しいでしょうか？

その2行ではコメントが訳されて、逆にその下の alt が訳されていないので、単純なミスだと考えました。
おそらく、他のファイルではコメントは訳されていないはずです。

>パッチだけだとどうしても意図の理解、解釈に時間がかかってしまうので、ご負担にはなると思うのですが一言コメントを添えていただだけるとうれしいです。

これについては先にご案内したポストで議論できればと思います。

>4.
>
>+. 同じ手順で「情報」ページを作ります。タイトルは「農産物市場について」とし、本文に農産物市場の歴史を記述します。
>
>「アバウト」がカタカナだと気持ち悪いのはご指摘のとおりですね。書いていて気づきませんでした（笑）。
>
>「 about 」とアルファベットが残るのは気持ち悪い気もしますが、個人的な経験・観測では「 about ページ」という言い方で伝え合うことが多い気がしますし、「 about ページ」でいかがでしょうか。

「アバウト」に違和感を感じるのが私だけでないとわかり安心しました（笑）。
「about(About) ページ」で良いと思います。

>他の点についてはご指摘いただいた形に変更するのでよいと思いました。

いろいろと不躾な提案をさせていただきましたが、ご理解いただけて幸いです。

申し訳ありません。
#6 のパッチ内の

+| 概要 |「 本文」フィールドの値の概要。概要ページのティーザーとして使用できる。 | シティマーケットの営業時間と場所。

で、『「 本文」フィールド』に余分なスペースが入っていることに気づきました。
パッチ当ての前後どちらかで修正をお願いします。

Re 8, 9:

素早くありがとうございます！なかなかすぐにお返しできずすみません。。。

https://groups.drupal.org/node/517245 についてお知らせいただきありがとうございます。ディスカッションが進んでいますね。後追いになりますが私も参加させていただこうと思います。

先の議論内で、たたき台となるガイドラインも提案する予定ですので、そこで議論しましょう。
私の感覚では、ドキュメントでこの長さの文に一つも読点がないのはちょっと読みにくいな…というのが率直な感想です。（この返信のように、会話であればそうでもないのですが…）

なるほど。関係代名詞が入って文章が長くなるような場合に読点を入れた方が読みやすいだろう、ということですね。言われてみれば確かにそうかもしれません。厳密なルールにするのは難しそうですが「推奨」程度のゆるやかなルールにはできるかもしれないなと思います。続きはより適切な場所で議論させてください。

パッチ内のコメントというと英文のことを仰っているのでしょうか？ もしそうであれば、ドキュメントの翻訳と同列で考えるのは少し違うような気がします。

はい、英文のことを指していました。 User Guide についてはもう少し品質を考慮したルールにする方がよいとお考えとのことですね。

言い回しなどについてまったく議論しないというのもアレですし、一方で、読点の有無を 1~2 ヶ月も議論しているようだとそれはそれでやりすぎな気もしますし、このあたりはどれぐらいがちょうどよいのか試しながら探っていくべきですかね（こちらも続きはそれぞれのページで・・・）。

その他の点についても丁寧にご説明くださりありがとうございます。私のケアレスミスがなければこのパッチにすべて反映されているはずです。再度 NR とさせてください。

（添付ファイルについては、 content-create-10.txt が差し替え後ファイル、 .patch が git パッチファイル、 interdiff-... がコメント 2 のパッチとの interdiff ファイルです）

細かくて済みませんが、2点ほど修正を提案させていただきます。

-サイトのホームページとして使用する、コンテンツアイテムを作成し公開する。
+サイトのホームページとして使用する、コンテンツアイテムを作成し、公開する。

読点の打ち方の（ある程度の）ルール化以前で申し訳ありませんが、連用形は読点で区切る方が良いかと思います。
元の私の提案にもその点でミスがありました。

-. 同じ手順で「 About 」ページを作ります。タイトルは「農産物市場について」とし、本文に農産物市場の歴史を記述します。
+. 同じ手順で「About」ページを作ります。タイトルは「農産物市場について」とし、本文に農産物市場の歴史を記述します。

こちらも、括弧内でのスペースの扱いルール化以前で申し訳ありませんが、基本的に括弧内の直前直後にスペースを入れない方が良いと思います。（「マルチバイト文字間でのシングルバイト文字には前後にスペースを入れる」は賛成ですが、括弧内は例外とした方が良いと考えます）

それ以外は問題ありませんでしたが、便宜上、Needs work にさせていただきます。

ありがとうございます。

こちらも、括弧内でのスペースの扱いルール化以前で申し訳ありませんが、基本的に括弧内の直前直後にスペースを入れない方が良いと思います。（「マルチバイト文字間でのシングルバイト文字には前後にスペースを入れる」は賛成ですが、括弧内は例外とした方が良いと考えます）

個人的には「マルチバイト文字間でのシングルバイト文字には前後にスペースを入れる」のルールは例外なく適用するのが好みですが、おっしゃるとおり「」や（）、【】などの中に英単語が 1 つだけ入るような場合にはスペースを入れない方がいいかもしれませんね。私はここには強いこだわりがないので Takafumi さんの案の方で進めさせていただきます。
（このあたりは出力されるページや PDF の見栄えによってよりよい方を選んでいくのがよいでしょうか）

再度 NR とさせてください（ 3 つファイルをあげさせていただいていますが、 interdiff をご覧いただくと最新の変更箇所だけご覧いただけて比較的スムーズかと思います）。

お手数をおかけしました。
問題がないようですので RTBC に変更させていただきます。

尚、現時点で、

• スペースの扱い
• 括弧の扱い
• 符号の扱い
• カタカナ語

など、ルール化可能な部分については早めに決めておくべきだと思っています。
近々に、各部分についてのルール候補を提案させていただこうと考えていますので、議論へのご参加をお願いいたします。

==== サイトの前提条件

コンテンツタイプ「基本ページ」が存在すること。
コアの「標準」インストールプロフィールでインストールした場合、これはすでに作成されています。

この部分は「常体／体言止め」なのに、常体と敬体が混在してしまったことに気づいたので、

これはすでに作成されています。  -> これはすでに作成されている。

に修正をお願いします。
ステータスは変えないでおきますので、特に問題がなければ直接コミットしていただければよいと思います。