Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Wikipedia

Wikipedia‐ノート:スタイルマニュアル/表

< Wikipedia‐ノート:スタイルマニュアル
（Wikipedia‐ノート:スタイルマニュアル (表)から転送）
最新のコメント：5 年前 ｜ トピック：良い例と悪い例の翻訳 | 投稿者：タバコはマーダー
このページについての詳細
経緯

「表を作成したらよい場合」

編集
最新のコメント：15 年前18件の コメント2 人が協議に参加

多数の色を並べて説明する必要がある場合、図によりますと訂正に高価な画像処理ソフトが必要になる場合があり、却って「自分以外の人には編集しにくくなる可能性が」あります。表ならばそのままブラウザで可能であり編集も容易です。それ故、そのことを「どんなときに表を作成するべきか？」と「表を使った場合に考えられる問題」に追加させていただきたいと思います。
また、という文言は例としては不適切だと思います。表の内容を問題視している場合もあるからです。これについてもより適切な言い方にするべきではないでしょうか。--Onyx 2008年8月31日 (日) 11:10 (UTC)返信

多数の色を並べて説明する必要がある場合、図によりますと訂正に高価な画像処理ソフトが必要になる場合があり、却って「自分以外の人には編集しにくくなる可能性が」あります。表ならばそのままブラウザで可能であり編集も容易です。それ故、そのことを「どんなときに表を作成するべきか？」に追加させていただきたいと思います。 （内容を修正。内容の分割。--Onyx 2008年9月13日 (土) 00:30 (UTC))返信

議論以前の問題として、プレビューを使って確認してから投稿されるようにお願い致します。見出しの「表を作成したら場合」とは「表を作成したら良い場合」か何かだと思いますがくだけすぎてすっきりせず、私が誤解している可能性もあるので次の投稿時にでも正しい表記を書いて下さい。後段の「また、」と「という文言は」の間に

<!-- この記事を編集するときには、表の部分を飛ばして、その後をご覧ください。-->

というのが隠れているわけですが、こちらも&lt;という方法をご存じなかったとしてもヘンだと気付いて何らかの代替方法がとれるはずです。
さて本題に入りますが、この文章ですと「多数の色」ならそれこそ表ではなく図にすべきではないのかということになり、事情を知らずにここを読む方には何のこっちゃわけわからん話題提起になってしまいます。事情というのは利用者‐会話:Onyx#表記ガイド等をご一読くださいでのOnyxさんと私との会話なんですが、どうしましょう、この場だけで意味が分かるような説明は可能ですか、とお尋ねするのも気がひけますが現に意味不明なわけでして…
後段の「この記事を編集するときには…」の件については改善の余地があると思いますが、議論する節を分けておいたほうが良いかもしれません。話が続くようなら分けるということでいかがでしょう。--鈴見咲 2008年9月4日 (木) 15:17 (UTC)返信

例えばオレンジ色 2008年9月12日 (金) 14:05冒頭のさまざまなオレンジ色、色　2008年9月12日 (金) 23:56の色の様相の三属性を説明する例などのように、画像によらず色を並べる場合を認めるべきです。先に述べた「多数の色を並べて説明する必要がある場合」とはこのような場合です。理由は既に述べました。画像ですと訂正が困難である場合もあります。色の「文化における色」において示されている画像であるColored pencils chevre.jpgは並びが奇妙ですが、簡単に訂正する訳にはいきません。en.wikipedia Value_(colorimetry)におけるColorValue.jpgは例えばAdobe PhotoshopのHSBに従った場合の明度の不揃いが目立ち、具体的な着色材(colorant)の指示でもないのに色相の移行が目立ちます。もちろんこれは(画像データの数字を読まずに)目視でも確認できます。また、それぞれの色相の選択の根拠もいまいちはっきりしません。このような問題が生じた場合にも、表を作成するなら、特殊なソフトによらずに編集できます。そして、それぞれの色の編集も容易です。また、画像を用いますと、説明に不便な場合もあります。その場合にも、一律に画像にせよとは、おかしな話です。本ガイドラインはこのような事例が考慮されていないので、このような場合を、「どんなときに表を作成するべきか？」に加えさせて頂きたく思います。--Onyx 2008年9月13日 (土) 00:30 (UTC)返信

ご説明ありがとうございます。いくつか疑問点はございますが、一度にやると大変なので重要そうなところから。
画像に依らずに色を並べる方法として表を用いることを認めるべきである、というご意見ですが、その理由に自分以外の人には編集しにくくなる可能性を示されています。従って、Onyxさんの主張は実質的には「画像に依らずに色を並べる方法は表に限定すべきである」ということになってしまいます。
しかしながら、ウィキペディアにはWikipedia:画像提供依頼というものがあります。欲しい画像、または訂正したい画像があってもすべてを自分で作業する必要はないのです。ですから、画像を訂正したくても自分ではムリというときは依頼をすればよいのであって、表の目的外利用にあたるルールを持ちこむ必然性はありません。まずはこの点において、ご提案には賛同致しかねます。--鈴見咲 2008年9月20日 (土) 10:23 (UTC)返信

だれにとっても容易な手段として表の利用を許容すべきと主張します。文言の不備から誤解を与えたようですので訂正します。画像の依頼が可能だとしても、大抵思うようなものには仕上がらないでしょうし、依頼から画像提出、再度依頼といった余計な手間が増えます。既存の不適切な画像に気付かないひとに依頼しても良い結果は得られないでしょう。また、容易さとより多くの人に開かれた方法であることは既に述べたつもりです。--Onyx 2008年9月28日 (日) 22:33 (UTC)返信

ここで議論されているのは色を並べて表現する場合に表を使えるようにすべきかどうかということですよね。ということは表で表現できる範囲の話ですので、その表を用いてこんなのを作ってくださいと画像提供依頼に出せば指定どおりになるのではありませんか？百科事典の記事中にそのような表の使い方をすると読む側のアクセシビリティに問題が出ますが、画像提供依頼であればそのページの性質上問題はないでしょう。
多くの人に開かれているかどうかについては「学べば問題を解消できる書き手」よりも「学習では対処のしようがない読み手」を優先したい、という意味で受け入れがたい提案であるというのが私の印象です。--鈴見咲 2008年10月6日 (月) 01:53 (UTC)返信

最後の一文の意味をはかりかねます。ご説明いただければ幸いです。色の記述を表に書き換えた場合の例を説明に使えるだろう程度に素描した例に大雑把に示してみました。縦幅は縮められますし、画像は適当に並べたのみです。しかしながら、枠で囲われた画像が並ぶ様は如何にも醜く文との不和が際立ち見難いです。それぞれの画像の作成、検証、修正はかなり面倒です。例えば、ひとつひとつ色面のピクセルを数えるなんて真似は徒労です。また、恣意性が高まるので、それぞれの並びを下手に組み合わせて一枚の画像をアップロードするべきでもありませんし。データ容量としても画像は不利、不便です。子細に手順を示しても、改訂の必要が出てくるときはあるでしょうし。その後、改訂の必要が出てくることは多いにあります。修正も面倒です。余談ですが、望む画像を私が作れないわけではありません。その無駄な徒労と編集にかかわる杜撰な出来を考慮して愚かだと思っているのみです。そもそも、鈴見咲が、必要な画像を用意するコストと現行の色を書き手の意図通りに表示するコストでは前者が大きいのではありませんか？少なくとも他の利用者の場合はそうだと想像します。また、Wikipedia:表のガイドラインに則っている表も依然として、表示は見づらいものという理解で妥当でしょうか。

別の話と言えば別の話ですが、色の該当箇所がHelp:表の作り方の何処に反しているのか、どのように反しているのか、お教え下さい。表を使った場合に考えられる問題にあるように編集の障壁となるとのことですが、既述の理由で、画像の方が編集の障壁となるでしょう。色関係の虚偽を修正してきましたが、依然として発生しますし、敢えて作業を増やすよう改訂するのは頂けません。--Onyx 2008年10月9日 (木) 11:28 (UTC)返信

前回の私の最後の一文、つまり学習では対処できない読み手を優先したいという話について。これはその部分の少し前にも申し上げていますとおりアクセシビリティを考慮した上での発言です。ウィキペディア(というかメディアウィキというソフトウェア)ではHTMLの<TABLE>タグを用いて表を表現するというのがもともとの姿であったらしいのは以前分割して下さった下の議題のなかで述べたとおりです。HTMLではアクセシビリティに問題が出るので使うべきでないとされている方法は、ウィキペディアでもやはり使うべきではないでしょう。
ところが表を用いて色を並べるというご提案は、どう転んでもここにひっかかってしまいます。表内の小区画に色だけを置いてしまうのは視覚障碍者本人か、スクリーンリーダに特殊な能力を期待することになってしまいます。「学習では対処できない読み手」というのはそういうことです。アクセシビリティを考慮する際、社会的少数派だけに負担を強いるのは避けるというのが肝要です。
「学べば問題を解消できる書き手」というのは、もちろん記事編集の初心者を指しています。こちらもウィキペディアにアクセシビリティを求める人々だと言えなくはありません。ですが読み手が査読しているのでもない限り、書き手が読み手より高い能力を要求されるのは文章一般に言えることです。そこで書き手がもう少しだけ学んで、時には工夫や手間もかけて執筆すれば、ここで議論しているような例外規定を作ることもなく、読み手のアクセシビリティを下げることもなしに百科辞典を作ることができる。このようなことを申し上げた次第です。
次の件。色の記述を「表に書き換えた」場合というのは「画像に書き換えた」の誤りですね。で、色の目次2.1「色の三属性」節とOnyxさんが用意して下さったページでは明らかな違いが二つ見られます。
  • a)画像の横幅に1200pxという現時点ではかなり大きい値が指定されていること。
  • b)本節の議題である表の部分に「枠付きで」画像が張り付けられていること。
「縦幅は縮められますし、画像は適当に並べたのみです」とのことですから縦の大きさと引用画像そのものについては触れなくてよいとして、上記二点について考える必要があります。
まずa)について。表でも1200pxの幅を指定できますから、ここでの議題に寄与しません。次にb)ですが、Help:画像の表示の説明にありますとおり、不要であれば付けないという選択ができます。一方Onyxさんのおっしゃった「醜さ」と「文との不和」はa),b)の指定によるものです。従って表で色を並べることを認める根拠にはなりません。a)とb)を避ければ済む話だからです。恣意性は表でも画像でも同じことでしょう。むしろ表のほうが弄りやすい分だけ恣意性も持ち込まれやすいとさえ言えます。
このほか画像作成の面倒さやデータ容量に言及されていますが、「表を使って色を並べることを認めるべきかどうか」という議論でどうしてそのような話になるのか未だによくわかりません。それ以前のなにか重要な前提をきちんと説明されていないのではないかという印象を持っています。そこで、私の議論イメージとして当該表部分の改変例を作ってみました。Onyxさんの考えていることと相違点がもしあれば教えていただけますか? また、相違点がないのでしたら、この例を検証された上での意見をお聞かせ下さい。いずれの場合でも「表を使って色を並べることを認めるべきかどうか」という観点に限定してのお返事をお願い致します。同じく議論を明確にするため「余談」と「別の話」についても当面パスさせていただきます。
高彩度色における色相の変化
 
高明度色における色相の変化
 
低明度色における色相の変化
 
--鈴見咲 2008年10月14日 (火) 02:05 (UTC)返信
Wikipedia:ノートページでの慣習的な決まり#レイアウトに従って、コメントして下さい。
恣意的に限定しての返答要求には、要求通りに答えられません。意味が判然としませんので。当方とて、鈴見咲さんとの雑談に時間を裂くつもりはございません。こちらもいちいち説明するのは面倒ですので子細な説明は省きます。
そこかしこに、HTMLタグが見受けられますので、本件こそが削除されるようなルールがあるようには思いませんが、HTMLタグ一切が使用禁止なのですか？
枠については私の誤解でした。撤回します。
私の意見を読み取ったのか計りかねますので、繰り返します。文脈違いならご指摘下さい。対応します。
それぞれの画像の作成、検証、修正はかなり面倒です。例えば、ひとつひとつ色面のピクセルを数えるなんて真似は徒労です。子細に手順を示しても、改訂の必要が出てくるときはあるでしょうし。その後、改訂の必要が出てくることは多いにあります。再度の修正も面倒です。今回の画像でいうと、四角の寸法が合っているか数えるのが面倒でしょう、ということです。表なら容易です。また、恣意性が高まるので、それぞれの並びを下手に組み合わせて一枚の画像をアップロードするべきではないでしょう。これは例えば、私が作ったものを模していながら鈴見咲さんのものの順序が異なることも示唆しています。この３つの画像をひとつの画像にすることを批判している訳です。鈴見咲さんの画像が何の順番なのか私には理解できる物ではありません。画像にすると直し難い、他人が確認しづらいとも言っています。表を使って色を並べることを認めるべきかどうか、の話だと思います。
その他、いちいち説明しませんが、鈴見咲さんの発言に対する(同意ではなく)反論を書きました。--Onyx 2008年10月15日 (水) 10:25 (UTC)返信
ノートページでの慣習の件は利用者‐会話:Onyx#ご指摘の具体的な内容を教えてくださいでお尋ねしますね。
HTMLの件は、タグに限らず使ってよいものと使用を避けるべきものがあるという意味です。そして表で使われる bgcolor は避けるべきものに含まれています。なお bgcolor はタグではなく属性です。
これまでOnyxさんと私とで「見栄えの異なる画像の製作」に関して面倒だ(Onyxさん)、どうして面倒なのか(私)？と言いあっているのではないかという疑問を持っていました。しかし、この度「四角の寸法が合っているか数えるのが面倒でしょう」という具体的なお話がでてきましたので、少なくとも横方向の並び・大きさ・形状などについては認識のズレがないことが確認できました。
それを踏まえて話を進めます。私がこのノートで提示した画像はSVG形式で作られており、実はご意見のような「(画素数を)数える」行為自体が不要です。まず、SVG形式の画像ファイルはテキストエディタで開いて編集することができます。四角の数を変えたい場合、テキストエディタ上での切り取り・複写・張り付けと数ヶ所の数字(座標)の足し算引き算で済ませることができます。色を変えたいだけならばまさに色を指定する部分だけを変更すればよく、HTMLの#rrggbbという16進数6桁の書式がそのまま使えます。投稿前における編集結果の確認にはMozilla Firefox、OperaといったウェブサイトブラウザやApache BatikのようなSVG専門のソフトが使えます。具体的にどういうテキストなのかについては直接画像を表示した状態(例)でウェブサイトブラウザからページのソースを表示するメニューを実行されるとよいでしょう。
このようなわけで改めてお尋ねしたいのですが、上記のようにテキストエディタで画像を作成できるという前提でのOnyxさんのご意見はいかがでしょうか。もちろん、このような画像の作成方法をヘルプページとして用意すべきとのことであれば、いくらかお時間をいただくかも知れませんけれども喜んで作成致します。
そのほか「３つの画像をひとつの画像にすること」を「批判」されていますが、私はそのような意見・提案を述べたことはありません。必要に応じて三つにするか一つにまとめるかを選択すればよいのですし、現に私の提示した例は三つに分かれています。また、その順序が壊されてしまうと意味が変わってしまうような理由があればそれは記事中に説明しておけばよいのです。編集者だけが注意すればよいのであればコメントとして残しておく方法があります。一つにまとめた場合でも、納得のいく説明があれば誤解で順番を変えられることはないでしょう。--鈴見咲 2008年10月21日 (火) 15:05 (UTC)返信
それならば事情が変わりますね。私の懸念は意味がありません。
HTMLの使用の可否について資料となるサイトなど教えていただけないでしょうか。bgcolorが何故避けねばならないか私は理解していないので。禁止でなければbgcolor〜ナンチャラも許容して頂ければありがたいのですが。
本旨から外れますが、この件に関して指摘しておいた方がよい事柄を見つけましたので書いておきます。例に、「彩度の高い色について色相の変化を12色並べて示したもの。現時点では他の属性(明度と彩度)が一定であるかどうかは未検証。」と書かれていますが、規格によっては同じ明度となる数字にしましたが、明度は構造上揃いませんし、揃えない方が、色相の指示に相応しいものなるでしょう。この場合、一次色と二次色の明度を揃えることにあまり意味は無いはずです。低彩度の例ならば、揃えても良いかも知れないですが。誤解を生むので、こういう情報は下手に足さない方がいいと思います。--Onyx 2008年10月23日 (木) 09:20 (UTC)返信
HTMLの各表現が使えるかどうかに関する資料ですが、基本はHTML 4.01 仕様書になるかと思います。メディアウィキはXHTML1.0を出力に採用しているようですが、XHTML1.0はおおむねHTML4.01をそのまま準用することになっています(下記仕様書参照)。で、HTML 4.01 仕様書の15.1.1 背景色でbgcolorは「推奨しない」とされています。最新傾向についてはW3C - HTML 5 differences from HTML 4 日本語訳/3.5 削除された属性が参考になるでしょう。ここでもbgcolorは削除(廃止)されることになっています。HTML5の完成は遥かに先の話ですがブラウザの対応と並行して整備されることになっているようです。
「本旨から外れますが〜」以降については、まさしく本節の内容から外れますのでここでのコメントは控えさせていただきます。もしかしたら別のところでお話しをすることになるかもしれません。--鈴見咲 2008年10月30日 (木) 08:55 (UTC)返信
勉強させて頂きます。暫くお待ちください。--Onyx 2008年10月31日 (金) 11:26 (UTC)返信
時間が取れず未だ手を付けていません。暫くお待ちください。
なお、IE、Safari、Firefoxでも問題なく閲覧できるのですが、どのような環境下だと支障があるのでしょうか？不適切な画像が蓄積されてしまうことについては如何お考えですか。--Onyx 2008年11月11日 (火) 11:40 (UTC)返信

(字下げ戻します)アクセシビリティ確保の目的を考えると、本件の場合「障礙をお持ちの方しか使ってないようなマイナーなものも含めて全てのブラウザでbgcolorの利用に問題がないこと」を示す必要があります。bgcolor以外の情報が表の中で提示されない本件のような使い方では、全てのブラウザがそれを「表以外の何か」として適切に処理できることを確認して廻らなくてはなりません。ですが、言うまでもなく完全な確認は不可能です。ただし不可能の原因がそういうbgcolorの使い方にあるのですから、その使い方こそが否定されるべきだというわけです。仕様に従った方法であれば、解釈できないブラウザがあったとしてもそれはブラウザの責任です(現実問題としてしかたなく記事側を調整することはあるでしょうけれども)。そうでない方法の場合、記事自身がアクセシビリティを考慮していないことになりますから、ガイドラインにも含めるべきではないことになります。

不適切な画像の蓄積があったとしても、話題のきっかけ程度しか本件提案との関わりがありません。従来の適切な方法で解決すべき問題です。--鈴見咲 2008年11月18日 (火) 09:20 (UTC)返信

従来不適切なbgcolorの使用で対応して来たものを別の手法で代替するのでしたら、画像による新たな手法は「従来の適切な方法」とは言えないのではないでしょうか。例えば南足立郡のbgcolorの使用は問題ないのでしょうか。このようなものなら問題ないのなら、これを一部修正する形で、不適切な画像を蓄積する事無く済ませる事が可能なように思います。画像によらずに解決する方法は無いのですか？単に「推奨しない」ものを禁止する理由が私には分かりませんでした。ご説明頂けますか？--Onyx 2008年11月19日 (水) 16:40 (UTC)返信
bgcolorの情報が失われても元の表の意味は失われない、というのが許容範囲の考え方として有効かと存じます。アクセシビリティが失われていないことと等価であればよいのです。南足立郡に使われている表は三色(町・村・二段階目の宿)が使われていますが、仮にこれらの色情報が失われたとしても表のなかでほとんどの地名に「町」や「村」が付いていて内容の判別は可能です。また（1町8村）などの形で表の前にその総数が示されており、この表の色が持つ役割を同様に果たす文言があります。従って南足立郡の記事における表はほぼ問題ないと言って良いでしょう。
もう一点、市町村合併史の規模はさまざまですので同じやり方がいつでも通用するとは限りませんが、しかしどの市町村でも色が「副」の位置付けにあることは変わらないでしょう。このノートで議論されているのは色そのものが「主」の位置を占める方法であり、そのためbgcolorの情報を拾わない限り何が記されているのかわからない所に大きな違いがあります。--鈴見咲 2008年11月27日 (木) 05:26 (UTC)返信

「表を使った場合に考えられる問題」

編集
最新のコメント：16 年前5件の コメント2 人が協議に参加
<!-- この記事を編集するときには、表の部分を飛ばして、その後をご覧ください。 -->

という文言は例としては不適切だと思います。表の内容を問題視している場合もあるからです。これについてもより適切な言い方にするべきではないでしょうか。--Onyx 2008年9月13日 (土) 00:30 (UTC)返信

なんとなく不自然さを感じていたのでちょっと調べましたところ、その項目(記事に表があると、自分…)とその次の項目(HTMLの経験が豊富な人にとっても…)はかつてHTMLの<TABLE>タグでしか表を書けなかった時代の文のようです(参考)。そこで2つまとめて新しい文章にする試案。
  • 自分のウェブブラウザでは見栄えが悪いという理由で、しばしば表に書式指定などを付け加えたくなります。ところがその書式指定のために他のウェブブラウザで見栄えどころか可読性まで失ってしまうことがあります。概して表は広く安定して見せることが難しいため、なるべく避けることが望ましいのです。
初心者にとって…とかは各々表の複雑さに依るのでばっさり削除で。--鈴見咲 2008年9月20日 (土) 10:23 (UTC)返信
削除に同意します。速やかに対処下さって構いません。--Onyx 2008年10月9日 (木) 11:28 (UTC)返信
削除なさいませんか？--Onyx 2008年10月15日 (水) 10:25 (UTC)返信
対処いたしました。--鈴見咲 2008年10月16日 (木) 23:49 (UTC)返信

改訂提案

編集
最新のコメント：15 年前11件の コメント2 人が協議に参加

本ガイドラインにおける「どんなときに表を作成するべきか？」および、「表がふさわしくないのはどんなときか」の改訂を提案致します。--マクガイア 2009年6月22日 (月) 22:27 (UTC)返信

改定案

編集

== どんなときに表を作成するべきか？ ==
表は一般にデータ集を見易く整理・表示する事が出来、特にデータが予め行と列で表せる形式になっていれば、大抵の場合は表にするのが最も良いやり方です。また行・列で表せるデータであれば、必要に応じてソート機能を使う事により一つのデータ集を多角的に提示する事も出来ます。

表の使用が適切な例としては、以下のようなものがあります。

  • 数学の表
    • かけ算九九の表
    • 約数の表
    • ルックアップ
  • 多項目に渡る情報の一覧
    • 同じ単語を二つ以上の言語で表記する
    • 人、誕生日、居住地リスト
    • アーティスト、アルバム、発表年、レーベル

== 表がふさわしくないのはどんなときか ==
上述の通り、行と列で表せる情報を表示するのにあたり表の使用は有用な方法です。しかし、表の編集にはやや複雑なマークアップを理解する必要があり、後からの編集が難しくなるという短所があります。従って、表を使用する利点が少ないのであれば、表の使用を避けて平易なマークアップで済む箇条書きを使用する方がより適切です。表の使用を考えた際にはまず、「表を使用する事によりどのような利点があるか」を具体的に考えてみて下さい。その利点を具体的に説明する事が出来ないのであれば、おそらく表の使用は最善の方法ではありません。

また、表はレイアウトだけのために使うべきではありません。あなたが編集している情報が、表形式で書くべき性質のものでなければ、表形式では書かない方がよいでしょう。写真の下にキャプションを入れたり、一覧のグループを整理したり、その他見栄えを変えるだけのために、表は使わないようにして下さい。他のウィキペディアンにとって記事が編集しにくくなりますし、表の本来の使い方ではありません。

=== 非常に短い一覧 ===
一覧がごく簡素な場合には箇条書きを使って下さい。簡素な一覧は、行・列を使うまでもなく十分に読者が理解できます。ここに、表の代わりに箇条書きを使う方がよいと思われる例を挙げます。

以下同じ

--マクガイア 2009年6月22日 (月) 22:27 (UTC)返信

議論

編集

この改訂の目的としましては以下の2点が大きな目的となっています。

  1. 「ふさわしくない場合」としての説明の根幹部分が「作成するべきか?」に含まれている事の見直し。
  2. 「表が長い事」を理由として、表の使用を制限しうる現状の改善。

1.については上記まとめの通りでして、現状では相応しくない場合の説明の多くが「作成するべきか?」側に含まれており、「表がふさわしくないのはどんなときか」の説明としては不十分であると考えたためです。

2.についてはWikipedia‐ノート:ウィキプロジェクト 漫画雑誌/連載作品の一覧でこちらのガイドラインを引き合いとして「長すぎるの作るな」との指摘を受けた事が直接のきっかけとなっています。

長い表の編集が難しいというのは確かに大きなデメリットではありますが、「長い事」で禁止であるように捉え得る現状の文面はWPの発展・特に一覧記事の充実に取って好ましくない物であると私は考えます。理由は以下の通りです。

  • 一覧としての質向上を目指せば、長い表を使用する必然性が高い場合があるため。
  • 個人差はあるであろうが、「長い事」は後からの保守作業の難易度を必ずしも上げないため。
    • 私の経験則として、ソースを一望できない分量となってしまえばエディタの検索機能を使って修正箇所を特定した方が効率的であり、検索機能を使うのであれば母集団の大きさはさほど作業の難度に影響を与えません。体感的な数字としては30以上であれば100であろうと500であろうと1000であろうとさほど変わらない様に思います。もちろん、一つのずれにより列全体を修正しなければならない……という状況など、行数が少ない方が楽な場合もありますが、表の保守作業としてはそう頻度の多い物ではないと考えますし、こうした場合というのはそもそも表でなかったとしても保守作業が大変な物です（表計算ソフトを下書きに使用すれば、場合によっては表の方が楽かもしれません）。

以上により私としては、「長い事」はそもそもとして「表がふさわしくない」場合には当てはまらず、これを制限する事は一覧記事の発展を阻害する物であると考えます。「誰でも編集できる」 というのはあくまで「質量ともに最高の百科事典を創り上げる」という目的を達成するための手段であり、この手段を達成するために目的の一部である質を落としかねない様なガイドラインは本末転倒ではないでしょうか。

御意見よろしく御願致します。--マクガイア 2009年6月22日 (月) 22:27 (UTC)返信

例示されたen:List of Nintendo 64 gamesは項目数は多いですが、現在はもう新作ソフトが発売されていないようですので、これ以上項目数が増える可能性は低いでしょう。一方で、たとえば週刊少年ジャンプ連載作品の一覧は刊行中の漫画雑誌に連載されている作品を扱うわけですから、今でさえ多いのに、今後もさらに増え続けることが予想されます。この点で両者には違いがあるように思います。
表の項目が増え続けますと、読者側にとっては全部読もうとするとかなりスクロールしなくてはならず、読みにくくなります。また低速な回線で接続している場合、ページの表示に時間がかかることが考えられます。このような理由から、分割が検討されることがあるかもしれません。しかし分割してしまいますと週刊少年ジャンプ連載作品の一覧で採用されているような項目のソートはあまり意味がなくなってしまいます。年代順や五十音順などに変更できるといっても、それはひとつの記事にまとまっているからこそ意味が出てくるのではないでしょうか。ソートを用いないのでしたら週刊少年サンデー連載作品の一覧のような箇条書き形式でも情報量としては十分だと思います。
「長い」という基準もあいまいですので、ケースバイケースでの対応がよろしいかと思います。英語版の例もありますし、長い一覧に表を使用することを一律に禁止するのは好ましくないと考えますが、長い一覧への使用に基準をいっさい設けないというのもいかがなものかと思います。--長月みどり 2009年6月23日 (火) 19:08 (UTC)返信
スクロールについて
例えばen:BAFTA Award for Best Filmであれば一つ一つの表自体であれば1950sの220ほどのものが最大ながら、表の行の総数では800ほどとなりますし、同様にen:List of birds of Thailandであれば総数で1000を越えています。またen:List_of_birds_of_Canada_and_the_United_Statesのようにテーブルを使っていないくても行数が膨大な一覧もあります。もちろん閲覧環境に因る違いはありますが、多くの方に取って今回提示した様な記事は、スクロール量と言う点では『ジャンプ』の一覧よりも多くなっている様に見受けられます。分節による目次機能が使えている事を理由として、スクロール量の単純比較だけの問題ではないとの見方も出来ますが、この点につきましてはen:List of Nintendo 64 gamesで使用されている目次を応用する事により、多くの場合は問題を解決出来るのではないかなと現在考えております。
表示時間について
例えばen:List_of_counties_in_Texas（250行ほど）・en:List_of_extant_papal_tombs（120ほど）・en:List_of_temples_of_The_Church_of_Jesus_Christ_of_Latter-day_Saintsのように画像を多分に含んだものであれば、行数はジャンプ一覧よりも少なくても総サイズは大きくなり、より多くの表示時間を必要とします。
上記の例はいずれも秀逸な一覧として選ばれているものですし、こうした事例を踏まえますに「長い事だけ」で制限を設けるというのは難しいように思います。またこうしたご指摘の問題は「長い表」に限らずサイズの大きい記事であれば全てに当てはまる問題ですので、もしこの問題が根本的に解決しなければならない問題であるのであれば、この場で「長い表」を制限するよりも先に、まずは「大きい記事を制限するルール」を整備をすべきであるように思います。「サイズに関するルールがあった上で、この場で長い表についても触れる」という形ならまだ分かりますが、「サイズだけのために何かを犠牲にしても良い」というのはWPの目的を脅かしかねない非常に重い決定であり、表単独でガイドライン化してよい事ではないと私は考えます。「技術的な問題で重度のエラーが出る」状況などサイズによる致命的な問題が発生しているのであれば話は別ですが（またそのような状況であればガイドライン等がなくても対策が必要になるでしょう）、サイズに限らず記事の充実のために必要な事については原則として制限をかけるのは慎重に慎重を重ねる必要があるのではないでしょうか。
私の探した限りではこの辺りの根拠となりそうなものとしましてはHelp:ページサイズがありますが、まずこの文章は方針やガイドラインではなくヘルプ文章です。そして同文章では「あまりにページサイズが大きい場合は、記事の分割が推奨されます。」として、その解決方法としては原則、分割のみを提示しています（表のサイズを小さくする方法というのもありますが、表の使用をやめるという解説はありません）。そして解決方法であるWikipedia:ページの分割と統合では、『分割すべきでない場合』として「1つにまとまっているべき情報である場合」と「サイズのみを理由に分割がされるわけではありません」というものがあり、両項により多くの一覧については分割の対象外である事も明示されています。
分割の結果として『ジャンプ』一覧の倍ほどのソース分量となっている日本工業規格（化学）の一覧という記事もありますし、長さによる表使用の制限はマイナス方向の結果ばかりが発生する様に私は感じています。--マクガイア 2009年6月25日 (木) 22:38 (UTC)返信
まず、申し上げましたようにen:List of Nintendo 64 gamesと、週刊少年ジャンプ連載作品の一覧とでは、既にほぼ完結している一覧と今後も項目が増え続けていく一覧という違いがあると思います。増え続けた場合は、読みにくくなるということもありますし、分割が検討されるかもしれません。
Wikipedia:ページの分割と統合#分割すべきでない場合には、おっしゃるように「1つにまとまっているべき情報である場合」とあります。しかし、実際には例えば『しゅごキャラ!』としゅごキャラ!の登場人物のように、1つにまとまっているべき情報が分割されるケースが多数見受けられるのではないでしょうか。『カードキャプターさくら』のように1ページに情報が上手くまとまっているのが理想的なのでしょうが、それでも多数の記事が分割されているのは、Wikipedia:ページの分割と統合#分割すべき場合の「ページの分量が肥大化したため、読者にとって全体の見通しが悪く不便な場合」や「ページ中で特定の説明だけの分量が多く、明らかにバランスを失している場合」に該当するものと考えられているからではないでしょうか。例示しました記事は一覧ではありませんが、ガイドラインが一覧かそうでないかにかかわらず全ての記事を対象としている以上、一覧が分割の対象外と言い切れるものではないと思います。現に日本工業規格（一般機械）の一覧（B 0000-0999）のような記事も存在します。
週刊少年ジャンプ連載作品の一覧につきましては、Wikipedia‐ノート:ウィキプロジェクト 漫画雑誌/連載作品の一覧によりますとソート可能なことに表を使用する意味があるとおっしゃっていました。それ以外で、週刊少年サンデー連載作品の一覧のような箇条書き形式を使用したものと比較して、どのようなメリットがあると考えられているのでしょうか？ 改定案には「従って、表を使用する利点が少ないのであれば、表の使用を避けて平易なマークアップで済む箇条書きを使用する方がより適切です」とありますし、あまりに長くなりすぎた（もしくは将来的にそうなる可能性が高い）表においてまでメリットのほうがデメリットを上回るということには、正直まだあまり理解はできていません。
あと、例示の英語版の一覧が秀逸な一覧であることを挙げられていますが、秀逸かどうかを決めるのは編集者側です。読者にとっては、秀逸であるかどうかが利便性に直結するとはかならずしも言えないと思います。長くて読みにくいと思う方がいらっしゃることをはたして否定することができるのでしょうか。--長月みどり 2009年6月26日 (金) 18:30 (UTC)返信
「これからも増え続ける」と言う点につきましては、増えた結果として問題が発生した時点で対策を行なえば良いと考えます。日本工業規格（化学）の一覧程度の容量であれば問題がないのであれば、あと40年ぐらいは大丈夫かもしれないわけでして、遠い将来の事を考えるよりも現時点で最高のものを目指す方が重要ではないでしょうか。
「1つにまとまっているべき情報」と言う点につきましては、「作品」と「作品の登場人物」の様な分割と「一覧」の分割では問題点が異なると考えます。前者は単なるサイズの問題ではなく記事全体のバランスが重要ですし、記事の階層化による「視点の異なる記事」という一面があります（もっともそうした面からすれば、単に2つに分割しただけで本記事側に最低限の登場人物に関する記述を加筆しない「よくある分割」には問題を感じておりますし、そうした面の是正策として、私としましてはWikipedia:キャラクターの記述に対するガイドラインの整備作業を進めております。）。こうした記事の関係はメインカルチャーで言えば日本の歴史と平安時代の関係のようなものであり、「1つにまとまっているべき情報」であるとは言い切れません。一方、一覧は「データが1つにまとまっている事に意味がある」という面があるため、「1つにまとまっているべき」という要素が特に強いものです。例えば索引のように、あまりに膨大になってしまったものを分割するのはやむを得ない場合は確かにありますが、そのような場合であっても、目次等によって互いを密接に繋げる事により一つに近づける対応が取られます（その点で、日本工業規格（一般機械）の一覧（B 0000-0999）は前後に対するフォローが不足しているように思います）。そして、ソート機能が有用なものであれば、分けてしまえばその有用性は激減します。従って一覧の場合は「1つにまとまっている」事が一覧の質にも大きな影響を与え得るものであり、前者との単純比較は出来ないのではないでしょうか。
「表を使用する利点」というのは、見易くする・情報の把握を容易にするといったように、常にWPの目的である「記事の質」に関わるところにあります。一方「表を使用しない利点」というのはWPの目的とは直接無関係で副次的な「記事のサイズ」にしかありません。「記事のサイズが大きくなりすぎた際に、その対策をとる」という事を必ずしも否定は致しませんが（しかし非常に主観的なものであり、明確な基準値を定められないのであれば、これだけを理由として質に関わる部分を犠牲とするのは現実的な問題が発生している場合に限るべきだと思います）、その選択肢は「表をやめる」だけではないはずです。そもそもとして表の長さは「一緒にまとめるべきデータの量」によって決まるものですから、これを箇条書きにしたところで、サイズが小さくはなっても行数はほとんど変わりません（ジャンプの一覧はふりがなで増えていますが、これは割と特殊な例ですので一般論に当てはめる事例ではない様に思います。）ので、表でなくしたところで短くはなりません。それどころか、視認性に劣る箇条書きに変更するのですから、より理解は難しくなるはずです。表とはデータを見易く・情報の把握を容易にする為に使用されるものですので、データ量が多く長い表であればその効果は長ければ長いほど出てきます。「表が長い」という事だけを理由として使用を制限できる文面というのは、質の向上を阻害し得る非常に危険なものです。Wikipedia:ページの分割と統合で「サイズのみを理由に分割がされるわけではありません」とされているのも、サイズとは記事の質に取っては副次的なものであり、（余程の事がない限り）それだけを理由にした分割は記事の破壊に繋がり得る事に配慮したものであると私は捉えています。
「読者には長くて読みにくいと思う人がいるかもしれない」事は否定できませんが、これは前述の通り（少なくとも英語版の秀逸な一覧については）表をやめたところで解決はしませんし、「ネタバレを嫌う人がいるかもしれないから全ネタバレを記述するな」というのと同じ様な事であり、「百科事典」という目的から外れた利用者への考慮を第一とはすべきではないと考えます。審議の結果として「最高の一覧と考えられている (we believe to be the best lists) 」秀逸な一覧は「百科事典の一覧」として優れているものであると見て問題ないのではないでしょうか。
例として上がっている、週刊少年サンデー連載作品の一覧は「サンデー連載作品の索引」としてならば使えるかもしれませんが、それ以外の目的では正直使い物になるとは思えず、百科事典に求められる一覧としてはその役割を果たしているとは思えません。週刊少年ジャンプ連載作品の一覧との比較については、Wikipedia‐ノート:ウィキプロジェクト 漫画雑誌/連載作品の一覧の方で発言させて頂きます。これは、まとめた文章が「表のガイドライン」という一般論にはあまり関係のない「漫画雑誌の連載作品の一覧」についての内容となっており、この場に投稿するには場違いのものであると判断した事によります。--マクガイア 2009年6月28日 (日) 07:10 (UTC)返信

（インデント戻します）週刊少年ジャンプ連載作品の一覧と週刊少年サンデー連載作品の一覧の比較につきましてはそちらに移すことでよいと思います。ただ、わたしとしましては、同じような内容を扱っている一覧において、表を使用した場合と箇条書きを使用した場合とで、どのような違いがあるかということを比較するのは重要ではとの観点から例示させていただきました。たまたま例が漫画作品の一覧であったというだけでして、ここで扱うことが場違いであるとはかならずしもいえないように個人的には思うのですが。

もう一度わたしの意見を整理させていただきますと、

  1. 単に「長い」というだけで作成そのものが禁止されているような文面には問題があり、「長い」は削除すべきである。
  2. ただ、Wikipedia:ページの分割と統合#分割すべきでない場合の「1つにまとまっているべき情報である場合」に該当すると考えられるのにもかかわらず、 ノート:日本工業規格（電気・電子）の一覧#分割提案によりいくつかの一覧記事は分割されている。これは、Wikipedia:ページの分割と統合#分割すべき場合にある、「ページの分量が肥大化したため、読者にとって全体の見通しが悪く不便な場合」にあたると考えられる。そのため、ケースバイケースで分割を認めてよいのではないだろうか。

以上の2点になります。1. は問題ないと思います。2. につきましては、マクガイアさんは一覧の分割にあまり賛成されていないようですが、個人的にはもっと柔軟に対応できたほうがよいのではとの考えからです。ソートを使用した表では分割により無意味になりますので、そのような場合は対象外にするとよいと思います。分割につきましては必要であれば個別のノートで検討することになりますが、（表を使用した）一覧の分割そのものが非推奨ともとれる点がひっかかっています。--長月みどり 2009年6月28日 (日) 18:37 (UTC)返信

見返してみますと、Wikipedia‐ノート:ウィキプロジェクト_漫画雑誌/連載作品の一覧に投稿した2-4段落目は一般論として「表を使う事」と「表をやめる事」のメリット比較としても問題がなかったですね。漫画誌に限らない一般論としてまとめ直しますと以下の様な感じでしょうか。
データが予め行と列で表せる形式になっているのであれば、表を使用する事によりデータを見易く・使い易く提示する事ができる。特にデータが多項目に渡っている場合は、ソート機能を併用する事により一つの情報を多角的に提示することも可能となる。またソート機能を使用しない場合であっても表を使用する事によってデータに縦の軸が通り、リストの順番を決定している筆頭項目以外からもそのデータの背景を読み取り易くなる。
具体例として週刊少年サンデー連載作品の一覧の場合、データは作品名・作者名・連載開始・連載終了と多項目に渡って充実していながら作品名の五十音順での箇条書きのとなっている為、作品名からしかデータを引けなくなっている。例えば「1980年代の作品を探す」といった使い方をしようとしても、「連載開始」のデータは作品名や作者名といった前に書かれている項目の長さに依存して位置が不定なため「連載開始」時期から作品名を引くという事は難しく、せっかくの充実したデータが死に体となっている。これにソート機能付きの表を使用すれば、「連載開始」で並び替えをする事により「1980年代の作品を探す」事が容易になるなど、一つのデータを多角的に取り出す事が可能となる。またソート機能なしの表であっても縦の軸を辿ってデータを見る事ができるため、ソート付きには及ばないながらもデータを多角的に使用する事が容易になる。
よって表の使用はそれが適切な場合、記事の質向上に様々なメリットを持っている。一方で表が効果的な場合に表を使用しない事のメリットは「サイズ抑制」以外にはない。しかし、サイズというのは記事の質にとっては後からついてくる副次的な要素であり、その副次的な要素のために記事の本文である質を犠牲にしなければならないという事を踏まえれば、この「サイズに対するメリット」を「記事そのものに対するメリット」と判断するには極めて慎重な議論が必要である。
1.2.共に意見の根幹としては違いはない様に思います。違いは、私と長月みどり氏の「質とアクセシビリティの釣り合いのポイント」にあり、私の方が「アクセシビリティよりも質をかなり重視している」という事なのだと思います。改めて、自分の当ガイドラインに対するスタンスをまとめてみますと以下の様な感じす。
「表が長い」ことは、それだけでは表をやめる・分割をするといった根拠とは成り得ない。もちろんこれはサイズの問題等からの「表をやめる」という選択肢を完全に無くすものではないが、長い表こそ「表である事のメリット」は大きく、質を犠牲にし得るこの判断はより慎重に下される必要がある。分割についても「一つである事に意味がある」場合があるため同様に慎重にあるべきだが、一方で必要であるならばWikipedia:ページの分割と統合に基づき行なえば問題はない。「表をやめる」「分割をする」という判断については、現実的な問題が発生しているのであれば本ガイドラインとは関係なく対応できるものであり、本ガイドラインにおいては「長い表を禁止する」と安直に取り得る様な文面を避ける必要と併せれば触れるべきではない。
こうした考えの元、改定案では「長い表」を禁止としない反面、分割等についても制限する様な文面は含めていません。これは、今回の改定案の目的はあくまで「長い表はすべからく表の使用をやめるべきである」という考えに根拠を与えている状況を是正することにあり、一覧に対する分割抑制や表の推奨という点にはないからです。私自身が一覧に対して「分割抑制」や「表の推奨」という考え方を持っている事はこれまでの議論の通りですが、その辺りはこのガイドラインに含めるべき内容ではないと考えています。--マクガイア 2009年6月30日 (火) 22:32 (UTC)返信
おっしゃるように「質とアクセシビリティの釣り合いのポイント」に違いがありますので、全く意見が一致するということにはなりませんが、「表を使うこと」と「箇条書きを使うこと」とのメリットの比較はわかりやすいと思います。ただ、
＞一方で表が効果的な場合に表を使用しない事のメリットは「サイズ抑制」以外にはない。
につきましては、
  • 一から表を作成するには長ければ長いほど時間もかかり難しくなる。項目の追加の際にも編集がやや複雑になる。
ことも挙げられます。「サイズ抑制」と関連はありますが、今まで長い表が非推奨とされてきた大きな理由ではないでしょうか。
長い表ではないのですが、例えば政令指定都市#指定都市に関連する事項で使用されている表にはソート機能があります。これを用いますと人口順に並び替えることなどが容易にできますから、そのような点において表のメリットはわたしも感じています。
分割につきましては、Wikipedia:ページの分割と統合という文書がありますから、あえてここで触れる必要はないと思いました。分割が検討された場合はそちらを根拠とされればよいですし。そのため、長い表の使用そのものが禁止ともとれる文面を削除し、分割に関しては特に触れないという今回の改定案が無難だと考えます。--長月みどり 2009年7月1日 (水) 18:56 (UTC)返信

（報告）最後に頂いた御意見から10日以上経ちましたが反対意見がありませんでしたので、改定案を反映致しました。上でも申し上げていますが今回の改訂は「長い表を問答無用で禁止する」という事を避けるための物であり、「長い表を野放しに推奨する」という物ではありません。発端となったWikipedia‐ノート:ウィキプロジェクト 漫画雑誌/連載作品の一覧等におきましても、「長い事のデメリット」を理由とした提案を制限する物ではない事を改めて明示させて頂きます。--マクガイア 2009年7月12日 (日) 22:21 (UTC)返信

改名提案

編集
最新のコメント：8 年前6件の コメント2 人が協議に参加

Wikipedia:表のガイドラインからWikipedia:表へ改名します。どこからも参照されていない現在リダイレクトのWikipedia:表が改名先となりますので、リダイレクト内容の変更あるいは削除で対応することもあるでしょうが、これも提案します。

改名理由として、現在ガイドラインではないので、「のガイドライン」とする必要がありません。また、本文書はWikipedia:方針とガイドライン#名前の付け方の整備前に作成された文書ですが、現行ではガイドラインにも「のガイドライン」とする必要がないということもあります。

2005年にWikipedia:表が作成されWikipedia:表の作り方へリダイレクトされ、後にその文書名がHelp:表の作り方に変更されました。2007年にWikipedia:表のガイドラインが作成されました。その後のWikipedia:方針とガイドライン#名前の付け方では「ガイドライン」と書く必要がないという文書が用意されたので、この改名先が「Wikipedia:表」となります。「Wikipedia:表」はまったくどこからも参照されていなかったため、リダイレクトの存在自体が定着していないと考えられます。これらの整合をとり、「Wikipedia:表のガイドライン」を「Wikipedia:表」へと改名します。

また、改名後にリダイレクトとなる「Wikipedia‐ノート:表のガイドライン」の即時削除も、リダイレクト先を変更する対応次第、削除できるよう提案します。--タバコはマーダー（会話） 2016年8月9日 (火) 02:32 (UTC)返信

改名自体は賛成ですが、Wikipedia:表だと簡潔過ぎて何の文書かイメージしづらいのが気になるところです。表を使う／使わない／どういう風に使う、というのはスタイルの話なので、対応する英語版のen:Wikipedia:Manual of Style/Tablesに倣ってスタイルマニュアルシリーズの一つとし、Wikipedia:スタイルマニュアル (表)ではどうでしょうか？ --Yapparina（会話） 2016年8月15日 (月) 11:22 (UTC)返信
その案はいいですね。ご提案ありがとうございます。思いつきませんでした。--タバコはマーダー（会話） 2016年8月16日 (火) 04:15 (UTC)返信

新しい案を入れて、Wikipedia:表のガイドラインからWikipedia:スタイルマニュアル (表)へ改名。リダイレクトのWikipedia:表はWikipedia:スタイルマニュアル (表)へリダイレクト。

「Wikipedia‐ノート:表のガイドライン」の即時削除も、リダイレクト先を変更する対応次第、削除できるよう提案します。--タバコはマーダー（会話） 2016年8月16日 (火) 04:26 (UTC)返信

改名しました。--タバコはマーダー（会話） 2016年8月23日 (火) 08:40 (UTC)返信
「Wikipedia‐ノート:表のガイドライン」へリンクしているページですが、リダイレクトの変更処理をしました。利用者空間が残りますが、IgiturとOjjiy氏の文書はノートではない文書自体にリンクしていますので転送可能です。利用者空間の扱いがわかりませんが、ブロックされている、お二人、Suzukitaro、会話ページのOnyx氏はノートにだけリンクされています。即時削除を依頼します。--タバコはマーダー（会話） 2016年8月23日 (火) 08:40 (UTC)返信

良い例と悪い例の翻訳

編集
最新のコメント：5 年前7件の コメント3 人が協議に参加

現在、表の良い例と悪い例がWikipedia:スタイルマニュアル (表)#表がふさわしくないのはどんなときかで示されていますが、実例が少なすぎてイメージをつかみにくいです。本家英語版ウィキペディアのen:Wikipedia:Manual of Style/Tablesのen:Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Avoiding column headers in the middle of the tableで解説されている表の良い例と悪い例を忠実に翻訳して、こちらに紹介したいのですが、よろしいでしょうか。--Markbotedit（会話） 2018年12月24日 (月) 07:38 (UTC)返信

本ページは日本語版ではガイドラインになっていないので、更新しやすいですからぜひやってみてください。--タバコはマーダー（会話） 2018年12月24日 (月) 07:43 (UTC)返信
ありがとうございます。丁寧につくるよう頑張ります。--Markbotedit（会話） 2018年12月24日 (月) 07:46 (UTC)返信
  コメント 将来ガイドラインにするつもりなら、提案したノートをWikipedia:コメント依頼やWikipedia:コメント依頼/リストやプロジェクト:プロジェクト関連文書/リストなどに掲載したり、本体側で告知したりする手順を踏んだ方が良いと思います--aki42006（会話） 2018年12月24日 (月) 10:24 (UTC)返信
アドバイスありがとうございます。今後、検討しておきます。--Markbotedit（会話） 2018年12月29日 (土) 17:22 (UTC)返信

  完了 翻訳しました（特別:差分/71121253）。--Markbotedit（会話） 2018年12月29日 (土) 17:22 (UTC)返信

ありがとうございます。日本語版では文書が古いですから、より新しい感じに更新されました！--タバコはマーダー（会話） 2018年12月29日 (土) 18:12 (UTC)返信
話題追加
「https://ja.wikipedia.org/w/index.php?title=Wikipedia‐ノート:スタイルマニュアル/表&oldid=84069085」から取得
プロジェクトページ「スタイルマニュアル/表」に戻る。