いくつかのパターンの扱いについて、早めにルール化しておいた方が良いと思います。
次に挙げるパターンのそれぞれで、どれが良いかを議論し、決定してゆきましょう。
また、これ以外のパターンで早めに決めておくべきものがあれば、ご提案をお願いします。
A) 符号文字 @ # $ % & ^ - + = _ \ | * . : ? ! ” ( )
ソースコードや英文中ではシングルバイト文字が必然という共通認識があることを前提に、ここでは、日本語文章中に頻出する & ? ! : ( ) に限定
-
シングルバイト文字で統一する
例： 概念: ／ コアの標準テーマ (Bartik) では ／ シティマーケットへようこそ! ／ リージョンとは? -
マルチバイト文字で統一する
例： 概念： ／ コアの標準テーマ（Bartik）では ／ シティマーケットへようこそ！ ／ リージョンとは？ -
場所によって使い分ける（これを選択する場合は、具体的な場所や条件も列挙）
例： 英単語やパスの前後はシングルバイト、それ以外はマルチバイト ／ 見出しだけシングル
B) マルチバイト文字間のシングルバイト文字前後のスペース（スペースはシングルバイト文字）
-
入れる
例： コアの Bartik テーマでは、次の画像で強調されている 17 箇所のリージョンを提供します。 -
入れない
例： コアのBartikテーマでは、次の画像で強調されている17箇所のリージョンを提供します。
C) シングルバイト文字カッコの外側と内側のスペース（スペースはシングルバイト文字）
-
外側だけに入れる
例： コアの標準テーマ (Bartik) では ／ branding (site name, slogan, and logo) -
内側だけに入れる
例： コアの標準テーマ( Bartik )では ／ branding( site name, slogan, and logo ) -
どちらにも入れる
例： コアの標準テーマ ( Bartik ) では ／ branding ( site name, slogan, and logo ) -
どちらにも入れない
例： コアの標準テーマ(Bartik)では ／ branding(site name, slogan, and logo)
D) マルチバイト文字カッコの外側と内側のスペース（スペースはシングルバイト文字）
-
外側だけに入れる
例： コアの標準テーマ （Bartik） では -
内側だけに入れる
例： コアの標準テーマ（ Bartik ）では -
どちらにも入れる
例： コアの標準テーマ （ Bartik ） では -
どちらにも入れない
例： コアの標準テーマ（Bartik）では
E) カタカナ表記
-
一般財団法人テクニカルコミュニケーター協会発行の「外来語（カタカナ）表記ガイドライン」に準拠
https://www.jtca.org/standardization/katakana_guide_3_20150929.pdf -
その他のガイドラインに準拠
-
独自ルールを策定
Comments
私の提案は、A-2 B-1 C-1 D-4
私の提案は、
A-2, B-1, C-1, D-4, E-1
です。
パターンの洗い出しありがとうございます
ほとんど意識していなかったのですが、自分は、現状以下のようにしていると思います。
A-1, B-2, C-1, D-4, E-2(コアの翻訳に合わせている)
A-1については、「／」も「/」にする気がします。
そのようにしている理由は、趣向や癖といったもので特に強い根拠はないので、賛成意見の多い方に合わせます。
Eについて、E-1で良いと思うのですが、現状のコアの翻訳とガイドラインを適用した場合の翻訳が異なる場合、
1.ひとまず現状のコアの翻訳を優先する
2.ガイドラインのルールを優先して、コア側の翻訳変更の提案を行う
の二通りが考えられるので、そちらもどのようにすべきか考慮した方が良いと思いました。
2.を選択した場合は、現状のキャプチャー画面と文字が異なることになるかも知れませんが、この翻訳が終わる頃には8.4.xがリリースされ、キャプチャー画面も再作成されることになると思いますので、必ずしも画面に合わせる必要はないと思います。
.
原文の中でスラッシュが使われるのは、パス区切り以外で
の 2 パターンだと思いますが、1 は接続詞に置き換えて作文可能ですし、2 はそのままでよいと思います。
ですので、スラッシュは必然的にシングルバイトしか使わないと想定したのですが、使うことも想定しておいた方がよいでしょうか？
コア翻訳は hgoto さんの所属する会社内で提案と承認が完結しているようですので、hgoto さんの協力があればコア翻訳の方を変更することも可能だと考えます。
現在のコア翻訳はカオス状態ですので、現時点の画像と齟齬が生じてもかまわないということであれば、kabetani さんが提案された 2 を選択するのが最善だと考えますがいかがでしょう。
スラッシュについて
現状はないとしても、今後原文の加筆、修正で必要なケースが発生するかもしれないですし、人によっては原文にない「/」または「／」を使って翻訳する可能性もあるので、一応想定しておいても良いのではないかと思いました。
その辺の事情を私は知らないので、hgotoさんの返答を待ちたいと思います。
もしコア側の翻訳を変更することが可能であるならば、2.のパターンが良い気がしますが、コアの翻訳がからむと、そちらの方に力が分散してしまい、ユーザーガイドの翻訳作業が滞るのではないかという心配もしています。
.
もろもろおまとめくださりありがとうございます。
私も議論に参加させてください。私は以下のとおりでやっていることが多いです。
...
B については、 DTP ツールなどで全角と半角の間のスペースがコントロールできる場合などはあまり気にしなくてもよいのですが、そうでない場合（ HTML の場合）はスペースありの形で統一した方が見た目がきれいなのかなと思います。
逆に、「英語の文章の中に全角単語を入れる場合」は当然間にスペースを入れると思うので、「英語と日本語の間にはスペースを入れる」で統一するのがよいのではないでしょうか。
ただこの点については、何かよいよりどころがないか調べてみたところ、「日本翻訳連盟」さんというところが出されている次の資料がひっかかりました。
ここでは「スペースは入れない」のルールで統一されているようです。
http://www.jtf.jp/jp/style_guide/pdf/jtf_style_guide.pdf
（「 3. 文字間のスペース」というところです）
...
コア翻訳については、既存の翻訳の変更も視野に入れながら進めていくべきという点には賛成です。
ただ、私が他の人たちといっしょに集中的に翻訳をさせていただいたのは実は Drupal 8.0.0 が出る前後のみで、現在私は承認権限を持っておらず、私のコントリビュート活動は 100% 個人＆プライベートなこともあり、「コア翻訳をスピーディに変更できる」という想定はなしとして考えていただいた方がよさそうです。お役に立ててない感じですみません。。
ということで、 E についてはゆくゆくコアの翻訳も変更していくことも考えながら、 E-1 で進める形などがよいと思いますがいかがでしょう（もちろん https://localize.drupal.org/node/64106 にいただく意見も考慮して・・・）。
（「まずおおもとになるコア翻訳を変更していこう」とやるともろもろ停滞してしまう気がするので、それは避けたいと思っています）
このあたりについてはどのルールを選ぶかということ以上に「ルールを明確化し一貫させること」が大切な気がするので、 A~E のすべてにおいてどの案で進めていただいても私は賛成です！（投げやりではなく）
.
私が提示したいガイドラインの一つがそれです。もう一つが OSS 界隈ではよく使われる SUN のガイドラインです。
SUN のガイドラインの方が詳細で、議論が少なくてすむと考えていますが、カタカナの扱い方が少々古く、また、スペースなどの扱いも JFT とは異なるため、まずはじめにその点をクリアしようと考えたのがこのポストです。
なるほど、そうでしたか。勝手な想像で語ってしまい、申し訳ありませんでした。
ただ、ldo で調べてみると、同社内に承認権限を持った人（あるいはアカウント）が存在しているのは事実のようです。
l.d.o より転載（画像の添付ができないため、テキストにて）：
「100% 個人＆プライベート」ということで無理強いはできませんが、もし権限を持った方の協力を得られれば、ユーザーガイドとコア翻訳間の齟齬をなくす最低限の修正は可能になると思いますので、ご一考いただければ幸いです。
返信ができていないまま時間が経ってしまい申し訳ありません。
返信ができていないまま時間が経ってしまい申し訳ありません。。
そうなんですね、ありがとうございます。
ちなみに、 Sun のガイドラインについて少し検索して探してみたのですが、見つけることができませんでした。。どう検索すると出てくるでしょうか？
少し話がそれるかもしれませんが、 Microsoft のスタイルガイドもとても細かくルールが決められているようなので、 JTF や Sun のものをガイドラインに採用した場合でも、その他の部分で参考になりそうです。
https://www.microsoft.com/Language/ja-jp/StyleGuides.aspx
はい、そうですね、このあたりは必要に応じて対応していきましょう！
SUN のガイドライン
SUN のガイドは、数年前までは著者のブログからダウンロードできたようですが、今はブログ自体が存在しないようです。
私の手元にあるのは 2009 年版なのですが、再頒布に関する記述がないため、勝手に配るのははばかられます。
少し探した範囲では web.archive.org で 2004 年版が見つかりました。
https://web.archive.org/web/20080409205119/http://developers.sun.com/glo...
よく比較したわけではありませんが、2009 年版とは多少の差異があるようです。それでも SUN 版の感触をつかむことはできると思いますので、ひとまずこれを一読されてはいかがでしょうか。
MS でダウンロードできるものは、ほとんど英語なのでちょっと使えないと思っています。
手元には MS ドキュメント作成用のものがあるのですが、そちらは機密保持契約の対象になっているので、当然頒布はできません。
JTF 版は少々あっさりしすぎかなと思っていて、今ひとつの感が拭えないでいます。
ともあれ、そろそろベースのガイドラインを提案する時期に来ていますので、近いうちに別トピックで提案させていただきたいと思っています。それまでに SUN 版にざっと目を通しておいていただければ議論がしやすいと思います。
.
シングルバイト文字には数字も含まれます。
それですと数字が除外されてしまい、余計にルールが増えてしまいます。
.
翻訳するにしても、レビューをするにしても、下敷きとなる一定のルールがないと無駄に議論ばかりが増えてしまいます。そのため、「ルール化可能な最低限のものはルール化してしまう」のがこのポストの狙いであり、「ルールを明確化し一貫させること」に必要な作業です。
ですので、以上云々というか、「ルールを選ぶ」イコール「ルールを明確化し一貫させること」だと思います。
(なんだかレスがバラバラになってしまい、申し訳ありません)
途中経過
今のところ C-1、D-4、E-1 は決定で問題なさそうですね。
A-2、B-1 も kabetani さんが多数決でよいと仰っているので決定しても問題なさそうです。
となると、A にスラッシュを含めるかどうかが決まれば、ひとまず A-E はルール化を完了できそうですね。
Re:途中経過
私は、A-2、B-1、C-1、D-4、E-1 で問題ないです。
ただE-1について、出来る限りの努力を行ってもコア翻訳側の変更をする事が出来なかった場合、ユーザーガイド側の翻訳内容とコア翻訳が矛盾する箇所について、最終的にコア翻訳側に合わせる可能性があるという点については了承して頂きたいです。
(ユーザーガイドを読む方の混乱をさける為)
あと、数字について今のところ全員が半角で翻訳しているので特に取り決めは必要ないと思いますが、今後人が増えた場合に備えて、「数字はすべて半角とする」というのもどこかに追加して頂けるとありがたいです。すみません、こちらは「スペース／符号／カタカナ」の議論なので、上記の件は取り消させて頂きます。
.
了解しました。
ひとまず、スラッシュを含めるかどうかは後回しにしましょう。
とりあえず、決定したところから ｗｉｋｉ で日本ローカルの翻訳ガイドラインを作ってゆこうと思いますが、既存の翻訳ガイドラインのタイトルを「翻訳ガイドライン（翻訳）」と変更してよろしいでしょうか？
ローカル版はひとまず「翻訳ガイドライン（作成途中）」とでもしておこうと思います。
「数字を半角で」については、https://groups.drupal.org/node/517284#comment-1155278 で紹介した 2 種類のガイドラインのどちらにも記載がありますので、どちらかを採用すれば別途ルール化する必要はないと考えています。
既存の翻訳ガイドラインのタイトルを「翻訳ガイドライン（翻訳
はい、大丈夫です。
お手数おかけしますが、よろしくお願いします。
追加パターン（カタカナ複合語）
複数のカタカナ語が連続する場合も、ガイドラインによってルールが異なるため、これもルール化しておく必要があることに気付きました。
F として追加しますので、ご意見をお聞かせください。
F) カタカナ複合語の区切り（単語が 3 つ以上連続する場合）
（例： content entity type ※原文の文脈から「コンテンツ」は省略可能な場合もあるが、ここでは省略できない場合を想定）
区切らない
例： コンテンツエンティティータイプ
中点で区切る
例： コンテンツ・エンティティータイプ
スペースで区切る
例： コンテンツ エンティティータイプ
可能であれば「の」などで区切る
例： コンテンツのエンティティータイプ
Re:追加パターン（カタカナ複合語）
私は、
4が優先で、4が無理な場合は、2に一票です。
ただし特に強い推薦根拠は見つけられなかったので、多数の決定に従います。
http://www.jtf.jp/jp/style_guide/log/000268.htm
を読んだのですが、専門家の方でも色々意見が別れる案外難しい問題なのですね。
選択肢を追加
カタカナは表記ゆれが容認されていて、これが正解というものがないので、最終的には話し合いで決めてローカルでの正解を作るしかないのでしょうね。
たとえば、先の「レポート／リポート」などの古くから定着している語も、この先 100 年経っても統一は難しいと思います（国レベルで決めない限り）。
確かにその選択肢も必要ですね。
コメントの付いたコメントの編集はできないようですので、F-4 は削除とし、ここに選択肢を追加させていただきます。
例についてはすぐに思いつくものがないため、省略させていただきます。
5. 可能であれば「の」などで区切り、それが難しい場合は中点で区切る
例： コンテンツのエンティティータイプ
6. 可能であれば「の」などで区切り、それが難しい場合はスペースで区切る
例： コンテンツのエンティティータイプ
従って、kabetani さんの選択は F-5 ということですね。
私も F-5 でよいと思います。
F について、私も F-5 に賛成です！ F-5
F について、私も F-5 に賛成です！
F-5 でいくとどうしてもおかしくなってしまうような場合には都度相談させてください。
念のために確認させてください
それでは F-5 で決定としましょう。
その上で 1 つ確認しておきたいのですが、3 つ以上の単語で構成されるカタカナ語で、どうしても「の」などで区切れない場合、1 のパターンで区切るという認識だと思いますが、間違いないでしょうか？
言い換えると、
F) カタカナ複合語の区切り
（例： content entity type ※原文の文脈から「コンテンツ」は省略可能な場合もあるが、ここでは省略できない場合を想定）
（例： content entity type = コンテンツ・エンティティータイプ）
最初の提案で、2 単語までは区切らないという前提で候補を列挙してしまったのが失敗でした。
Re:念のために確認させてください
私はその認識でしたので、1 のパターンに賛成です。