Wikipedia:ガジェット/提案

最新のコメント:2 か月前 | トピック:IPユーティリティライブラリ | 投稿者:Whym

このページでは SpBot による過去ログ化が行われています。解決済みの節に {{Section resolved|1=--~~~~}} というテンプレートを設置して過去ログ化を提案すると、その節は 7 日後に過去ログ化されます。

Reference Tooltipsを既定で有効にしない提案

編集

このガジェットは2012年の提案にて、当時の英語版を参考に「規定で有効」という形で導入されました。これについて、先日の技術ニュースにて、各ウィキのユーザーエクスペリエンスを標準化するという目的から、規定では無効の状態にすることを推奨するというアナウンスが行われました。MediaWiki本体側の機能として脚注プレビュー機能が実装されたため、ガジェットを規定で有効化しなくても概ね同等の機能が提供されるようになったというのが大きな理由です。

そこで表題の通り、MediaWiki:Gadgets-definitionからReference Tooltipsのdefaultのオプションを外すことを提案します。ガジェット自体の削除は行われずログインユーザーであればいつでも任意で有効化できるため、影響は大きくないと考えます。推奨とのことなので、大きな反対がないようであれば勧告に従い規定での無効化を設定します。--Marine-Bluetalkcontribsmail 2024年2月6日 (火) 08:39 (UTC)返信

内部リンクとウィキ間リンクの文字色に差をつけるガジェット

編集

現在、各外装における内部リンクとウィキ間リンク(言語間リンクを含む)の文字色は下記のようになっています。

外装 内部リンク 訪問済内部リンク ウィキ間リンク 訪問済ウィキ間リンク
Vector #0645AD #0B0080 #3366BB #663366
Vector2022 #3366CC #795CB2 #3366CC #795CB2
MinervaNeue #3366CC #6B4BA1 #3366CC #6B4BA1
Monobook #002BB8 #5A3696 #3366BB #663366
Timeless #3366CC #2A4B8D #3377AA #275C83

Timelessで判別がつきにくく、Vector2022とMinervaNeueで色からまったく判別できなくなっています。Vector2022でこのようにデザインされた理由はphab:T213778にある通り、Web Content Accessibility Guidelines (WCAG) 2.0のレベルAA要求(リンク色と文字色のコントラスト比が3:1以上、リンク色と背景色のコントラスト比が3:1以上)を満たすためです。しかし、このリンク色変更には下記の欠点があります。

  • 内部リンク文字と白背景のコントラスト比が8.52:1(レベルAAA準拠)から5.36:1(レベルAA準拠)に下がっている。
  • 内部リンクとウィキ間リンクが見た目からまったく判別できなくなっています。

このほか、リンクが普通の文字より目立ちすぎるという意見もあるようですが、WCAG 2.0の要求はリンクを目立たせること自体を目的としており、欠点とは言えずトレードオフかと思います。しかし、リンクの種類が判別できないのは既存の利用者にとって不便になるので、普通の文字と多少見分けがつけづらくなっても簡単に元に戻す選択肢を提供すべきと考えます。したがって、Vector2022とMinervaNeue(とTimeless)でのみ適用される、下記のようなガジェットを提案します。

a {
	color: #0645AD;
}
a:visited {
	color: #0B0080;
}

既定で有効にすべきかについても意見を求めます。--ネイ会話2024年3月16日 (土) 13:54 (UTC)返信

ガジェット化については  賛成 、デフォルト化するかどうかは  保留。デフォルトにしてしまうとリンクの色が変わるので(特にスマホユーザ周りで)少し混乱が起きるのではと思います。ガジェット作成自体は問題ないと考えます。--鈴音雨 () 2024年4月19日 (金) 13:53 (UTC)返信
オプトインの選択肢として用意するだけならいいとは思いますが、むしろカスタムCSSとして置いておくか、外装そのものの改修を目指すほうがいいかもしれません。色の件は、日本語版ウィキペディア特有の現象ではないようです。そのため、本質的な解決は外装そのものに手を入れることでしょう。カスタムCSSは、global cssを通じて他のウィキでも適用しやすいです。グローバルのガジェットがあればもっといいですが、それはまだありません。 --whym会話2024年4月19日 (金) 23:15 (UTC)返信

IPユーティリティライブラリ

編集

test2wiki:MediaWiki:Gadget-ip-wiki.jsに仮作成しましたが、IPユーティリティモジュール(自作)をGadgets-definitionに登録させてください。(無論、ご意見等あればお寄せください。 )

右のボタンで展開
const gadget = 'ext.gadget.ip-wiki';
mw.loader.getScript('https://test2.wikipedia.org/w/load.php?modules=' + gadget).then(() => {
	mw.loader.using(gadget).then((req) => {
		const {IP, IPUtil} = req(gadget);
		[
			'192.168.001.001',
			'192.168.1.1/32',
			'::1',
			'fd12:3456:789a:1::'
		]
		.forEach((ip) => {
			console.log(IPUtil.sanitize(ip));
		});
		// 出力:
		// 192.168.1.1
		// 192.168.1.1/32
		// 0:0:0:0:0:0:0:1
		// fd12:3456:789a:1:0:0:0:0
	});
});

何を目指しているかというと、MarkBLockedのさらなる機能向上です。例えば、ページ内に192.168.1.0/24192.168.1.3192.168.1.122の利用者リンクがあったとし、192.168.1.0/24のみがブロックされており個別のIPはブロックされていないとします。現状、このような場合は個別の単一IPそれぞれについてAPIリクエストを飛ばさないと処理できません。一方、IPアドレスのビット演算処理ができるライブラリがあれば、非同期処理を行わずにこのあたりを判定できるようになります。(例:IPUtil.contains('192.168.1.0/24', '192.168.1.3'); // true、内部処理としては192.168.1.0/24の帯域を計算しそれに192.168.1.3が含まれているかを判定)上記のテストコードのように、ext.gadget.ip-wikiをロードすればユーザースクリプト内でもライブラリが使用できるようになります。
以上、ご検討のほどよろしくお願いします。 --Dragoniez (talk) 2024年8月20日 (火) 16:08 (UTC)返信

  --Dragoniez (talk) 2024年8月30日 (金) 18:27 (UTC)返信
その例では、従来ブロック状態を判定するために合計3回のAPIリクエストを行っていたところ、合計1回のAPIリクエストで済むようになるということでしょうか。「非同期処理を行わずにこのあたりを判定」というのは、192.168.1.0/24がブロックされているかどうかを先に判定すれば、192.168.1.3、192.168.1.122がブロックされているかどうかの判定は必要なくなる、ということでしょうか。「非同期処理を行わずに」というと、APIリクエスト0回で判定できるようになるというようにも聞こえますが。--whym会話2024年9月1日 (日) 10:52 (UTC)返信