维基百科:互助客栈/其他

本页讨论與維基百科有關的话题,但不包括新闻方针技术求助條目繁简处理

  • 如果您需要就具体条目应当如何编辑才符合中立性原則寻求社区共识,请前往條目探討留言。
  • 請在主題欄简明扼要地寫出問題主旨不要使用如「新問題」等無意義的文字。
  • 請勿公開姓名、地理位置、電話、Email地址等联系資料。我們通常只在此頁回應,並不利用Email或電話等私下回應。
  • 無關維基百科專案的問題,請往知識問答相關頁面询問。


請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 抛砖引玉一下 81 18 MilkyDefer 2022-05-20 21:14
2 提議新增每月協作項目 1 1 Jimmy-bot 2022-05-28 00:14
3 禁止摘编、链接等用途的被引用来源 16 6 Kethyga 2022-05-20 20:16
4 移除首页“你知道吗?”板块的“更多新条目”链接 19 12 12З4567 2022-05-25 20:59
5 设置过滤器拦截在条目中插入简短描述的编辑 14 8 Ohtashinichiro 2022-05-08 18:11
6 关于Template:Itn/special-header 32 9 Lucien09 2022-05-23 07:09
7 重啟逐筆巡查標記的討論 91 11 Cwek 2022-05-27 13:59
8 又找到一個鏡像網站 2 2 角色扮演对话 2022-05-18 09:55
9 新建一个去除图片介绍末尾标点符号的机器人 6 6 Temp3600 2022-05-21 01:20
10 Module:Citation/CS1/Identifiers中提高s2cid上限 1 1 Ghrenghren 2022-05-18 23:29
11 注入特制的TCP数据包是否需要承担法律风险 15 8 SunAfterRain 2022-05-25 09:38
12 歡迎各位加入存廢覆核志願參與工作小組 10 8 Nishino Asuka 2022-05-24 23:55
13 管理員投票選民名單不符合程序方針 5 4 A2569875 2022-05-27 01:28
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

抛砖引玉一下编辑

 
简体
 
繁體

最近做了一个用于中文维基百科20周年的logo。虽然现在讨论这事还是太早,但既然做出来了就放一下。主要是在维基球上显示“廿載中維”四個字(毫无创意),最下面的设计是抄燃灯的(逃)

字体方面:“廿載中”用的是方正楷体(繁体,陆标)。宋体字是思源宋体(“中文”、“二十”用CN,“周年”用TW)改的(简体的“周”字还是怪怪的)。“自由的百科全书”,简体用思源黑体CN,繁体用源石黑体。

希望能有大佬能做出更好的作品(然后10月24日前能煮得出结果( ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 09:10 (UTC)

竟把其他三種字型從維基球上抹去並全以漢字取代,難道是存心不良?!--Iridium(IX) 2022年2月13日 (日) 10:01 (UTC)
? ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 11:12 (UTC)
是想說維基球本來就有其象徵意義,把其中幾個所代表的語言刪掉讓位給中文好像不太好--Iridium(IX) 2022年2月13日 (日) 11:35 (UTC)
就是说没必要这样解读吧( ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 13:18 (UTC)
也許吧,就當是個爛笑話聽聽就算
只不過是覺得這維基球設計的意念頗有意義,如果在搞特殊版本時也能夠保留那在我個人來說實在覺得更好--Iridium(IX) 2022年2月13日 (日) 14:34 (UTC)
感觉添加上的文字颜色与维基球原有文字颜色有差异啊。--    2022年2月13日 (日) 12:35 (UTC)
哦,确实,晚上回去改一下。(应该和图层顺序有关。) ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 12:38 (UTC)
@50829!:我改了,你看看?如果还不行我就不知道为什么了 ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 15:57 (UTC)
请注意字体的版权问题,不过思源是自由版权的。桐生ここ[讨论] 2022年2月13日 (日) 13:12 (UTC)
方正楷体“商业发布”可以免费使用。如果还有疑虑的话我就改成文鼎PL中楷。 ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 13:41 (UTC)
奇了,文鼎PL中楷的各个下载渠道都404了……(虽然去其它网站下下来了) ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 15:47 (UTC)
維基百科標誌與文字本身不必動,只要在下面加一行「中文維基百科二十週年」即可,建議用思源黑體。目前這樣混用視覺效果不太好。—— Eric Liu 創造は生命(留言留名學生會 2022年2月13日 (日) 17:29 (UTC)
試著自己做了一個版本( —— Eric Liu 創造は生命(留言留名學生會 2022年2月13日 (日) 18:23 (UTC)
要不然直接把燃灯的拿来改(钦定庆祝logo ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 13:11 (UTC)
就是參考了他的版本,只是用的現行的維基球。—— Eric Liu 創造は生命(留言留名學生會 2022年2月14日 (一) 15:00 (UTC)
我说的就是把那块透明拼图也加上去  ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 15:58 (UTC)
同样觉得维基球还是不要改为好,毕竟这是维基百科多语言的象征。--BlackShadowG留言) 2022年2月14日 (一) 15:16 (UTC)
又没有把多语言整个抹去。之前也没少做把其它语区遮住、拆掉的标志,还有的只留了一个W英维的20周年第一版标志的维基球也只有一个 。而且这本来就是中维的生日。 ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 16:11 (UTC)
好像这也是某巨大风波之后,才注重标志的版权问题,避免大改,或者干脆这个重新创作来避免吧。——Sakamotosan路过围观 | 避免做作,免敬 2022年2月15日 (二) 07:17 (UTC)
这啥事 ——魔琴 [ 留言 贡献 ] 2022年2月15日 (二) 09:44 (UTC)
数下标识的年份。——Sakamotosan路过围观 | 避免做作,免敬 2022年2月16日 (三) 00:56 (UTC)
如果是想要強調中維的那不如就完全只留下中文的那片,留一些其他語區卻又不留一些實在是兩頭不到岸,那些有拆的標誌也很久以前了呀。。--Iridium(IX) 2022年2月15日 (二) 07:21 (UTC)
Wikipedia:維基百科標誌,除非整个换掉(包括维基球),否则怕基金会律师函会寄出。 简便的话,直接换掉下面的标语或者题头则可?——Sakamotosan路过围观 | 避免做作,免敬 2022年2月15日 (二) 07:13 (UTC)
我就是這樣做的。話說,是要從10月24日懸掛至年底?—— Eric Liu 創造は生命(留言留名學生會 2022年2月15日 (二) 16:46 (UTC)
基金會應該不會寄送律師函,但是我可以問一下。--1233 T / C 2022年2月16日 (三) 16:10 (UTC)
本来就是给维基百科设计的标志,基金会为什么要寄律师函,我倒是觉得字体的版权如果和标志原图版权不兼容,字体厂商会寄律师函。桐生ここ[讨论] 2022年2月17日 (四) 08:53 (UTC)
字体在美国不受版权保护,寄律师函没用。--Lt2818留言) 2022年2月19日 (六) 07:14 (UTC)

我也弄了一個版本(見右方),其中“維”字來自File:維 GungSeo.svg,因此不處理繁簡,其他文字用的是源流明體,而且本來繁簡沒有區別。有需要的話我可以加寬一下margin。Sanmosa A-DWY3 2022年2月22日 (二) 06:54 (UTC)

@魔琴Ericliu1912Sanmosa A-DWY3 2022年2月22日 (二) 07:03 (UTC)
視覺上似乎不太協調?—— Eric Liu 創造は生命(留言留名學生會 2022年2月22日 (二) 07:37 (UTC)
這樣的話,我把“維”字縮小並放得比較右下角一點(提案2)會不會好些?--Sanmosa A-DWY3 2022年2月22日 (二) 07:55 (UTC)
20用汉字可乎? ——魔琴 [ 留言 贡献 ] 2022年2月22日 (二) 15:42 (UTC)
你等會,這樣的話我要多弄4個版本。--Sanmosa A-DWY3 2022年2月23日 (三) 00:36 (UTC)
@魔琴:我新弄了4個(6個)版本,你可以看看。Sanmosa A-DWY3 2022年2月23日 (三) 01:03 (UTC)
倾向3 6 ——魔琴 [ 留言 贡献 ] 2022年2月23日 (三) 02:38 (UTC)
“二十年”與“廿載”嗎?Sanmosa A-DWY3 2022年2月23日 (三) 07:49 (UTC)
可能這種設計本身就不怎麼好看orz —— Eric Liu 創造は生命(留言留名學生會 2022年2月23日 (三) 05:53 (UTC)
畢竟是我下載File:維 GungSeo.svg後用小畫家整出來的(之前討論2020年賀年標誌時我搞出來的“羅鼠”也是用小畫家與小畫家3D弄的),要避免File:2021 Chinese New Year Wikipedia logo from Cyril Yoshi (no ball test).jpeg這種翻車情況的話就只能極簡風處理(另一方面也是因為我自己傾向極簡風)。Sanmosa A-DWY3 2022年2月23日 (三) 07:53 (UTC)

我另外弄了一個新設計,也讓大家看看(繁體與簡體都做好了)【2022年2月23日 (三) 13:43 (UTC)更新:加造了一個拼圖中的“維”字也是簡體的版本】。字體的部分除了中文字用源流明體外,其他都是用Noto Serif,保證完全開源。Sanmosa A-DWY3 2022年2月23日 (三) 12:39 (UTC)

源石黑體貌似是開源字型?有在GitHub上看到相關頁面ButTaiwan/genseki-font。--🍫巧克力~✿ 2022年2月23日 (三) 13:21 (UTC)
@卡達源流明體本身其實也是開源的(不然我也不敢説“保證完全開源”)。Sanmosa A-DWY3 2022年2月23日 (三) 13:29 (UTC)
@魔琴Ericliu1912Sanmosa A-DWY3 2022年2月23日 (三) 13:29 (UTC)
更新:如果想要看效果的話,可以到Special:MyPage/common.js加入importScript('User:Sanmosa/Logo test Chinese Wikipedia 20th Anniversary Propsed Icon PNG.js');(繁體+簡體A)或importScript('User:Sanmosa/Logo test Chinese Wikipedia 20th Anniversary Propsed Icon Version 2 PNG.js');(繁體+簡體B)代碼。Sanmosa A-DWY3 2022年2月23日 (三) 14:02 (UTC)
方案7,“一干”?  囧rz……——Sakamotosan路过围观 | 避免做作,免敬 2022年2月24日 (四) 01:19 (UTC)
@Cwek:其實是「二十」,我嘗試再調整一下設計。Sanmosa A-DWY3 2022年2月24日 (四) 02:40 (UTC)
已調整7的設計,現在「二」和「十」應該分得比較開了。Sanmosa A-DWY3 2022年2月24日 (四) 02:56 (UTC)
在小分辨率下,“干”的间隙好像不够充分,创意还行,只是好像不太实用。——Sakamotosan路过围观 | 避免做作,免敬 2022年2月24日 (四) 03:22 (UTC)
或許我換個顔色會比較有效果。--Sanmosa A-DWY3 2022年2月24日 (四) 03:59 (UTC)
@Cwek:剛才換了顔色,現在應該不是「一干」了。--Sanmosa A-DWY3 2022年2月24日 (四) 04:13 (UTC)
3、4、6方案还行,5方案啰嗦,1方案“维”太大了。——Sakamotosan路过围观 | 避免做作,免敬 2022年2月24日 (四) 01:20 (UTC)
1已經是棄稿了,可以不用管。Sanmosa A-DWY3 2022年2月24日 (四) 02:41 (UTC)
更新了一個提案8,通過字母“Ω”形成數字“2”,並在兩旁加入拉丁字母“O”(我懶得找字母Omicron了),形成對稱的“20”字樣(已列於上方)。如果想要看效果的話,可以到Special:MyPage/common.js加入importScript('User:Sanmosa/Logo test Chinese Wikipedia 20th Anniversary Propsed Icon Omega PNG.js');(繁體+簡體A)或importScript('User:Sanmosa/Logo test Chinese Wikipedia 20th Anniversary Propsed Icon Omega Version 2 PNG.js');(繁體+簡體B)代碼。Sanmosa A-DWY3 2022年2月24日 (四) 10:41 (UTC)
(对这个方形拼图系列的整体意见)拉丁字母“ ”应该要stylize. 简体社群可能不会喜欢“文”字的那笔捺(不过现在还早先别急着改)。 ——魔琴 [ 留言 贡献 ] 2022年2月24日 (四) 11:07 (UTC)
File:WP20 EnWiki20 Logo BillionEdits.svg除了最底部的“WIKIPEDIA”中的“W”之外,所有“W”都沒有特別弄成雙V的設計,我覺得不要緊(另一方面是沒有任何Noto字形的字母“V”能造出“ ”的效果)。“文”字的話沒辦法,源流明體就是這個樣子,我不打算特別改動。Sanmosa A-DWY3 2022年2月25日 (五) 00:27 (UTC)
簡體的從人,不從入。--紺野夢人 肺炎退散 2022年2月25日 (五) 01:47 (UTC)
還是這句話:“源流明體就是這個樣子”,我已經特地確認過是否轉換成簡體了,仍然是同一個樣子。--Sanmosa A-DWY3 2022年2月26日 (六) 00:52 (UTC)
何不就用回現有圖標的字體,現在兩行字之間的間距覺得有點大。——玖宸 2022年3月6日 (日) 14:54 (UTC)
現有圖標的字體與源流明體同源。行距變大的原因是我在第二行的每個字之間加了全形空格,然後我調小了字體大小。--Sanmosa 2022年3月10日 (四) 14:03 (UTC)
再搜集幾個月,之後投票表決罷。—— Eric Liu 創造は生命(留言留名學生會 2022年2月24日 (四) 11:40 (UTC)
说一下自己的想法,用维基球当20的0,用有里程碑意义的条目名称当背景-- WPTO 2022年4月3日 (日) 01:33 (UTC)
 
简体
 
繁體
被赶回学校之前来发布一下“廿载中维”新版本:给四块拼图上了金色,这回不像是抹去其它语区了吧…… ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 15:59 (UTC)
路過,不得不提醒一下:中文直寫應該是「由上而下,由右而左」(同一行字由上寫到下,一行寫滿了於左邊開始新的一行),所以您這樣排列不是「中維廿載」,而是「廿載中維」。-游蛇脫殼/克勞 2022年4月5日 (二) 16:28 (UTC)
我觉得“中维廿载”和“廿载中维”都行啦,而且我一直说的都是“廿载中维”。当然如果可以选择的话“中维廿载”大概会更好些。 ——魔琴 [ 留言 贡献 ] 2022年4月6日 (三) 15:48 (UTC)
虽然路过,但我觉得提案7很不错。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月8日 (五) 09:19 (UTC)
在下个人觉得,提案7的基础上其他三个语言字母也应该凸显一下“20”之类的字样;在下刚刚阅读了一下维基百科标志的解读,觉得可以把剩下的三个语言改成朝鲜语谚文「 」、缅文字母「 」和藏文字母「 」。这也能体现汉语圈之类的概念。
不知道各位有什么看法,仅供参考。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月8日 (五) 10:05 (UTC)
下面是在下初步的构想;因为第一次设计,还没有来得及上色凸显“20”“二0”“二十”或者“二”。具体介绍可以直接进入共享资源的页面查看。
Special:MyPage/common.js加入importScript('User:A Chinese user/logo test 20th anniversary proposed icon.js');代码以体验。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月8日 (五) 11:21 (UTC)
更新:已经完成上色。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月8日 (五) 13:40 (UTC)
@A Chinese user:我個人覺得參照File:WP20 EnWiki20 Logo.svg還有一般拼圖的形狀設計成矩形比較好,另外就算是設計成圓形,我真的覺得你的提案看起來好像坤輿的那種羅盤節刪 2022年5月5日 (四) 15:06 (UTC)
在下再研究研究。--         2022年5月6日 (五) 01:56 (UTC)
我建议简体中文版维基球上的“廿”改为“廿”。毕竟简繁之间是有差异的。——范博 · · 2022年4月30日 (六) 12:53 (UTC)
“廿”改成“廿”?--         2022年4月30日 (六) 12:59 (UTC)
是的。——范博 · · 2022年5月1日 (日) 12:03 (UTC)
维基球上的“ ”字是繁体的,故“載”字亦用繁体。 ——魔琴 [ 留言 贡献 ] 2022年4月30日 (六) 13:09 (UTC)
我覺得現在各個提案的序號都已經有點混亂了,不如我開個頁面重編一下序號:Wikipedia:維基百科標誌/中文維基百科20周年標誌節刪 2022年5月6日 (五) 06:08 (UTC)
@Ericliu1912魔琴A Chinese user節刪 2022年5月6日 (五) 06:29 (UTC)
(+)支持@Sanmosa:在下深以为然。--         2022年5月6日 (五) 06:55 (UTC)
對了,我也把S-9A跟S-9B放出來吧,畢竟未必所有人都會點進去那個頁面看。節刪 2022年5月7日 (六) 08:06 (UTC)
(?)疑問:我想问一下,图标可以是一个GIF吗?用一个会动的图片来做特殊时间节点的图标多是一件美事啊。 ——范博 · · 2022年5月10日 (二) 11:17 (UTC)
不知道技術上是否可行,也不知道P站是否容許,但個人觀感是用GIF來當圖標在視覺上不太友好(主要是花里胡哨的問題)。Sanmosa Νεκρα 2022年5月17日 (二) 14:30 (UTC)
SVG动画(无端联想)--MilkyDefer 2022年5月20日 (五) 13:14 (UTC)

本章節暫時不存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

提議新增每月協作項目编辑

禁止摘编、链接等用途的被引用来源编辑

注意到中国经济周刊旗下“经济网”上的部分原创稿件注明有(版权属《中国经济周刊》杂志社所有,任何媒体、网站或个人未经授权不得转载、摘编、链接、转贴或以其他方式使用。)。此时该网页及稿件是否会不适宜作为维基百科的脚注,稿件中的采访、观点或资料又该如何对待(例如[1]),即便“用自己的话重写”,仍难避免对文章的“链接”或“其他方式使用”。该声明仅存在于部分稿件,集中于“周刊原创”“周刊精选”频道,文章作者是该周刊记者或特约撰稿人。

当前直接链接不多,52条。例子:[2]新浪网转载含有该声明。[3][4][5][6]有声明。[7]等仅要求“转载时须获得授权并注明来源”。部分文章无声明。[8]周刊精选但无特别声明,[9][10]周刊精选但有特别声明。是否有类似网站或先例。旧有类似讨论。--YFdyh000留言) 2022年4月23日 (六) 19:04 (UTC)

在下第一個想到的是:既然如此,閣下連這個問題都不該問,閣下現在已經對其鏈接了。-游蛇脫殼/克勞 2022年4月23日 (六) 23:24 (UTC)
  囧rz……似乎好有道理。但限制的主要是出版物吧,否则网站还应该用robots.txt禁止搜索引擎链接。--YFdyh000留言) 2022年4月24日 (日) 11:56 (UTC)
我不是真的認為您不該問這個問題,相反地,我認為這個網站的要求太離奇,令人不知所措。-游蛇脫殼/克勞 2022年4月24日 (日) 14:54 (UTC)
著作人的权利不应超出著作权法范畴。维基百科的链接形式属于这篇文章中的“普通链接”,只要所链接的作品本身不侵权,就没问题。--Lt2818留言) 2022年4月24日 (日) 06:44 (UTC)
单纯发一个链接也许是普通链接,但在文章(条目)中引用或将违反链接、摘编或其他方式。像是文章中的采访内容,有此声明、未经授权的情况下,其他媒体恐怕无权直接、指名道姓的引述。--YFdyh000留言) 2022年4月24日 (日) 12:03 (UTC)
合理使用是美国著作权法支持的权利,引述遵照Wikipedia:合理使用#文字即可;改述则更不受原材料著作权限制(著作權只保护思想的表達而不保護思想本身)。否认他人有这些权利的声明不受法律支持。--Lt2818留言) 2022年4月24日 (日) 12:49 (UTC)
禁止链接这点维基百科最好不要遵守,否则其它网站也可以使用这种方式使自己不出现在维基百科上。--BlackShadowG Pray for Ukraine 2022年4月26日 (二) 05:40 (UTC)
直接無視,哪來那麼多奇奇怪怪的要求。--中文維基百科20021024留言) 2022年4月27日 (三) 17:08 (UTC)
应该不止这一个网站,很多网站都有这样的文字表述,但是普通链接🔗应该没问题吧,否则的话他们网站上的新闻其他人如何分享。倒是Wayback Machine版感觉可能侵权,对原有内容做了全文复制。--Kethyga留言) 2022年4月30日 (六) 05:24 (UTC)
后来搜索来看,历史上的判例中有时限制链接明知侵权的内容,或者使用不能提供网站全貌的“深度链接”。网站时光机可以辩称完全自动化,且遵循robots.txt。对“禁止链接”条款的成因和如何在法律上解读,暂未找到更多资料。--YFdyh000留言) 2022年4月30日 (六) 15:37 (UTC)
前半句里,假如链接了明知是内容农场(很多是盗用内容)是不是就是一种侵权行为?--Kethyga留言) 2022年5月1日 (日) 15:13 (UTC)
这种直接用站内方针和避风港条款移除。除了严重侵权(名誉权或者盗版软件),链接一般侵权文章不产生后续反应。--YFdyh000留言) 2022年5月2日 (一) 04:08 (UTC)
看到每日经济新闻版权声明有一段应当在明显的位置注明作者姓名、作品原名称、作品来源,感觉{{cite web}}或{{cite news}},可以考虑对没有完整填写出处的参考来源标示一下。--Kethyga留言) 2022年5月12日 (四) 06:15 (UTC)
这个似乎无关,是“以下情形使用《每日经济新闻》系列媒体发布的内容”而非引用内容或观点,维基百科不符合那些情形。倒是第六条比较符合。--YFdyh000留言) 2022年5月12日 (四) 06:24 (UTC)
中工网发现了这么一段,“本网未标有"来源:中工网"或"中工网**电/讯"...稿件均为转载稿,本网转载出于传递更多信息之目的,并不意味着赞同其观点或认可其内容的真实性。如其他媒体、网站或个人从本网下载使用,必须保留本网注明的"稿件来源",并自负版权等法律责任。如擅自篡改为"稿件来源:中工网",本网将依法追究责任。”
新华网版权声明有类似语句,“ 凡本网注明“来源:XXX(非新华网)”的作品,均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。”。 可能需要编辑注明 报纸/网站/通讯社(原著)与Via。--Kethyga留言) 2022年5月20日 (五) 12:16 (UTC)

移除首页“你知道吗?”板块的“更多新条目”链接编辑

建议移除首页“你知道吗?”板块的“更多新条目”链接,该链接链接至Special:最新页面。该页面的条目没有经过筛选,ip建立的侵权条目、被提删的条目,甚至被打回草稿的条目([11])都会显示。这对读者的印象不太好。--BlackShadowG Pray for Ukraine 2022年4月26日 (二) 05:36 (UTC)

感觉更多新条目和侧边栏的随机页面链接能向读者展示更真实的中文维基百科。读者点进去后可能会发现条目每小时都在增加,这未尝不是一件好事。--50829! Talk · 496,466,022 2022年4月27日 (三) 00:00 (UTC)
  說明:所谓“你知道吗”指的是新条目推荐,“更多新条目”指的只是新条目而已,可能不满足推荐标准。--185.217.119.46留言) 2022年4月28日 (四) 05:07 (UTC)
暂时没看到很多太差的条目。坏条目会不会吸引到新编者来参与呢。如果很担心,技术上将默认的偏移后移如12或24小时?--YFdyh000留言) 2022年4月28日 (四) 20:08 (UTC)
我觉得可以。--Tranve () 2022年5月3日 (二) 03:12 (UTC)
虽然看着很合理,而且确实部分其他语言版本也没在首页弄这入口,但是对于多年来通过首页点进Special:最新页面的我来说还是一时不太能够接受……故整体持中立态度。--🔨留言) 2022年5月7日 (六) 12:18 (UTC)
如果是這個理由的話,(-)反对,讀者看到品質低劣的條目,不也能促使他們動手編輯並改善維基百科嗎?-KRF留言) 2022年5月17日 (二) 02:20 (UTC)
(!)意見:这个链接显然是不合适的,我认为应该链接至Wikipedia:新条目推荐/候选/自动筛选,这样比较好一些。--12З4567留言) 2022年5月17日 (二) 02:31 (UTC)
可是這是給讀者看的嗎?—— Eric Liu 創造は生命(留言留名學生會 2022年5月17日 (二) 10:31 (UTC)
难道Special:最新页面是给读者看的?那么“黄色背景的页面还没有被巡查”等三段文字是干什么用的?改成Wikipedia:新条目推荐/候选/自动筛选,这样读者既能阅读到质量比较好的新页面,又能了解新条目是如何经过筛选然后推荐到首页的,难道不好吗?--12З4567留言) 2022年5月17日 (二) 12:27 (UTC)
是有一點道理啦。—— Eric Liu 創造は生命(留言留名學生會 2022年5月19日 (四) 13:25 (UTC)
(+)贊成,浏览主页的用户一般都是普通用户,目前的链接确实不太好,链接到Wikipedia:新条目推荐/候选/自动筛选会更好一些。MoJieCPD留言) 2022年5月19日 (四) 05:50 (UTC)
這顯然有爭議(現在才有人會在意這個  囧rz……),看起來留哪個都不是的。原因是,如果照上面所述的話,那要不要以後也寫出FA/FL/FP/GA的自動篩選啊?還有,Special:最新页面也不等同說所有條目都能上DYK,那是不可能的。看來這有得討論是否該廢除了,畢竟首頁可能每天都不少人會看嘛。是吧?--Z7504非常建議必要時多關注評選留言) 2022年5月19日 (四) 13:31 (UTC)
(+)支持,以前就覺得很怪,適合給讀者看嗎?但想說應該是很多人習慣從首頁進Special:最新頁面(看樓上還真有,我也是後來用工具列才沒從首頁進)Wikipedia:新条目推荐/候选/自动筛选這個方案不錯!--Rice King 信箱 · 留名邊緣人🇹🇼 2022年5月24日 (二) 02:10 (UTC)

设置过滤器拦截在条目中插入简短描述的编辑编辑

负责展示简短描述{{Short description}}已由维基数据提供,不在本地设置,模板已经弃用,故建议在本地设置过滤器拦截使用该模板的编辑,提醒编辑在创建页面后到维基数据项添加,防止编辑翻译英文版条目时误加入该模板。--百战天虫留言) 2022年5月1日 (日) 16:59 (UTC)

过滤器说明文字建议:

您的编辑行为触发了本过滤器,这是因为您在条目中加入简短描述模板{{Short description}},而该模板一般只在英文维基百科使用。目前,维基百科的页面描述由维基数据统一提供,无需在本地添加,所以请在创建页面后添加跨语言链接,之后点击“编辑链接”进入对应的维基数据项,在最顶部添加描述。

--百战天虫留言) 2022年5月1日 (日) 17:07 (UTC)

大部分带过来的原因是翻译者自己也不清楚这段代码是干什么的,要求他们去wikidata编辑可能有些难度。->>Vocal&Guitar->>留言 2022年5月1日 (日) 23:44 (UTC)
过滤器就是要指导他们如何用维基数据项。--百战天虫留言) 2022年5月2日 (一) 02:22 (UTC)
如果使用代理,编辑维基数据需要全域IP封禁豁免权限,有时甚至需要取得维基数据本地IP封禁豁免权限。对于从未编辑过维基数据的用户来说,整个过程可能非常复杂,而且可能需要等待很长时间。--Yining Chen留言|签名页) 2022年5月4日 (三) 13:05 (UTC)
把模板删除后白纸保护如何?过滤器要消耗资源,尽量不用为好。--Lt2818留言) 2022年5月2日 (一) 01:44 (UTC)
留空即可,並開機器人定時清除引用。不過先把現在2000+引用想辦法清掉再說。--Xiplus#Talk 2022年5月2日 (一) 02:13 (UTC)
cf. 维基百科:机器人/作业请求#清理Template:Short description用法錯誤。—— Eric Liu 創造は生命(留言留名學生會 2022年5月2日 (一) 06:29 (UTC)
加了預覽警告作为暂时解决方案。--Lt2818留言) 2022年5月2日 (一) 02:59 (UTC)
User:YFdyh000相關討論中提及他傾向標記/分類、機器人清理,理由是「不然長文編輯遇到過濾器真的相當打擊貢獻積極性,有時根本找不到原因」,不知他是否接受這個過濾器提示?又目前的追蹤分類是Category:带有简短描述的條目,就我清理、觀察所見,大概只有不到一半的人會把Short description模板內容翻譯成中文,其他都保持英文。--迴廊彼端留言) 2022年5月2日 (一) 09:07 (UTC)
比过滤器好,但见下。--YFdyh000留言) 2022年5月2日 (一) 13:29 (UTC)
  1. 按我的理解,英文维基用这个是因为之前没有维基数据,所以用小工具实现短描述显示,并在后来被其他小工具和模板沿用。虽然整理条目源代码可能是译者的“责任”,但由于可视化编辑和非资深编辑不少,要求他们理解和清理该模板、尝试写维基数据,也许将浪费人力资源。
  2. 既然中文维基不显示该内容,那么只是一个多余代码,由机器人直接移除就可以,提供该翻译并非条目的必选项。类似情况如维基数据的各种属性,仅英维支持的模板、参数等等。
  3. 模板文档要求翻译内容并且“请注意维基数据的内容属于公有领域,如遇他人所写内容请行转叙。”是相当繁琐并难以遵循的,具体如何“转叙”,是指署名?相关界面似乎不能写编辑摘要。
  4. “(无描述)[编辑]”如果为“无描述”提供维基数据链接,就更好了,直接去那边对照填写简单明了。
  5. 所以,始终由机器人全数移除,并在编辑摘要中链接一个说明文档,介绍维基数据“描述”字段就好。比如,在该模板的说明文档中介绍并设锚点。--YFdyh000留言) 2022年5月2日 (一) 13:29 (UTC)
写好了一个将类似{{Short description|这是一段简短描述}}替换为<!--Short description|这是一段简短描述-->的程序。于Wikipedia:机器人/申请。另外,是否有可能将条目中的描述直接转移到维基数据中而不经过改写?--Yining Chen留言|签名页) 2022年5月8日 (日) 09:17 (UTC)
遗留下的有大量是未翻译原文,不能直接搬送。--。->>Vocal&Guitar->>留言 2022年5月8日 (日) 10:11 (UTC)

本章節暫時不存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

关于Template:Itn/special-header编辑

有鉴于现行Special-header上关于COVID-19的内容已经稍显陈旧且略欠关注度,做了一个俄乌战争的Draft:Itn/special-header,请斧正。--Lucien09留言战争永恒的战争…… 2022年5月2日 (一) 13:54 (UTC)

好像COVID-19特殊头也是参考en的做法,现在看了一下en,也是将COVID-19和俄乌战争并列(不过内容缩水了),所以只单列其中一个似乎不太好?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月3日 (二) 06:37 (UTC)
我倒是覺得可以比照英維,移到下面去並列,看起來也應該不會太醜。—— Eric Liu 創造は生命(留言留名學生會 2022年5月3日 (二) 10:04 (UTC)
直接縮水就好了,沒有關係。另外,也可以考慮比照COVID-19一樣確定結束再移除。--Z7504非常建議必要時多關注評選留言) 2022年5月4日 (三) 06:36 (UTC)
支持版本2。--Txkk留言) 2022年5月5日 (四) 13:58 (UTC)
先對此草稿之項目做了點調整。—— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 15:59 (UTC)
支持仿照英维,去掉子页面,只留两个主条目。--东风留言) 2022年5月6日 (五) 13:09 (UTC)
加了一个版本3;其中Draft:Itn/Ongoing应该与Portal:新聞動態/Sidebar的部分内容同步。--Lucien09留言战争永恒的战争…… 2022年5月8日 (日) 14:47 (UTC)
@EasterliesEricliu1912TxkkZ7504CwekKOKUYO--Lucien09留言战争永恒的战争…… 2022年5月11日 (三) 11:02 (UTC)
我支持版本三。--东风留言) 2022年5月11日 (三) 11:05 (UTC)
我依旧支持版本二。--Txkk留言) 2022年5月11日 (三) 11:17 (UTC)
版本三。—— Eric Liu 創造は生命(留言留名學生會 2022年5月12日 (四) 08:01 (UTC)
版本3。--YFdyh000留言) 2022年5月12日 (四) 09:31 (UTC)
(!)意見:建议把“正在发生”改成“长期事件”。--BlackShadowG Pray for Ukraine 2022年5月13日 (五) 08:26 (UTC)
“正在发生”里也有白俄罗斯-欧盟边界危机这样的“短期事件”吧……--Lucien09留言战争永恒的战争…… 2022年5月15日 (日) 02:13 (UTC)
我覺得可以這樣理解:從正在發生的事件裡面選出最重要的兩個放在首頁上,那就是疫情跟戰爭了。—— Eric Liu 創造は生命(留言留名學生會 2022年5月16日 (一) 02:53 (UTC)
补上支持版本三,毕竟首页没有必要放“背景·时间轴·反应·制裁·谈判”这么多链接,读者只要点进主条目,自然能看到这些分拆后条目的链接。--BlackShadowG Pray for Ukraine 2022年5月16日 (一) 06:01 (UTC)
(&)建議:如果其中一項結束,可改為只顯示另一項,顯示方式參考版本1/現行版本。--Cmsth11126a02留言) 2022年5月13日 (五) 12:43 (UTC)
支持版本二。如果硬要說長期議題的話,那麼像是「全球变暖」這種的,難道不能稱上長期議題嗎?--Z7504非常建議必要時多關注評選留言) 2022年5月13日 (五) 12:49 (UTC)
左边那个链接里其实是有全球暖化的。--Lucien09留言战争永恒的战争…… 2022年5月13日 (五) 15:03 (UTC)
長期議題這定義只能說就是模糊、模稜兩可的,因此為什麼會考慮版本二的原因就是這樣。另,確實如Cmsth11126a02所述,若其中一項真結束就能選擇用版本一(或現行版本)。--Z7504非常建議必要時多關注評選留言) 2022年5月14日 (六) 02:47 (UTC)
是的。--Lucien09留言战争永恒的战争…… 2022年5月15日 (日) 02:16 (UTC)
长期议题如何界定,可以参考英文维基百科的标准:

“正在进行”的部分链接到持续更新的维基百科条目,该条目本身也经常出现在新闻中。通常使用以下标准来发布“正在进行”的内容:

  • 任何条目都可以被提名为“正在进行”的链接。一般来说,这些事件可能缺乏值得列入新闻公告的新闻,但其条目仍有定期更新。
  • 一般来说,条目不会仅仅因为它们与仍在发生的事件有关而被张贴到“正在进行”中。张贴到“正在进行”中的文章需要定期更新相关的信息。如果条目的最新更新时间比目前ITN上最旧的新闻公告还要久远,那么其更新频率通常不足以使其被列入“正在进行”。
  • 被列为“正在进行”的条目不应因其新闻价值以外的原因而保留在头版。
(注:“新闻公告”指的是一般ITN正常的四条新闻)
因此,疫情的数据和影响会持续更新,战争的进展和伤亡会持续更新,但全球变暖一类的议题几乎不怎么需要更新,因此仅前两者适合列入ITN。--BlackShadowG Pray for Ukraine 2022年5月16日 (一) 06:18 (UTC)
读了一遍WP:7days,鉴于User:Z7504的意见“已获正当合理的回应,且自该回应起计的3日后无进一步再回应,应视为该意见已解决,且不再作为对该提案的正当合理的意见。”是否可以按方案三🕗 公示7日,2022年5月28日 (六) 12:03 (UTC) 結束?--Lucien09留言战争永恒的战争…… 2022年5月21日 (六) 12:03 (UTC)
另@Z7504:请问您是否同意BlackShadowG君的意见?(此回复同样不影响公示)。--Lucien09留言战争永恒的战争…… 2022年5月21日 (六) 12:06 (UTC)
@Lucien09:沒事,繼續公示就好了,上面也有提及到可以考慮「直接縮水就好了」。--Z7504非常建議必要時多關注評選留言) 2022年5月21日 (六) 13:53 (UTC)
我的意思是是否有必要将上方提到的英文维基百科的标准定为指引?--BlackShadowG Slava Ukraini! 2022年5月22日 (日) 12:03 (UTC)
這真的不知道,有關en的指引去問下別人吧。但是,若要增加內容的話,原本在模板中的這段「{{#if:{{{stat|}}}||<br/>累计确诊人数超过{{Cases in the COVID-19 pandemic|conround|ref=no}}人,其中逾{{Cases in the COVID-19 pandemic|droundt|ref=no}}人死亡}}」其實也能直接砍掉了,畢竟首頁也派不上用場;就算用到首頁也很麻煩,因為連鎖保護的緣故,會導致Cases in the COVID-19 pandemic模板無法再由一般用戶更新。--Z7504非常建議必要時多關注評選留言) 2022年5月22日 (日) 12:23 (UTC)
现在公示是按照版本三吧,版本三中已经没有Cases in the COVID-19 pandemic的这个模板了。--BlackShadowG Slava Ukraini! 2022年5月22日 (日) 12:47 (UTC)
如果是版本三那就真的沒事了,版本三就是「直接縮水」的版本。--Z7504非常建議必要時多關注評選留言) 2022年5月22日 (日) 13:25 (UTC)
是版本三。--Lucien09留言战争永恒的战争…… 2022年5月22日 (日) 23:09 (UTC)

重啟逐筆巡查標記的討論编辑

已通过:
后续请见phab工单T308976MilkyDefer 2022年5月22日 (日) 12:57 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

如題,之前有提過是否能對每一筆編輯進行逐筆巡查的標記,以避免巡查員重複巡查同一篇文章的問題,不過好像最後結論就不了了之,因此希望能重啟討論。

在前一篇討論中,有很多人擔心巡查人力的問題,這部分我回覆一下,就是因為現行巡查人力不足,所以我們更應該改善巡查的效率,讓每位巡查員一打開巡查頁面就能知道什麼編輯尚未審查,而不是像現在一樣每筆點開來看,如同大海撈針。至於擔心巡查員積壓工作的問題,我想這並不是一個很好的理由,逐筆巡查對反破壞工作來說非常重要,並不是說不打開這個工具就可以當作現在這個工作不存在。--Koala0090留言) 2022年5月8日 (日) 03:56 (UTC)

先是技术上是否支持,其次是用法和是否可靠。如权限下放程度,是否允许机器人/批量标记巡查,标记不当(应该有日志吧?)是否要追问质询、如何应对增加的“煮”。如果启用/禁用手续不复杂,试行也无妨。其实最近更改巡查也挺好,每个人对修订是否得当的标准不同;或者,逐笔巡查主要应对隐秘的鬼祟破坏?--YFdyh000留言) 2022年5月8日 (日) 04:20 (UTC)
之前@Xiplus:好像有說技術上有可能辦得到,不過機器人批量巡查這件事我不確定能不能。我是覺得可以試行兩周個幾次,如果沒問題就全面適用。--Koala0090留言) 2022年5月8日 (日) 05:05 (UTC)
主要是逐笔标记巡查有何意义?有不同于Wikipedia:稳定版本功能(好像由于技术原因,不会再追加功能新开站点)可以控制显示标记后的显示页面。新页面巡查好歹被视为具有权限性的职务,而最近更新巡查是人都可以巡查,是否标记的意义不大。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月9日 (一) 09:41 (UTC)
意义可能是减少重复检查,提升对冷门条目的检查率。--YFdyh000留言) 2022年5月9日 (一) 09:46 (UTC)
想到一个弊端,破坏者可能根据条目修订长期无人“巡查”而采取鬼祟破坏,不知道是否有应对之策,就像条目监视者太少时不具体显示。--YFdyh000留言) 2022年5月9日 (一) 09:48 (UTC)
@Cwek沒有標記的話,打開最近更改只能望洋興嘆,根本不知道從何檢查起。如果有標記的話,至少我一登入就知道我要檢查哪些編輯。--Koala0090留言) 2022年5月9日 (一) 09:54 (UTC)
最近更改的过滤器功能现在挺强的。可以用最近更改-“监视列表新更改”过滤器。--YFdyh000留言) 2022年5月9日 (一) 09:59 (UTC)
我目前是這樣做沒錯,但這一樣會有重工的問題--Koala0090留言) 2022年5月9日 (一) 10:13 (UTC)
最近更新和监视列表有个修订评分功能,会自动标记可能是坏质量的修订版本,可以试试打开。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月9日 (一) 10:32 (UTC)
我有開,但感覺不知道評斷依據是什麼?而且似乎大多數的破壞反而都不在標記中。另外會需要蹲點巡查就是因為有些蓄意破壞很難透過位元組或用戶加入時間去判斷。--Koala0090留言) 2022年5月9日 (一) 18:08 (UTC)
那也没办法,有些破坏行为是偶然看条目发现不对劲才去翻查页面历史的,不可能靠整天蹲着最近更新来“扫描”(好吧,虽然有工具是可以这么干的),要不然这是严重的中毒了。 ——Sakamotosan路过围观 | 避免做作,免敬 2022年5月9日 (一) 23:33 (UTC)
所以有什麼具體不能開放的缺點嗎,理論上巡查工具應該是越多越好,如果技術上可行,又沒有什麼缺點就開著,想用的人就用,不想用的人不用也沒關係吧。--Koala0090留言) 2022年5月11日 (三) 09:25 (UTC)
如果技术允许的话,建议将所有延伸确认用户的编辑自动标记为已巡查。否则打开最近更改看到一大片未标记的编辑,更没有动力去标记了。--Steven Sun留言) 2022年5月15日 (日) 01:59 (UTC)
看了之前的讨论,技术上似乎无法区分新页面巡查豁免和编辑巡查豁免。--Steven Sun留言) 2022年5月15日 (日) 02:11 (UTC)
可以开发机器人来自动标记。--YFdyh000留言) 2022年5月15日 (日) 04:00 (UTC)
@Xiplus:想請問技術上是否能達成?若能達成,是否還需經表決,還是直接當成小工具開啟即可。---Koala0090留言) 2022年5月15日 (日) 04:36 (UTC)
哪個部分?--Xiplus#Talk 2022年5月15日 (日) 04:42 (UTC)
@Xiplus 開啟逐筆巡查以及利用機器人標記巡查豁免者--Koala0090留言) 2022年5月15日 (日) 06:25 (UTC)
我覺得可以開啊,但我覺得沒必要用機器人自動巡查,最近更改本來就可以篩選30/500,跟90/500也差不多吧,用這個就行了。--Xiplus#Talk 2022年5月15日 (日) 06:30 (UTC)
@Xiplus感謝回覆,那如果要啟用的話需先經過表決,還是要經過什麼討論步驟嗎?--Koala0090留言) 2022年5月15日 (日) 09:18 (UTC)
公示數日即可--Xiplus#Talk 2022年5月15日 (日) 09:31 (UTC)
自即日起公示七日,若無其他反對意見,則開啟逐筆巡查功能。---Koala0090留言) 2022年5月15日 (日) 12:57 (UTC)
先試三個月看看好不好?直接一次通過我擔心沒能完全消掉社群的疑慮。--Ghren🐦🕙 2022年5月15日 (日) 14:31 (UTC)
不需要定死时间吧,有共识再关闭。开关都需要phab那边完成。--YFdyh000留言) 2022年5月15日 (日) 22:35 (UTC)
技术层面上,这个功能能够启用吗?(已经发生过多次搞不清楚状况,最后提交到phab那里被拒。。。)--百無一用是書生 () 2022年5月18日 (三) 02:39 (UTC)
@Xiplus屆時是否可以協助提交請求呢?--Koala0090留言) 2022年5月18日 (三) 03:19 (UTC)
好。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)
近百個wiki開啟此功能。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
感觉启用后实在没啥意义,全都是红色感叹号,而且修订历史里还没有这个标记,只有最近更改和监视列表里才有--百無一用是書生 () 2022年5月23日 (一) 14:56 (UTC)
目前看來回退和復原後並不會自動標記已巡查,若是如此,認為可能需要提醒所有巡查員要記得點選已巡查,不然還是要每筆點開來看。Koala0090--0906(回復請Ping我) 2022年5月23日 (一) 16:30 (UTC)
對我也發現這個問題了,有辦法將某些設定設定為自動巡查嗎,例如說回退之類的。--Koala0090留言) 2022年5月23日 (一) 16:32 (UTC)
另外就是因為我有開啟小工具,可以在不點開畫面的狀況下進行依些簡單的巡查。但因為最新更改清單中沒有巡查按鈕,還是要點進去才能巡查。不知道之後可不可以在後面加上一個巡查按鈕--Koala0090留言) 2022年5月23日 (一) 16:37 (UTC)
Xiplus如果使用TW不知道可否自動標記,還有管理員、机器人應該可以自動免巡查吧....--0906(回復請Ping我) 2022年5月23日 (一) 18:57 (UTC)
@ChhTJ096:全都是靠外部脚本运作的配套功能,为什么要靠脚本来清除?所以说,这个功能,为什么不从一开始就考虑解决后续的问题(一些用户或者大部分用户并不需要这些标记,或者说还需要考虑部分用户组的编辑可能不需要被这样标记)。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 02:21 (UTC)
很困惑的鸡肋功能,而且还要靠额外的手段来清理掉一些不必要的标识。只为其中一位编辑的识别能力弱而特此开启该功能,真的是……——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 01:45 (UTC)
祝某些编辑“消消乐”愉快。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 01:49 (UTC)
沒價值的引戰留言恕我不回覆了--Koala0090留言) 2022年5月24日 (二) 06:22 (UTC)

建议撤销该操作编辑

正如所见,这个标记功能很鸡肋,而且观感糟糕(最近更新和监视列表全是叹号),一系列解决方案(包括机器人自动标记、延伸确认用户自动标记)都没有跟上。所以没必要开启,如果特定编辑需要为每笔编辑标记以防止漏查,亲,我建议你自己写工具更好,毕竟是自己动手丰衣足食。@ShizhaoSteven SunYFdyh000:如果认为该功能作用不大,应该考虑撤销掉。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 02:13 (UTC)

暂时来看,具有“新页面巡查”、“巡查豁免”,或者说用户组具有标记巡查功能,的编辑是没有叹号的,也就是自动标记的。有可能这本身和“新页面巡查”的巡查机制是同一套的。Wikipedia:最近更改巡查也仅仅是提供一些外部追踪工具的志愿工作,而不是具有权限组的“职能”,为此开启这个功能有点用大炮打蚊子?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 02:37 (UTC)
另外,去了部分开启这个功能的wiki项目(波斯语fa,意大利语it,C区commons),fa和it的最近更新没看到有叹号,同时我没有当地类似巡查的职能性权限,可以认为没有“标记巡查”功能的用户是不会看到“叹号”的。commons的最近更新基本上没见到叹号,而且我有当地的“自动巡查”组,我就纳闷,然后再对了一下,一来分是大部分编辑都具有“巡查标记”功能的用户组,所以前述,会自动标记巡查;二来新页面巡查似乎也清得很勤快,没有对应用户组的用户的编辑很快被清理了;三来留意到一个bot账户User:BotLeo,会将新加入的“自动巡查”组的用户的旧编辑全部标记为已巡查。如果要达到不干扰的情况下,至少要做到commons区的情况才行。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 03:15 (UTC)
其實本來這個狀況就是有預期到的,首先開啟第一天,有許多巡查員尚不知有這個功能;第二就是這個工具缺乏自動標記功能。如果要解決的話應該是可以透過改善自動標記某些巡查功能,真的不能做到再關閉。每個新工具上線之初本來就會有問題,本來就需要一段時間的測試和調整。每個人的需求不同,如果因為你個人「不需要用到」這個因素而去阻止其他新工具的開發,那其實對於整個社群的進步是有危害的。例如說視覺化編輯上線初期,也是出現了很多反對的聲音,有些人說「原始碼用得好好的,為什麼要開發這麼難用的工具!」但對於許多不會原始碼的新手,這個工具還是相當重要的,如果還是用你那論調主張「只有少部分程式語言能力低落的用戶需要用到」,那就會阻礙很多人參與和工作。總之,言盡於此,若閣下後續有價值的留言我會適予回覆,單純來引戰和人身攻擊的就上ANM,這樣。--Koala0090留言) 2022年5月24日 (二) 06:37 (UTC)
“‘我’不需要用到”不等于“你需要用到就启用”,而且我也留意到一些用户也疑惑启用的必要性。而且“最近巡查”并不是“点击标记”,且不依赖于“点击标记”,你的想法是假设有最近巡查的人员会重复巡查,但问题当发现怀疑破坏后,不应该直接点击差异进去看一下有没之后的编辑(可能有其他用户已经发现而撤回,又或者不只是这一笔还有后续)?只要能做到这步,就不会出现重复巡查的问题(因为前述,如果没被处理就肯定这个“破坏”处理或者还有后续,这就更需要看页面历史),所以这个最近更改的标记就没有意义。而且没有CSS修饰的话,的确可以肯定已经对众多有巡查权限的用户造成困扰,而且我不认同靠CSS来掩耳盗铃来处理(甚至没有其他mw-core的功能配套下,依靠外部的行动来标记“可信”的编辑)。如果只是某些编辑为了防止自己的失误的话,应该自行解决,而不应该用大炮打蚊子的方法,还要搞出额外的操作来换更小的大炮打蚊子来避免。甚至最近巡查真靠逐个标记来排除破坏,而不是通过观察编辑行为来判断?———Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 09:49 (UTC)
所以你根本沒有搞清楚為什麼需要開啟這個工具,你說的重複巡查跟我說的重複巡查根本是不一樣的東西。你說的是重複反破壞,但至於重複審閱的問題根本沒有解決,開啟這個工具的目標並不是防止失誤,而是可以讓巡查員一眼看出哪些編輯還沒巡過,可以更有效率地去找。
第一天許多巡查員根本還沒進入狀況投入巡查,本來就預期會有這樣的情形,但我們卻必須花大把的時間跟你解釋這個是本來就會發生的狀況。--Koala0090留言) 2022年5月24日 (二) 11:00 (UTC)
反而你没搞清楚WP:新页面巡查Wikipedia:最近更改巡查的差异(一个是具有职权性的(有专属的用户组),另一个是只需要配合工具任何人都可以参与的志愿工作),而且“最近巡查”处理完破坏后还要手工点击“标记”多此一举的行为。所以我只能说你不过沉迷于“消消乐”的游戏,给有“巡查标记”功能的“新页面巡查”带来困惑罢了。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:02 (UTC)
别瞎代表,是“你”。根据行文来看,Shizhao似乎对此有不太赞同或疑惑的意思。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:14 (UTC)
“最近逐笔巡查标记”的问题是,对于没问题的编辑版本,依然依靠“标记”来消去提醒,在大部分编辑没问题的情况,这可能是困扰性的。不同于“新页面巡查”,“标记巡查 ”对于其他“新页面巡查人员”来避免重复新页面巡查来说,才是有必要性的。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:26 (UTC)
既然知道這是同源技術,那麼新頁面巡查就是巡查這個頁面的第1筆編輯,最近更改巡查就是巡查這個頁面的第2、3、4筆編輯,實際並無差異。就算已經有巡查員群組,所有人都還是可以參與新頁面巡查,而巡查權限本質上只是一個「告知其他人不需要再檢查一遍這個條目」的權力而已,同理,提案人只是需要「告知其他人不需要再檢查一遍這個編輯」的功能。--Xiplus#Talk 2022年5月25日 (三) 03:09 (UTC)
Wikipedia:新頁面巡查是职权性的(具有独立的用户组和功能),Wikipedia:最近更改巡查是带有志愿性和非职权性的,实际上“逐笔巡查”的功能是“新页面巡查”用户组及职权下所拥有的功能(或者说附带的,由于启用了逐笔巡查且技术同源),对于普通用户而言,逐笔编辑除了撤销破坏之外,就没有任何功能的操作的,而新页面巡查有着更多的操作(分析页面并且挂标示或者编辑改善),而且有着功能性的操作——将第一笔标记以便于清除提醒。所以对于“最近巡查”而言,有没这个功能(是否标记)无关重要,对于“新页面巡查”用户组而言,只是多了“最近巡查”的附带功能,而且对于想执行“最近巡查”的用户,“需要”这个功能还不如就是申请成为“新页面巡查”用户组人员。而且基于两次提案实际上看上去更像是Koala0090的一己之欲,支持者也不多(或者更多的是认为功能是否必要或者有不太可行的附加要求),所以看不出这样的功能开启共识有多强。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:26 (UTC)
或者说,对于大部分拥有“巡查标记”功能的“新页面巡查”人员来说,“逐笔标记”是否具有必要性;而对于想执行“最近更新巡查”的用户来说,“逐笔标记”是否具有必要性,另外如果为了这个“逐笔标记”的能力,是否其实应该考虑成为“新页面巡查”人员?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:30 (UTC)
「新頁面巡查有著更多的操作(分析頁面並且掛標示或者編輯改善)」難道一個文字內容在建立頁面時需要掛模板,但如果建立條目一段時間後再加入同樣的文字內容就不用掛模板嗎?--Xiplus#Talk 2022年5月25日 (三) 04:32 (UTC)
特定一笔编辑“挂修葺标示”和“标记巡查”在“Wikipedia:最近更改巡查”中有必要的关联?或者说,有必要每一笔编辑操作都需要人力确认有问题或者没问题,来消除这个巡查提醒?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:36 (UTC)
Re「有必要每一筆編輯操作都需要人力確認有問題或者沒問題」:沒有檢查到就算了,這同理於存在積壓的新頁面巡查,所以我們才需要「標記功能」來讓僅有的人力效益最大化,如果每個巡查員每天能巡查10個條目,那麼2個巡查員最多可以巡查20個條目,如果沒有將新條目標記為已巡查的功能,那麼這2位巡查員就可能檢查到重複的條目,導致總巡查量降低。同理如果有2位志願巡查最近更改的人,而分別每天能檢查100筆編輯,那總檢查量最高是200編輯,但如果沒有將編輯標記為已巡查的功能,那麼這2位檢查到重複的編輯,就會讓總檢查量降低。--Xiplus#Talk 2022年5月25日 (三) 04:44 (UTC)
我认为还是一个问题,没搞清楚WP:新页面巡查Wikipedia:最近更改巡查的意义,原则上新条目应该被标记巡查掉(现在就是人力原因或者其他原因,导致了经常超期,而且也不会影响条目的显示),“标记掉”就是“暗示”给其他“新页面巡查”人员这个条目已经巡查过。而执行“最近更改巡查”工作的用户,添加了修葺标识、撤销了一笔破坏,与“标记掉”有没必要的关联?没有,而且看是否存在后续编辑就知道是否被处理过。而且也提及过,由于技术同源,这个功能是对“新页面巡查”人员有影响也只对“新页面巡查”人员有意义,但对于“新页面巡查”人员来说,这个功能(连“逐笔编辑”都可以或者需要标记巡查)是否具有必要性?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:55 (UTC)
「而且看是否存在後續編輯就知道是否被處理過」為什麼我必須要點進去才知道有沒有被處理過,對於不需回退的正常編輯,也不可能有後續編輯。巡查新頁面同理,我如果點進去10個條目都發現已經被掛快速刪除模板,這是否表示巡查沒有積壓,並不是,這只是表示我巡查了其他人已經巡查過的條目。--Xiplus#Talk 2022年5月25日 (三) 05:02 (UTC)
簡單問:Special:最新页面裡面的「隱藏巡查過的編輯」意義是什麼?您巡查時會使用此功能嗎?為什麼要使用?--Xiplus#Talk 2022年5月25日 (三) 05:08 (UTC)
如果针对最近更新的编辑,如果发现有问题的编辑,点击差异进去,确认是有问题了,直接撤销掉,然后还要回去上一笔编辑,点击标记(对于具有“巡查标记”功能的用户,例如“新页面巡查”组的);或者然后可以什么都不用干(对于没有“巡查标记”功能但又想干“最近巡查”的用户)。而对于已经处理了的编辑(即使像过去一样,没有“逐笔标记”功能),没点击差异进去之前,最近更新已经提示有下一笔编辑了;点击差异进去,如果已经处理了,同样显示已经有下一笔版本;或者操作撤销时,提示有编辑冲突,因为类似的操作已经被另一位用户同样处理了。最终回到这里,“逐笔标记”似乎变得可以没有的存在,因为整个行为只对“新页面巡查”组有功能意义,但又不是必要的操作。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 05:29 (UTC)
「沒點擊差異進去之前,最近更新已經提示有下一筆編輯了」那如果沒有下一筆編輯,但這筆編輯實際上已經由別人檢查過的話呢?--Xiplus#Talk 2022年5月25日 (三) 06:29 (UTC)
如果是好编辑,那就别管它,关掉窗口或者忽略掉就是了。如果是坏编辑,请行动,或者已经有人行动了。“逐笔标记”并非必要。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 07:18 (UTC)
您一直沒有理解我的重點,我為什麼要重複檢查別人實際上已經檢查過的編輯?為什麼不能直接排除掉別人檢查過的編輯?--Xiplus#Talk 2022年5月25日 (三) 07:29 (UTC)
重申:點進去一筆編輯後才發現別人已經檢查過就算重複工作了,別人檢查過的編輯要直接隱藏!--Xiplus#Talk 2022年5月25日 (三) 07:30 (UTC)
那问题是这样做有意义吗?然后让一个对Wikipedia:最近更改巡查有兴趣的用户,特意去申请加入“Wikipedia:新頁面巡查”去获得“标记巡查”功能,然后就是为了给没有问题的编辑做标记,然后通过这样告诉其他“Wikipedia:新頁面巡查”人员“哦,这个编辑没问题,这个编辑也没有问题,这些编辑也没有问题”?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 09:18 (UTC)
有必要的話會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 09:30 (UTC)
Wikipedia:最近更改巡查没有用户组,而Wikipedia:新頁面巡查关联的用户组“巡查员”的核心权限就是“patrol”功能权限,也就是想做Wikipedia:最近更改巡查工作,现时肯定就要成为“新页面巡查”人员,才能拥有核心权限及对应的权利(启用逐笔巡查功能(非特设的话,默认关闭),则最近更新和监视列表能区分有没标记巡查的编辑,启用了新页面巡查功能(非特设的话,默认开启),则新页面能区分有没标记巡查的编辑,新文件巡查功能也是同新页面同理)。为了给每笔没问题的编辑标记没问题来提醒其他不一定相关的人员“没问题”,而特意去申请一个为新页面做巡查的职务或用户组,我觉得哪里不对。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 10:05 (UTC)
所以不會這麼做,會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 10:06 (UTC)
愿闻其详,希望不是为了别扭地配合,还要mw开发申请新功能。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 10:08 (UTC)
拆分權限比開發新功能簡單多了,mw開發新功能不行,開發外部工具就可以,是什麼道理?--Xiplus#Talk 2022年5月25日 (三) 10:21 (UTC)
为了使用一个从一开始开发完就被嫌弃的“新”功能,而去别扭地适配使用,还要靠外部工具去“修正”,还不如不用。因为你提到拆分权限,我无法确定你的想法,我猜想可能是将“patrol”功能拆成适配新页面、新文件、逐版本编辑的“patrol”,然后重新分配用户组?所以这意味着是不是还要找mw开发组进行功能适配?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月26日 (四) 02:26 (UTC)
開發新的外部工具就不會被你嫌棄嗎?--Xiplus#Talk 2022年5月27日 (五) 04:33 (UTC)
参考该功能开发初期的讨论,我认为好的编辑不需要特意标记(旧en讨论也有人提到,假设所有编辑都是可疑的来去标记不是好的wiki风格),坏的编辑直接操作处理则可;坏的编辑处理好后还需要额外的操作来标记之前被破坏的编辑(除了core-rollback似乎能直接标记,但留意到巡查日子似乎没记录);粗略看了commons的巡查日志,似乎也很少人会做“逐笔编辑标记”的操作,在旧en讨论中也提到这个问题。所以既然这个功能从一开发后就被遗弃,单独启用了的也似乎是鸡肋一样少用,我不认有启用的必要。而且这个功能更依赖于“新页面巡查”用户组的“patrol”权限,对于只做“最新巡查工作”但不属于这个用户组的用户来说,似乎并不合适。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月27日 (五) 05:59 (UTC)
如果只因为“观感糟糕”,在目前阶段,新增CSS/小工具默认禁用、以小工具自选启用,这样是否完美?没有巡查权限是看不到叹号的,例如我当前只有巡查豁免,看不到叹号。后续功能得功能开启才方便测试和有动力开发。其他观点不赞成。--YFdyh000留言) 2022年5月24日 (二) 07:55 (UTC)
CSS屏蔽,或者依靠外部行动来标记没有功能豁免的编辑,我认为不就是掩耳盗铃?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 09:53 (UTC)
CSS屏蔽,然后对有巡查权但认为不需要逐笔巡查的用户,不就跟以前一样吗?--YFdyh000留言) 2022年5月24日 (二) 10:03 (UTC)
话说,这是已经关掉了吗?现在我已经看不到红色感叹号了(除了新建页面)。另外,我认为其他wiki很少标记,可能更多的原因是具有“巡查标记”功能的用户组门槛很低,类似于自动确认用户那样。如果中文版这边没有类似机制,导致的后果就是一片红色的感叹号。另外,我对监视列表里的编辑,不会因为有感叹号标记而去特意查看并“标记为已巡查”,也不会因为没有感叹号或已经巡查而就不去看了。最后,这个功能到底我们社群有多大的需求?--百無一用是書生 () 2022年5月24日 (二) 12:35 (UTC)
没有关闭功能,只是在Mediawiki:Common.css用CSS屏蔽掉了。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:08 (UTC)
我认为可以降低逐笔巡查的门槛到扩展确认用户,以及前期默认不显示(如上文,通过小工具启用)。以及通过机器人标注可信用户,应比巡查豁免多并且进出更灵活。最好能提交批量标记历史编辑的请求。机器人编辑肯定要默认巡查。对于标记行权争议,也可再制定规则。--YFdyh000留言) 2022年5月24日 (二) 13:48 (UTC)
逐笔巡查和新页面查询是同源技术,也就是有“patrol”(标记别人编辑已巡查)权限就会看到功能按钮和进行操作,现阶段有的用户组应该有“新页面巡查员”和“管理员”。如果基于用户组的话,可能要给扩展确认用户添加“autopatrol”(自动标记自己编辑已巡查)权限,但Xiplus认为类似的机制不需要(?),而且前述,两者同源,如果给了“autopatrol”,连新建页面都会自动标记巡查,也就是等于有了“巡查豁免”用户组(该组有这个权限),可能会和“新页面巡查”的权责有冲突。或者申请开发mw-core功能作为绕过,但需要mw开发组的处理。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:08 (UTC)

其實以前在巡查最近更改的時候,就發現有重復巡查的問題,後來我發現HuggleSWViewer的功能非常的強大,如果說最後這個工具被撤销,Koala0090君可以試試這兩種程式。--0906(回復請Ping我) 2022年5月24日 (二) 14:01 (UTC)

我的意见就是这个意思,“最近更新巡查”因为定性于非职权性(没有用户组,而且逐笔标记似乎过于鸡肋,以至于很早(根据配置文件,似乎是en在2005年的讨论)被默认禁止了),只需要辅助工具就能解决,如果避免重复巡查的话,完全可以依靠这些工具来实现。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:10 (UTC)
請問哪個工具可以檢查一個小時前的編輯?Huggle或SWViewer可以嗎?這些工具都僅能檢查當下新出現的編輯吧。--Xiplus#Talk 2022年5月25日 (三) 03:12 (UTC)
这只是对这些外部工具对过往记录的回溯能力需求吧?有这个需求的话可以向相关工具开发提出(core-API没记错,最近更新列表似乎可以指定回溯的时间?)。如果这些工具长期启动的话,也可以回溯已经发生过的编辑?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:26 (UTC)
MediaWiki本身就有這樣的功能,不理解為何一定要開發新的。--Xiplus#Talk 2022年5月25日 (三) 04:46 (UTC)
你应该问Huggle或SWViewer的开发,这样外部的最近更新追踪工具有什么作用,就是为了给自己标记自己已经“复核”过的每笔编辑?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:58 (UTC)
我认为最近更改巡查对于small wiki或许有些意义,对于更新相当多的wiki完全没有实用价值--百無一用是書生 () 2022年5月25日 (三) 06:40 (UTC)
另外,实操上,我看到一个好的编辑我可能会标记巡查,但对于坏的编辑我可能直接回退而不会标记为巡查(因为操作太繁琐)。所以我感觉这个逻辑上有些怪--百無一用是書生 () 2022年5月25日 (三) 06:43 (UTC)
我认为为了提醒别人“好编辑,我巡查过了”或者“坏编辑,我确认过,并处理了”而特意在不断更新的最近更新里面启用这个功能,有点不值的,这在当时这个功能开发出来后就有人提出这个问题,后来开发者初步统计过,的确没多少人愿意做最近更新的巡查标记。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 10:15 (UTC)
如果有必要的话,可以参考当年实现了但又关闭掉这个功能的讨论:en:Wikipedia:Village_pump_(news)/Archive_A#Recent changes flagsen:Wikipedia_talk:Checked_edits_brainstorming。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 06:25 (UTC)
两天观察和处理后,对于“撤销”破坏编辑后的标记情况,我所观察到:如果使用系统功能rollback的话,是可以将被回退的编辑版本标记巡查(例如这笔:diff=71810208&oldid=71712640),不过在巡查日志没有找到该笔版本的巡查记录,不太确定这个是不是一个bug;如果使用盖板本的编辑式“回退”(例如:TW的回退、还有系统提供的撤销),则不会将被回退的编辑版本标记巡查(这笔:diff=71820246&oldid=71789098、diff=71822172&oldid=71822032)。可以将页面进行监视后然后在监视页面检查“叹号”。所以我认为shizhao的说法可能没说错:如果撤销掉一个破坏,可能不会有人得此返回去将“破坏”的编辑版本进行标记,尤其是用覆盖版本的编辑来“回退”。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月26日 (四) 02:18 (UTC)
开了功能就多试试吧,没有必要立即关闭,用CSS把感叹号的影响处理掉就好,逐笔巡查的按钮还是有点用的。桐生ここ[讨论] 2022年5月26日 (四) 07:55 (UTC)

又找到一個鏡像網站编辑

新建一个去除图片介绍末尾标点符号的机器人编辑

根据MOS:。,图片介绍文字的末尾不应该添加标点符号,但是有相当多的地方还是没有注意到这一问题,包括一些典范条目(如宋朝科技)和优良条目。因此,能否增加一个机器人,来自动处理该问题?实现起来应该也不难。--Shenzhiming88留言) 2022年5月13日 (五) 15:55 (UTC)

建议重新审视这条格式规范和共识。

  1. 首先,个人认为MOS:。中第二例在去掉末尾句号后反而更不美观和段落不清晰。
  2. 检查来看,该要求源自2013年由乌拉跨氪主笔并讨论和公示通过的格式指引,基于中华人民共和国《标点符号用法》(GB/T 15834—2011)[1]的附录A第一条,且不少机构的格式规范文件有参照此条做相同规定[2][3][4]
  3. 但其一,公示通过Gqqnb对该条提出了相反的格式意见,不过讨论以“标准”所定结束。没有找到其他讨论来强化该条指引的共识性。该标准为中国大陆的“GB/T”(国标/推荐),应该思考为什么这样做、是否这样做,而不是简单地“也要这样做”。
  4. 其二,也是比较重要的,仔细搜索看到了一些豁免解释和相反意见。
    1. 如果说明文字在图片或表格的正下方,则与一般文段句号的用法相同,在句末使用句号。[5]
    2. 针对科技论文图表中的注释句末是否用标点符号的问题,GB/T1.1—2009《标准化工作导则第1部分:标准的结构和编写》关于图题、表题和图注、表注的示例明确告诉我们:图题、表题的末尾不用任何点号;而图注、表注末尾要用句号。
      科技论文插图中除“注”“脚注”外,也有“说明文字”,三者通称图注。按照GB/T1.1—2009给出的示例,这类插图的“说明文字”末尾也要用句号。[6][7]
    3. 文章中有时会出现插图或表格等形式,其说明文字可能出现在上一段文字的末尾,也可能出现在图片或表格的正下方。如果出现在上一段文字的末尾,不管说明文字的长短,结尾都不用句号。如果说明文字在图片或表格的正下方,则与一般语段中的句号用法相同,结尾要用句号。[8][9]
    4. 如果出现在段尾,说明文字末尾通常不加句号。有时说明文字是一段话,前面已经使用了句号,在最后的结尾处仍不使用句号。
      如果说明文字在图片或表格的正下方,则与一般文段句号的用法相同,在句末使用句号。(如:行刑场景,上海,19世纪70年代。斩首为中国……。中国在1905年以枪决代替斩首。[10]
    5. (以上内容摘录仅用于学习、研究目的,版权归属原作者/书籍)。

关于“如果出现在段尾”,个人理解,可能指“正文-说明文字-表格/图片”的排版方式,这种情况下句号会分隔解释与“图或表”,从而不应。对于混排时悬浮(如右对齐)的图片下方的说明文字,除非不成句(如很短,中间没有任何逗号/句号/问号/惊叹号等),否则可能认为应加注句号以表示语句结束。 --YFdyh000留言) 2022年5月13日 (五) 18:39 (UTC)

非常感谢User:YFdyh000提醒了我们关于题注可能存在的争议。
2008年(比GB/T要早3年),en:Wikipedia:Manual_of_Style/Captions就已经被翻译成Wikipedia:格式手册/题注,但是只是作为参考,不是一个正式的指引。英文维基百科和一些语言的维基百科(如:ms:Wikipedia:Tajuk_imej)都是要求完整的句子,以句号结尾;也能发现另一些语言的维基百科对整句的是没有要求的,甚至多种形式会出现在同一篇条目中。
关于这些争议我们可以考虑以下方案:
1. 修改MOS:。使其与Wikipedia:格式手册/题注一致。这个方案的好处是可以与英文和一些其他语言的维基百科一致,在翻译条目时不必调整格式。
2. 修正Wikipedia:格式手册/题注,使其与MOS:。一致,避免指引和参考不一致的情况。这个方案的好处是和GB/T 15834—2011一致。
3. 如果现有共识已经不再被绝大多数编者接受,可以去掉MOS:。中关于完整的句子的指引。这个方案的好处是很可能会减少机器人编辑的次数,有利于减少碳排放。
另外,我们可以考虑将Wikipedia:格式手册/题注设置为指引。--zy26 was here. 2022年5月14日 (六) 03:50 (UTC)
我现在写英文比较多。我碰到的英文出版社关于图片题注是说,如果是一个完整句子,有主语谓语,则加句号。如果是短语,则不加句号。我自己做slides也是这样。
维基百科:格式手册/标点符号:“维基娘是维基百科萌拟人化后的美少女角色。由日本维基百科人创作”
这个例子有点儿怪。第一句是完整句子,第二句是残缺句(缺少主语)。我建议:题注第一句允许为短语。若题注多于一句,第一句用合适的标点符号结尾,后面的句子必须为完整的句子,用合适的标点符号结尾。
现在我倒是没有那么专注于《中华人民共和国标点符号使用规范》。我看楼主的参考资料大部分是中国的,可能中华民国台湾的用法是underrepresented。--Gqqnb留言) 2022年5月15日 (日) 07:50 (UTC)

原來這個圖片說明的句點規定放在那裡啊,我之前一直找不到XD —— Eric Liu 創造は生命(留言留名學生會 2022年5月14日 (六) 16:42 (UTC)

我自己的做法是,noun phrase (短句)不放句號,完整句子就放。供參。--Temp3600留言) 2022年5月20日 (五) 17:20 (UTC)

参考資料

  1. ^ https://people.ubuntu.com/~happyaron/l10n/GB(T)15834-2011.html
  2. ^ 咬文嚼字——图片下面的文字末不用句号
  3. ^ 中国科学技术大学 研究生学位论文撰写手册
  4. ^ 党政机关公文中标点符号使用应遵循国家标准 四平市审计局 任传宝
  5. ^ 【业务学习】标点符号用法解读之句号 - 《蚌埠工商学院》编辑部
  6. ^ 科技论文图表中的注释句末应用句号 《西部医学》 2016年第11期1488-1488
  7. ^ 郝远.科技文稿中的图注、表注末尾用句号吗?[J].编辑学报,2014(1).
  8. ^ 新国标标点符号使用手册 兰宾汉 2014-9-16 出版社:中华书局
  9. ^ 《标点符号用法手册》 兰宾汉 2015年1月 商务印书馆,内容应同上
  10. ^ 网友摘录,《标点符号用法》解读 2012-9 作者: 教育部语言文字信息管理司 出版社: 语文出版社

Module:Citation/CS1/Identifiers中提高s2cid上限编辑

注入特制的TCP数据包是否需要承担法律风险编辑

众所周知,翻墙违法。所以如题我提出一个疑问,如果不用VPN而是使用TCP是否也需要承担法律风险?比如Help:如何访问维基百科#注入特制的TCP数据包。--木子子羊翔留言) 2022年5月20日 (五) 06:40 (UTC)

众所周知,翻墙违法[來源請求]。众所周知,翻墙被抓也就报道或挖出来的那几个。VPN部分实现也就是TCP,所以不明白在说些什么。 ——Sakamotosan路过围观 | 避免做作,免敬 2022年5月20日 (五) 07:48 (UTC)
您能否再展开说一下,意思是否是说VPN是依靠TCP工作的吗?--木子子羊翔留言) 2022年5月20日 (五) 08:24 (UTC)
所以也是违法的对吧--木子子羊翔留言) 2022年5月20日 (五) 08:28 (UTC)
当你使用互联网接入服务时就已经违法了。 ——Sakamotosan路过围观 | 避免做作,免敬 2022年5月20日 (五) 08:36 (UTC)
墙会由于怪异TCP脱序而无法记录或发现访问基金会服务器的行为,但对于网络运营商而言并没有影响,还是会记录到访问目标地址,只是有没心思从大量的数据日志挖掘这些记录。其次只有特定的域名是有SNI RST而可以用怪异TCP数据包来绕过,其他域名并没有受到影响,如果没做好区分的话,这些没影响的域名还是可以正常访问,提供正常的地址数据。另外,如上述,使用是灰色行为(因为至少从已知被抓的和估算的使用者量有很大的差距),唯一肯定的,做未经许可的销售绝对会被抓的。 ——Sakamotosan路过围观 | 避免做作,免敬 2022年5月20日 (五) 08:36 (UTC)
那我还是使用镜像网站为好,免得犯这些事,年纪轻轻我可不想有污点。--木子子羊翔留言) 2022年5月20日 (五) 08:52 (UTC)
访问镜像站照样有域名记录,并要小心镜像站本身是否可靠。严格执法参考恶俗维基浏览案件。--YFdyh000留言) 2022年5月20日 (五) 09:35 (UTC)
呃。数据包是可以直连的的,GFW应该查不出,但是运营商可能可以翻出来。此外镜像站千万不要登陆那种标着不可编辑但保留登陆入口的,很容易被偷密码然后做出一些不可思议的事(比如在词条里插入黄图那种)--Neonlight185-欢迎参与赣语维基百科留言) 2022年5月21日 (六) 02:42 (UTC)
您上网的那一刻起就已经在用TCP了。--Shinohara Chihiro留言) 2022年5月20日 (五) 09:26 (UTC)
根据破坏计算机信息系统罪

第286条 违反国家规定,对计算机信息系统功能进行删除、修改、增加、干扰,造成计算机信息系统不能正常运行,后果严重的,处5年以下有期徒刑或者拘役;后果特别严重的,处5年以上有期徒刑。

Help:如何访问维基百科#注入特制的TCP数据包中的方法,违反了《网络数据安全管理条例》,对GFW功能进行干扰,造成GFW不能正常进行干扰,除了后果严重之外完全适用本条。--GUT412454留言) 2022年5月21日 (六) 05:39 (UTC)
沒有干擾,只是你解析不出來而已干我們甚麼事--SunAfterRain 2022年5月25日 (三) 01:38 (UTC)

根本不用想那么复杂,无论你是使用哪一种方式访问维基百科(包括使用境外SIM卡漫游等等),都是需要承担法律风险的。不管有没有明确的立法,法律的解释权……--🔨留言) 2022年5月22日 (日) 13:54 (UTC)

(~)補充:所以这个讨论串标题是我的话就是问“注入特制的TCP数据包是否会留下记录并被追踪到?”--🔨留言) 2022年5月23日 (一) 02:05 (UTC)

歡迎各位加入存廢覆核志願參與工作小組编辑

在下建立小組的目的是打算讓更多人來積極參與存廢覆核,並修改造成管理員不願意處理存廢覆核的方針指引,歡迎各位加入--飛馬🎠🎈 2022年5月22日 (日) 12:32 (UTC)

没有看到建立一个“协会”的任何必要性。这种东西越建越多,问题压根没解决。--三万光年 GBAW · 6000+ 2022年5月22日 (日) 16:46 (UTC)
“协会”怪怪的,“存废复核志愿者小组”可能较好,且较复杂的组织结构现阶段不重要。建议建立一些指引草案和状态模板、适当请求或提供原始内容参考链接,使每笔复核得到至少一笔意见或讨论方向,以免处置的管理员要独自决定最终意见。--YFdyh000留言) 2022年5月22日 (日) 16:58 (UTC)
感謝您的建議--飛馬🎠🎈 2022年5月22日 (日) 23:27 (UTC)
一個新成員也沒有但已經這麼官僚化,又搞一個學生會?--某人 2022年5月22日 (日) 17:05 (UTC)
路过,页面已经没了,如想重新创建,我也想提醒注意避免官僚化。--BlackShadowG Slava Ukraini! 2022年5月24日 (二) 01:04 (UTC)
已改為建立工作小組,也避免官僚化了--飛馬🎠🎈 2022年5月24日 (二) 01:59 (UTC)
直接去參與存廢覆核請求都好一些。—— Eric Liu 創造は生命(留言留名學生會 2022年5月24日 (二) 04:43 (UTC)
不是,到底建這個的意義在哪裡,一個沒實質意義的工作小組...--SunAfterRain 2022年5月24日 (二) 08:24 (UTC)
第一:建立這個小組的人前幾天才剛剛達到自確,有DRV的經驗嗎?答案顯然是沒有,太不自量力了;第二:建立各類呼籲積極參與站務工作的小組,以及設立各類站務員能解決站務擠壓的本質問題嗎?--紹💓煦意見箱 2022年5月24日 (二) 15:55 (UTC)

管理員投票選民名單不符合程序方針编辑

Wikipedia_talk:申请成为管理员/和平奮鬥救地球/第5次/List#投票權人名單,「基準時間」有問題。原來中文維基百科投票那麼兒戲的嗎?--陳白腸留言) 2022年5月26日 (四) 13:20 (UTC)

我早先已經做了解釋,不認為相關規定有嚴重扞格問題。如果有問題,建議直接忽略相關規則。另外Xiplus的解釋亦無不可。—— Eric Liu 創造は生命(留言留名學生會 2022年5月26日 (四) 14:47 (UTC)
恕我吐槽,你要求的基準時間在技術上是辦不到的--SunAfterRain 2022年5月26日 (四) 15:25 (UTC)
連署通過當下不可能「通靈」地「預知」正式選舉日期;連署通過當下就應該計算投票人有哪些;依你的要求,計算人員每天都要重算就飽了。強人所難!惡意!兒你他X戲啦。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年5月26日 (四) 17:28 (UTC)