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

维基百科，自由的百科全书
跳到导航 跳到搜索

互助客棧：消息（发表） · 方针（发表） · 技术（发表） · 求助（发表） · 条目探讨（发表） · 其他 ｜ 知识问答
快捷方式
Breezeicons-apps-48-braindump.svg

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

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

請注重禮儀及遵守方針與指引，一般問題請至互助客栈/其他或知识问答提出，留言后请务必签名（点击 Signature icon april 2018.png ）。


發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

7月6日之后没有新回應的议题會移动至相应的讨论页或存档。跳至本頁的：目錄 · 底端

公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 如何成立“支持反送中放置滚动新闻大陆维基人群”？ 21 18 66.241.128.130 2019-07-16 20:32
2 請問要如何在用戶頁中引入CSS樣式表？ 14 4 A2569875 2019-07-07 14:10
3 DYKC的type參數 47 7 Cdip150 2019-07-11 15:47
4 关于“不留重定向移动” 6 5 Sanmosa 2019-07-11 14:28
5 KOKUYO的地域中心“修正”行为是否正当？ITN改进方案？ 15 9 AT 2019-07-16 23:35
6 請管理員AT就使用者MeritTim濫用傀儡SmallTim一事做出解釋 17 8 Sunny00217 2019-07-10 06:51
7 如何翻譯「カイ」 0 0
8 玉皇大帝編輯 0 0
9 （单纯讨论方针）CIV的管理范围 12 7 Ericliu1912 2019-07-13 02:21
10 蘋果日報 4 4 Brror 2019-07-16 07:43
11 Special:用户贡献/Des Cascade 15 6 Masdggg 2019-07-14 02:46
12 有關DYK因票數不足而落選問題 19 8 UjuiUjuMandan 2019-07-16 10:00
13 我對近期行為的聲明和澄清（嚴肅版，絕不開任何玩笑。比較長篇大論，希望大家能耐心看完） 1 1 SickManWP 2019-07-13 01:58
14 永远再见 5 5 221.192.180.181 2019-07-16 09:21
15 回退破壞 6 5 Wong128hk 2019-07-14 12:08
16 關於新竹社群、新竹聚會之頁面，如何解決「新竹」一詞模稜兩可及地域中心之問題？ 9 5 Kai3952 2019-07-16 18:39
17 用户兼管理员的与管理员权限无关的个人編輯。十二余年后依然缺乏提供原文来源。如何适当处理？ 6 4 AT 2019-07-16 21:28
18 请求更改内容模型 1 1 DW YoungDLS 2019-07-16 23:37
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤


如何成立“支持反送中放置滚动新闻大陆维基人群”？[编辑]

我是大陆维基人，我支持香港人民反送中，我支持反送中放置香港区域维基百科滚动新闻。我不想被Lifeingenso，Rowingbohe，痛心疾首，Unravel17，YFdyh000等大陆维基人代表。每次我用VPN翻墙香港看到维基百科滚动新闻显示反送中我都感到十分振奋。请问如何成立“支持反送中放置滚动新闻大陆维基人群”，让我们这些支持香港人民在风雨中抱紧自由的大陆维基人能发出我们自己的声音，而不是被代表？174.138.212.84（留言） 2019年6月15日 (六) 18:36 (UTC)

我觉得大陆更应该成立“反《个人信息出境安全评估办法》”群。不如先从起个叫得响的名字开始？--140.180.246.189（留言） 2019年6月15日 (六) 19:04 (UTC)
建议参考Wikipedia的创始原则第一条，对中立性的说明。~ viztor ✪ 2019年6月15日 (六) 23:49 (UTC)
編輯條目而已。--1233 （T / C） 2019年6月20日 (四) 05:22 (UTC)
您好，视乎您所用的即时通讯软件类型，您可以使用多种方法创建该群聊：
  1. 如果您用的是QQ软件，您可以登录QQ客户端->进入群聊界面->点击“创建”，选择“创建群”->选择群类型->填写群名为“支持反送中放置滚动新闻大陆维基人群”->点击“下一步”->在您的好友列表中邀请好友进入成为群成员->点击“完成创建”，就可以创建一个这样的群聊。
  2. 如果您用的是telegram软件，您可以打开菜单栏，选择“新建群组”，填写群名为“支持反送中放置滚动新闻大陆维基人群”，点击“完成”，在您的通讯录中邀请他人进入成为群成员，就可以创建一个这样的群聊。
  3. 如果您用的是discord、irc或其他软件，您也可以通过谷歌等搜索引擎搜索这些软件的用法，或者致电客服询问。
{#(set-global-staff-size 10) a' b' b' a' a' g' g' c' g' a'2 r4 \bar "|."}
 2019年6月16日 (日) 06:16 (UTC)
感谢指导🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍🙇‍174.138.212.84（留言） 2019年6月16日 (日) 20:27 (UTC)
以上内容应移动到WP:知识问答。--进入低产期的Rowingbohe♬Taizhou/Sign 2019年6月16日 (日) 06:43 (UTC)
他们并没有代表你。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年6月16日 (日) 13:20 (UTC)
公告栏不是宣告板；宣导一部分人的意见，可视之拉票。站外讨论及共识值得质疑。--YFdyh000（留言） 2019年6月16日 (日) 22:13 (UTC)
咱不知道你书的是啥。--知唐桑艾 2019年6月17日 (一) 14:50 (UTC)
如何成立？不能成立。（Guarten？Guarten。）Σανμοσα 2019年6月18日 (二) 14:18 (UTC)
  • 建群可以，你们自己群聊就成，不过别放置滚动新闻，要不然实在有违中立性原则，支持或反对逃犯法案都不是维基媒体的立场。--侧耳倾听 2019年6月26日 (三) 06:49 (UTC)
  • 顺便提一下，《个人信息出境安全评估办法》只是规定不能让个人隐私信息出境，没有规定公民不能访问外国网站。但是C国工人党最近几十年以来打着社会主义旗号搞威权主义实是**。宪法规定的公民自由在实践上十分受限。“无产阶级专政”也不见得领导人都是无产阶级。怀念赵紫阳时代。--Inzhrui（留言） 2019年6月29日 (六) 14:59 (UTC)
  • (＊)提醒用手成立。--Kitabc12345（留言） 2019年7月2日 (二) 13:35 (UTC)
  • (！)意見：这个话题跟维基百科无关，建议关闭、不存档。极少数反送中的代表不了大陆人，别给大陆人丢脸。--風雲北洋※Talk 支持香港特区政府修订《逃犯条例》 2019年7月12日 (五) 02:53 (UTC)
    • 既然是「維基人群組」相關事項，那跟站內似不是全無關係。—— Eric Liu（留言．留名．學生會） 2019年7月12日 (五) 15:48 (UTC)
    • 嘿，你怎么知道“极少数反送中的代表不了大陆人”？！我就是大陆人，我就支持反送中，你少来代表我！另外你才别给大陆人丢脸，搞得我们大陆人好像都是共产党帮凶似的！69.158.246.127（留言） 2019年7月14日 (日) 21:53 (UTC)
    • 註：此處原有文字，因為人身攻击，已由風雲北洋※Talk 🐔🏀於2019年7月16日 (二) 06:23 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。
      • (＊)提醒：雙方請注意言辭和盡量理性討論，以免觸犯WP:CIV。 SCP-2000（留言） 2019年7月15日 (一) 12:35 (UTC)
        • 那几个IP政治狂，来维基百科什么都没编辑，就只会煮一些政治的东西。--風雲北洋※Talk 🐔🏀 2019年7月16日 (二) 06:10 (UTC)
          • 那是谁先拿滚动新闻说事儿的？人家香港人在港版维基百科港段IP地址设置滚动新闻碍着你们什么事了？如果你们不先搞这些政治的东西，我会开这一个话题么？66.241.128.130（留言） 2019年7月16日 (二) 12:32 (UTC)

請問要如何在用戶頁中引入CSS樣式表？[编辑]

又來打擾各位了。請問要如何在用戶頁中引入CSS樣式表？在下指的是引入另外寫的CSS樣式表，只有引入才有效果，而不是寫在Special:Mypage/common.css中只有帳戶擁有者才看得到的、應用在全站的樣式表。

祝 編安。

－台北人留言 2019年6月22日 (六) 13:40 (UTC)

做一个类似模板的被包含页，利用WP:模板样式引入到你的用户页。——路过围观的Sakamotosan | 避免做作，免敬 2019年6月23日 (日) 01:00 (UTC)
Face-smile.svg謝謝您！－台北人留言 2019年6月23日 (日) 07:02 (UTC)
你先建立一個位於U:台北人子頁面的新CSS頁，例如建立U:台北人/XXX.css的新頁面（不要跟個人使用者設定Special:Mypage/common.css混淆）好了後通知一下，請管理員將該頁的頁面內容模型改為「contentmodel:sanitized-css」後，就能夠過Help:模板样式來使用權站都能看到的CSS樣式表。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月23日 (日) 07:07 (UTC)
(＊)提醒@A2569875：全站-- Sunny00217 - 2019年6月29日 (六) 01:36 (UTC)
(：)回應.....好哦。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月7日 (日) 06:10 (UTC)
了解，謝謝閣下！－台北人留言 2019年6月23日 (日) 07:11 (UTC)
建好專門用於用戶頁的CSS了嗎？（盡量不要直接用Special:Mypage/common.css，可以開一個新的，因為要用特殊的檔案格式），例如U:台北人/style.css，好了的話我可以幫您通知管理員轉成適當的檔案格式。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月23日 (日) 07:15 (UTC)
(？)疑問是用戶頁中要引入U:台北人/style.cssCSS樣式表嗎? 如果您同意我就請管理員幫您轉檔了。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月23日 (日) 07:18 (UTC)
是，謝謝您！－台北人留言 2019年6月23日 (日) 07:21 (UTC)
(：)回應Special:Diff/54931820已由User:Stang完成轉檔，請複查，感謝。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月23日 (日) 07:27 (UTC)
Face-smile.svg謝謝您！－台北人留言 2019年6月23日 (日) 07:38 (UTC)
  • (：)回應接著你只要在頁面任一地方加入<templatestyles src="User:台北人/style.css" />即可使用如<span class="topic">的內容了，很高興能幫到您。祝編安。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月23日 (日) 07:45 (UTC)
    • 也祝閣下有美好的一天。－台北人留言 2019年6月23日 (日) 07:46 (UTC)

DYKC的type參數[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新条目推荐/候选、Template talk:DYKEntry。

原标题为：提議廢除DYKC的type參數

如題。Σανμοσα 2019年6月24日 (一) 09:36 (UTC)

理由？另外，上面我說「不再倚賴type」的方法衹是在研究階段，連可行性都還不確定，現在提廢除根本言之尚早。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月24日 (一) 09:53 (UTC)
同上。另外我還能夠想出一個反例，不過八字沒有一撇，先不提了。--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年6月24日 (一) 10:49 (UTC)
  • 不支持。无论如何把判断条目类别的逻辑全部硬编码到程序里不是好事情。设置参数的目的是为了合理控制上首页的条目的多样性。但是什么叫做“合理“并不是一成不变的。想象一下，如果某种类型X的条目平时不多见，但是偶尔由于活动突然涌现了一批X类型条目，那么临时限制一下X的流量是合理的；但是如果维基上突然出现一批X爱好者，每天贡献一半的DYKC提名，那么我们别无选择，只能将X细分。与其纠结“type参数该不该有这种问题”，还不如维护一个列表，告诉新手老手“type参数应该怎么填”。为了解决这个问题，只需要写一个单独的模块就够了，这个模块可以被DYKC提名页面的提示模板使用，以提示编者参数该填什么；也可以被DYKC提名模板使用，如果type参数不填或不合规范，则自动报错，不给显示内容；还可以产生信息供bot初始化，每次更新DYK前动态加载一次。同时如果DYKC的提名情况发生了变化也可以及时调整模块内容，而不必依赖bot操作者。--Antigng（留言） 2019年6月24日 (一) 19:55 (UTC)
  • 对于DYKC说明页和提名模板，这个模块的逻辑是很简单的，只需要告诉它们哪些参数能用就是了。但是对于bot来说情况就有点复杂了。想象一下当参数调整以后，bot并不知道当前DYK模板上的条目的类型在新参数下会被描述成什么，就可能出问题。一个解决方案是，将模块中的合法type参数实现为树，从根节点出发，逐步向下分类，每个节点包含一个或多个参数(别)名，并对每个参数名明确标识可以引用与不可以引用。这样:
  1. 合并多个参数时，只需要将新的合并以后的参数设置为老参数所在节点的父节点，再将老参数标记为不可引用；
  2. 拆分一个参数时，只需要为老参数所在节点设置子节点，并将所有老参数标记为不可引用；
  3. 新增一个参数别名，只需要增加一个别名即可；
  4. 删除一个别名，只需将别名标记为不可引用。
  • 于是bot只需要检查别名对应的节点到根节点的路径是否重合即可判断两个提名的条目参数是否重复。--Antigng（留言） 2019年6月24日 (一) 20:16 (UTC)
  • 然后可以再考虑复杂一点的情况，如果bot崩溃了，怎么知道当前DYK模板上的条目属于什么类型。一种解决方法是，强制DYKEntry模板加type参数，合法参数的列表仍然从模块取得。--Antigng（留言） 2019年6月24日 (一) 22:05 (UTC)
我先說明一下為何我提議廢除DYKC的type參數：
  1. type參數的規範化沒有共識，使使用type參數維持多樣性的可行性降低（@Antigng：之前有过类近「维护一个列表，告诉新手老手『type参数应该怎么填』」的討論，但無疾而終，你可以問一問Cdip150為甚麼）；
  2. 使用type參數維持多樣性未成為明文規定（@Antigng：之前也有过设使用type參數維持多樣性為明文規定的讨论，但也是無疾而終，你可以問一問Cdip150為甚麼）；
  3. 1導致胡亂填寫type參數的問題也沒有對應規範，使使用type參數維持多樣性的可行性再進一步降低；
綜上，type參數只對bot有用，卻對人無用，甚至為人帶來「type參數應該填甚麼」的困擾，所以我認為在1和2的前提下，type參數應該廢除。Σανμοσα 2019年6月25日 (二) 00:22 (UTC)
如果真的要保留type參數的話，type參數的規範化和將使用type參數維持多樣性定為明文規定缺一不可。Σανμοσα 2019年6月25日 (二) 00:25 (UTC)
  • 问题1、2、3一次性解决的方案就是利用技术手段限制错填的可能性。如果填错，就不给你显示任何东西，连问题都不显示，或者更极端一点，显示加粗加红的报错文字，我看谁还会填错。一个很明显的例子是，站内没闭合的noinclude模板比includeonly模板多多了，为啥？includeonly不闭合下边的内容全显示不出来，难看得要死，noinclude模板不闭连个警告都没。人是靠不住的，能用技术手段限制死的东西就要用技术手段限制住。于此同时，加大提报DYKC小工具的宣传力度，逐步引导新手老手采用半自动工具提报，既方便又安全。--Antigng（留言） 2019年6月25日 (二) 00:29 (UTC)
    • User:Antigng但之前的討論中有人明確反對用這樣的手段（以至任何手段）限制，所以最終未能夠實行。我真的不是不想做，而是沒有共識基礎讓我做，所以現在我們要做的就是取得這方面的共識。Σανμοσα 2019年6月25日 (二) 00:32 (UTC)
      • 不想做无非是不方便呗。半自动工具做好了，难道不比手动提报方便？想想现在还有几个用户手动提CSD，AFD的。--Antigng（留言） 2019年6月25日 (二) 00:34 (UTC)
  • 要知道當初沒機械人的年代是由管理員親自決定哪2個條目不適宜同時上架，嚴格來說，分類的責任應該是管理員而不是編者，後來設立的type，當初也衹是給管理員在非常必要的時候才用，而不是給編者的要求（又或者說type的使用性質其實和hash和result那些一樣，是管理用途）。僅僅為了管理上的方便，要求編者連管理員負責做的事情也要做，就算您有一個表給編者選，其實也是變相把這種責任轉嫁編者，本身我就已經不見得合理，所以「強制DYKEntry模板加type參數」是我極反對的事情，因為這是在把責任推卸。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 01:50 (UTC)
    • 在古早的年代没规则，DYKC的甄选到上架一系列流程全靠管理员完成，现在又是社群投票又是bot自动处理，难道是管理员推卸责任么？说到底，作为一个志愿者维护的协作计划，强行追究起责任来没什么意义。用“半自动工具的便捷”换“提报时加分类的举手之劳”，难道还不够么？--Antigng（留言） 2019年6月25日 (二) 02:11 (UTC)
      • 您提到的那些是社群在要求權利，而不是管理層主動下卸，條目內容必定是由社群中的人士寫的，所以社群要求投票甄選條目內容也要由社群自己負責，此乃正常不過的事；但是type我不見得也有這種特質。要求人家做對某事之前，請先想想人家本身有沒有責任或義務去做某事，如果人家沒有這責任或義務，您不能阻止他做錯。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 02:26 (UTC)
        • 2007年以前也没有引用模板，用户写条目加个裸网址就OK了，现在怎么建议条目作者使用cite模板，还不建议使用裸网址呢？作为一个就是想写条目，不管来源的美观程度的用户，他又有什么义务扩充裸链接呢？作为协作计划，自动分担责任才是正常不过的事情，过分强调义务可不是。--Antigng（留言） 2019年6月25日 (二) 02:39 (UTC)
          • 不同意這個比喻，一直以來編者本身是有義務避免裸連接，造模板的主要目的是為了方便他們避免，不是為了管理員省去責任。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 04:22 (UTC)
            • 但我參考了之前的討論，也有為數不少的用戶同意規範化type，那就意味著他們願意把這個義務轉移到他們自己身上，那我看不到理由要阻止規範化。這可以說是我們普通用戶在減輕管理員負擔上的一個苦心。Σανμοσα 2019年6月26日 (三) 10:19 (UTC)
            • 又或許這樣說：我認為Cdip150反對規範化的原因是他非常熱愛管理員的工作，對此我表示非常理解。Σανμοσα 2019年6月26日 (三) 10:26 (UTC)
其实既然用bot维护，那么type这个功能，为什么不能用专题来替代呢？根据条目所属专题的不同来区分条目类型是否会比较方便？（一个条目属于多个专题的话，所属专题相同的越少，则条目类型差异越大）毕竟type比较随意，而专题则相当固定。--百無一用是書生 (☎) 2019年6月25日 (二) 02:31 (UTC)
Shizhao的方案正正就是我在考慮中的其中一個辦法。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 02:35 (UTC)
专题似乎更麻烦：要求提名的用户给条目讨论页及时挂上专题评级模板。而且专题模板可以挂（很）多个，对bot制作者带来的麻烦大概也更大。--Antigng（留言） 2019年6月25日 (二) 02:39 (UTC)
又想省事，又想规范，这本身就矛盾啊。--百無一用是書生 (☎) 2019年6月25日 (二) 03:43 (UTC)
其實省事只限用戶參考type來選擇評選哪些條目和管理員如何排定上首頁的次序，規範才是我的主要目的。Σανμοσα 2019年6月26日 (三) 10:13 (UTC)
为什么要把type变得更复杂呢。我觉得现在的type就可行，当然type规范化也很好，如果规范化还允许别名的话，是麻烦一些。另外我也不觉得type只是给机器人看的，人也可以看的。--1=0，欢迎加入WP:維基百科維護專題 2019年6月25日 (二) 02:38 (UTC)
规范化的一个好处是把分类存档的问题也解决了。过去Liangent-bot工作的时候只能把条目存进“未分类”里。--Antigng（留言） 2019年6月25日 (二) 02:42 (UTC)
當上到{{DYK}}時，type是不可見的，所以人是不可以看的。而且就算給您規範type，如果某條目仍同時符合了多個type，那一樣還是為編者帶來煩惱。這之所以我想找type的替代品，因為這根本還是在勞煩編者，縱使勞煩程度可能不嚴重亦不太想看到。在我而言，對編者要求做的事情越少越好。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 02:56 (UTC)
上边的有一条建议是把type加进{{dyk}}模板里。如果愿意的话也可以让参数变得可见。显示效果例如：该类型对应的特色icon+分类名+冒号+问题。--Antigng（留言） 2019年6月25日 (二) 02:49 (UTC)
讀者瀏覽首頁時才不會想理首頁上的條目是甚麼類！--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 03:07 (UTC)
哈哈哈哈，我也这么想，不过我想的是评选的时候能看出是什么类就可以了。--1=0，欢迎加入WP:維基百科維護專題 2019年6月25日 (二) 03:12 (UTC)
評選時候看出甚麼類其實對評選來說沒有意義，至少不可能看到不對的分類就投反對票吧。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 03:17 (UTC)
有一定的参考价值吧。不一定是影响投票。--1=0，欢迎加入WP:維基百科維護專題 2019年6月25日 (二) 03:24 (UTC)
不過如果不影響投票，實在不知道對評選有何參考價值。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月25日 (二) 03:33 (UTC)
其實某程度上會影響投票，用戶可以透過分類決定是否參與某些條目的評選，這樣可以避免妄論用戶不熟悉的題目（如果用戶自己認為屬於妄論的話）。Σανμοσα 2019年6月26日 (三) 10:06 (UTC)
其實我認為在首頁加上分類也不是不可行，作用也是讓讀者選擇他們想看的條目的類型，也不是所有讀者也不想理會的。Σανμοσα 2019年6月26日 (三) 10:13 (UTC)
還有，我認為規範化分類填寫後，可能需要訂立一些特殊的填寫規則，例如所有單一人士的條目全部必須設定為「傳記／人物」分類。Σανμοσα 2019年6月26日 (三) 10:16 (UTC)
管理員看到兩個同類的條目，管理員自己把兩個type寫成一樣的字，便可以了，何必搞規範那麼複雜？所以不支持。--Opky9407（留言） 2019年6月26日 (三) 11:56 (UTC)
理論上，管理員不應隨意更改type，因為提名DYK的用戶填寫的type可能有特殊用意，這樣會引發編輯戰（我可能明白為何閣下經常和其他人發生衝突了）。另外，管理員也沒有責任更改type。Σανμοσα 2019年6月27日 (四) 10:22 (UTC)

兩天沒看，討論串就長了那麼多。我沒看完，只是想回應一下：

  1. 之前提到的反例說的是這個，上面一堆重複type，下面一堆重複type。以前劉嘉經常撰寫颶風條目的時候，我認識的某些朋友曾經抱怨過首頁展示的內容比較單一，甚至創作了一首歪歌來調侃一下。FA/GA/FL每天只展示一篇，而且要是等到DYK沒有颶風條目才上去，估計就要等很久了，不切實際。由此可見type參數的用處。
  2. DYK的type參數沒錯是不可見的，也不影響投票——我不熟悉很多領域，不過看到嚴重的翻譯錯誤，我才不會管這條目是甚麼類別的呢。它最大的影響是條目的展示順序。
  3. Shizhao方案有一個盲腸，一個條目是可以歸入多個專題的。例如這個，最後是劃入文物，國際關係，浙江，還是日本呢？更別說不同用戶掛portal模板的習慣不一樣，比如我掛portal模板一般是按照各地圖書館的分類慣例，學科前、地域後，但是某些用戶的做法是相反的。
  4. 要一般用戶記住分類法則較為繁瑣。之前曾經有個別用戶未經諮詢自行規範，不過可能會有人認為（至少我是這樣看）他是把自己的個人意志強加於社群。例如他把所有傳記類條目劃入biography類，但是我和街燈都不是這樣想（我之前手動更新的做法是：biography類不可重複，如果同一個時段要遇到另一篇不是biography類別的傳記條目，只要傳主從事的領域和已有的biography類條目的傳主不一樣，照樣更新。）。然而到互助客棧提到這話題的時候，街燈可能會認為這並不是強制要求，只是錦上添花，不需要規範。因此規範type參數這個話題，到最後總是不了了之。--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年6月26日 (三) 14:40 (UTC)
    • 我提出的这个方案，多类型的条目可以通过比对类型的相同度来判断条目类型上的差异。也就是说，所属专题相同的越多，类型越相近。这个方案可能比较会影响到的地方其实是分类归档这一块。--百無一用是書生 (☎) 2019年6月27日 (四) 02:07 (UTC)
    • User:春卷柯南我的計劃是首先在社羣達成規範的共識，然後我製作一個規範讓社羣看看是否適合（可以審議時修改）。Σανμοσα 2019年6月27日 (四) 10:25 (UTC)
  • 或許這樣說：現在這個討論可能就是管理員和普通用戶之間搶工作來做，兩邊都是工作狂（笑），然後又有些管理員和普通用戶打算因而順理成章把於其而言過重的負擔拋給對方。我認為如果要達致規範的共識的話，工作狂類型的普通用戶和不希望有太重的負擔的管理員佔多數會是最好的狀態。Σανμοσα 2019年6月27日 (四) 10:31 (UTC)
  • 綜合在這裏(：)回應：首先要明白一個道理：我很窮沒有錢，您捐錢給我，是否等於我必須接受您的錢？如果人家都說了不需要幫忙分擔義務的話，再好的苦心也是多餘。「管理員也沒有責任更改type」是錯誤的說法，別忘記type是管理員自己搞出來的東西，自然就產生打理type的責任，所以管理員有責任決定是否需要作出修改（即俗語所謂「自己造了隻鍋出來，拆這個鍋也應該要自己擺平」）。另一方面，與春卷柯南的第2點意見類似，投票者本身就應該要閱了條目才決定是否投票，而不是看類型，條目內容不是所有東西都需要投票者事先對該範疇熟悉的（例如有否列明來源、是否侵權等基本要求），看類決定是否參與某些條目的評選本身就是不該有的投票態度，type的作用本身就不應該影響投票和閱讀的取態，{{Dyk}}之所以在展示條目時保持了一定程度上的神秘感，其實就是希望讀者無論對某類有沒有興趣都可以看一下條目。而且，我還未看到大家填type時有過甚麼特殊用意，從實務上多年的觀察，各位參選DYK的人無非都衹是抱着一種態度：「我能以我想要的問題和圖片把條目放到上首頁，就行了」，實際根本不會很想理type是甚麼。我甚至憂慮定立規範會是幫倒忙：首先可以預估得到在type的管理上多了一重掣肘，彈性變少（至少春卷提到的處理方法會變得可行性極低）；二來是type還不會直接影響評審結果的時候，強迫提名者一定要正確使用type可能會讓提名者生厭，甚至可能影響提名他人的意欲。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年6月27日 (四) 21:07 (UTC)
那我只能支持廢除type，這次我不會讓步。Σανμοσα 2019年6月30日 (日) 13:59 (UTC)
說到這裏，我和您已有一個共同的方向——type遲早也應該要放棄。不過，在未有替代方案出爐前，管理員暫時仍需要倚賴type來控制。還有請懂得分一下莊閒：type是管理員自行創製和負責打理的事情，是故管理員要怎樣用type和甚麼時候不用type，理應由管理員自行決定，除非證實管理員打理type時影響到大家寫條目和評審，否則讓不讓步其實還未輪到一般用戶來說。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月3日 (三) 09:58 (UTC)

type的地位[编辑]

我認為對於如何看待type的地位，要取決於站內的需要。我認為可以由以下幾個問題評估結論：

  1. DYK的存檔是否有按條目性質分類的必要？
  2. 用戶是否時常有對於填寫type的煩惱？
  3. DYK條目上首頁除了受type影響外，還受甚麼因素影響（例如主編）？
  4. 外文維基百科的DYK制度是否（曾）有類近設置？如無，則中文維基百科當初設置的原因為何？如有已廢除者，則廢除的原因為何？

以上。산모사 DC17 2019年7月11日 (四) 06:23 (UTC)

  • 我個人對於1和2的答案分別是否定和肯定的。對於3的答案，我認為還會受主編和通過時間影響。산모사 DC17 2019年7月11日 (四) 06:25 (UTC)
    • 這串討論概念上就有問題，準確的應該是取決於管理員的需要。關於分類存檔，FA和GA賦予了條目地位並須靠條目質量維持，但DYK沒有任何地位賦予（這之所以一個條目可以多次DYK），所以DYK分類存檔其實多餘，更新程序早已放棄不管。type是有煩惱，但別忘記本質上是管理員用，您們填type衹是協助性質，不是責任性質，有煩惱其實大可以選擇不填不協助，交回管理員自己決定是否填和怎麼填（所以小工具和提名說明設它為「必填」，其實並不正確）；而DYK條目除了資格和質素外根本不應受任何其他影響，實務上多年的觀察，參選DYK的人衹會在意條目能否上首頁，卻不會在意條目何時上首頁；條目評審時，正如上面所說，是閱了條目才決定投票，不應因主編是誰而投票；是故討論type有否帶來煩惱和上首頁受何影響，根本沒有意義。其他外語沒有機械式做法，自然也沒有type的設置，即使有同類避免的做法，也是管理員親自人手選擇哪2個條目分開上（也就是Cloudcolors時期的做法）。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月11日 (四) 07:47 (UTC)

关于“不留重定向移动”[编辑]

试问回退员、巡查员技术上是否可以通过把被指向页面移动到新建的破坏性重定向页面，再不留重定向移回原始标题以通过G8删除符合G3的重定向？若能，社群是否支持这种操作？--DW祈福长宁 2019年7月3日 (三) 18:00 (UTC)

  • @DW_YoungDLS：甚麼意思？是指將A頁面移動到未存在B然後再不留重定向移動到A嗎？--【和平至上】💬📝 2019年7月4日 (四) 12:12 (UTC)
  • 「把被指向頁面移動到新建的破壞性重定向頁面」該行為本身是破壞。--Xiplus#Talk 2019年7月4日 (四) 13:05 (UTC)
    • 那样的话，还是挂g3吧。只是说这样会更快的压掉重定向而无需管理员处理，但是要是行为需要破坏性操作，还是不要的好。。。# D 2019年7月4日 (四) 17:32 (UTC)
  • 如Xiplus，顯然方針亦不支持，而且如此意義何在？--Hamish歡迎來訪 2019年7月6日 (六) 14:59 (UTC)
  • 如果頁面1被移動至頁面2，而頁面1的重定向未被編輯過，理論上要消除頁面1指向頁面2的重定向，可以把頁面移動至頁面1，然後再不留重定向移動至頁面2。不過如果頁面1的名稱是破壞性名稱的話，這樣做雖然可行，但不被建議。산모사 DC17 2019年7月11日 (四) 06:28 (UTC)

KOKUYO的地域中心“修正”行为是否正当？ITN改进方案？[编辑]

程序正当性的矛盾

依据Wikipedia:避免地域中心，“中文维基百科中，地点说明的最高级别行政单位最好以第一级行政单位为准，也可以注明至在华语圈中具有高知名度的城市即可，比如西安、洛阳、南京、武汉、广州、深圳、厦门、台北等。”不断添附中国和台湾，涉嫌违反WP:两岸用语方针：“当需要用以和台湾作非政治性用途对比时，应使用“中国大陆”一词，不要将“台湾”与“中国”并行（表述“台湾”不属于“中国”），也不要将“台湾”与“中国内地”并行（表述“台湾”属于“中国”）。此外，虽然香港及澳门隶属于中华人民共和国管辖，但通常不被视为中国大陆的一部分。”

行为正当性的问题

既然近期客栈有人提到蒋介石在中国大陆污名化的问题，中共和中国在台湾，甚至香港，难道不是这种情形？在叙述中有意无意要和政治上的中国挂钩，是否亦是一种不中立？且先不论是否有宣扬台独之目的刻意制造此对立，但事实却为台独的表述提供证据，似乎中国大陆四字亦不曾在某编者脑海中划过。诸动态中，就连上海都要加个中国前缀，就显得画蛇添足，且如前文所述，恐与方针抵触。另外，今天凌晨被加上台湾二字的长荣航空的劳方，更是造成歧义导致与事实不符合的解读之产生——长荣航空罢工的劳方，不是台湾空服员职业工会。最后，不断按自己的理解，去修改基本无异议的动态内容，是否接近于条目所有权的行为？另外，之前我就和其起过争论，我长时间不说话，不代表我对其种种行为之赞同，请好自为之。

搁置的Itn改善讨论

Itn相关的讨论区太多，以至于有许多搁置的讨论，建议Template talk:Itn、Wikipedia talk:新闻动态候选、Wikipedia talk:新闻动态等(±)合併为一个讨论区，并且列到互助客栈里面，以减少目前该区缺乏监督的情形。Wikipedia talk:新闻动态候选#新聞動態有一段2014年至今未解决的讨论，其中认为User:KOKUYO无论是否自行决定哪项新闻要登上首页，都要至少在Wikipedia:新闻动态候选上提供讨论的空间，我认为这是可行之举，但是至今未有所改善，这个板块几乎成为了KOKUYO的一言堂，甚至于别的管理员要加上什么，都几乎没有不被KOKUYO修改的。Portal talk:新聞動態里面亦在4月份提及2019年四川凉山木里森林火灾等重大条目迟迟不能入选，当时有站外意见认为管理员有意无意要淡化中国大陆的重大新闻，我亦有类似意见。另外，Template talk:Itn#關於校內暴力、職場暴力及大規模謀殺事件里面的提出者减少播报的态度，我是非常支持的。

最后關於校內暴力、職場暴力及大規模謀殺事件的讨论内容较少，我在此进行补充。依照常人思维，校內暴力、職場暴力及大規模謀殺事件属于社会所不容忍，正常情况不会产生，常人即便只是稍有涉及，也会对类似的行为感到愧疚与恐惧。但是，一旦人们收到了类似行为受到纵容的信号，就会产生破窗效应，因而产生模仿行为。大規模謀殺事件更加特殊一些，因为大规模谋杀事件，往往在媒体渲染下成为恐惧营销：媒体对其罪恶的模糊报道，恰恰标签化了罪犯，罪犯的意涵即超脱了犯罪本身，杯弓蛇影间人民更加恐慌；是否是真相对这些无良媒体并不重要，因为人民越恐惧就约会相信，报纸反而畅销，我不希望维基百科如此。因此，我反对维基百科为任何媒体口中的恶棍进行任何形式的恐惧营销，对于任何可能导致标签化的行为都应当谨慎对待。

--Unravel17（留言） 2019年7月7日 (日) 00:55 (UTC)

在此澄清一下:
  1. 當前絕大部分新聞都會在「不會產生爭議的地點」前面加上國家，如「美國紐約」、「紐西蘭南島」、「冰島艾雅法拉冰蓋」等，至於「釣魚台列嶼」之類的可能加上就會引起爭議的地點就不會添加國家。如果單獨只有中國沒有遵循此方式（如預設中文維基用戶是華人，都知道上海是哪個國家），那便是違反地域中心的宗旨。所以，「就连上海都要加个中国前缀，就显得画蛇添足」這句，其實就是地域中心的見解。
  2. 關於長榮航空罷工的部分，「團體協約是由長榮董事長林寶水、總經理孫嘉明，桃園市空服員職業工會常務理事李瀅、副秘書長周聖凱代表雙方簽約」。由於罷工尚未結束，所以把空服員工會往前挪動，作為「將在7月10日結束罷工行動」的主詞。
  3. 我自己的定位是維持新聞動態有最低的更新（當其他語言版本更新後，中文維基百科不能沒有改變），新聞動態候選則是只要有共識便能放上。關於當前新聞動態候選的流程，是新聞提名獲得共識（即1人以上參與支持），管理員才會認定這提名有共識，並依照該流程更新；如果提名沒有呈現出共識（即只有提名人提出），管理員直接更新ITN，那麼即管理員自己更新，而非依循新聞動態候選的流程。
  4. 經過上次的討論後，我也略為修改更新新聞動態的參考依據，包括德語維基百科和荷蘭語維基的首頁更新改列為參考（需要其他語言的維基有提名以上的佐證），及加上韓語維基首頁來解決地域中心問題（原本還希望有日語和蒙古語等東亞語種的維基百科，無奈這兩個的新聞動態更新已經長期停滯）。
  5. 還有，我從來沒有拒絕其他管理員更新模板，又或者其他非管理員用戶透過新聞動態候選流程取得更新共識。但如同其他管理員也會幫助我解決地域用詞、語法、圖片等等失誤，我也會幫忙其他管理員整理模板用語、格式長期以來的統一。
--KOKUYO（留言） 2019年7月7日 (日) 03:17 (UTC)
(！)意見：「不會產生爭議的地點」定义含糊，我已经指出阁下所为可能违反两岸用语方针，若因此产生争议又要加上国家则是自己给自己找麻烦。
以下是逐一(：)回應：
  1. 没有方针支撑阁下的做法，具体方针我已经给出。此外，桃园市怎么不加呢？还有，上海不是国家，谢谢。最后，我相信维基人的地理没有好到所有认识所有地名，如果我写个皮特凯恩群岛还要加上英国，岂不是时空错乱？我的理解是，依照維基百科:避免地域中心的方针，阁下何须画蛇添足，不断研究其国家归属，去添附标签呢？
  2. 如阁下所的材料给出，签订协议的是桃園空服員職業工會而不是台灣空服員職業工會，我亦已经给出。将桃園空服員職業工會说成是台灣空服員職業工會，这是否是原创说法？管理员为了所谓去地域中心化，做多少类似原创，会是合理的呢？
  3. 认定的标准是什么呢？实际上那个版面大部分人不会关注，最后还是管理员进行操作。如2019年四川凉山木里森林火灾这种有人迅速更新的重大新闻都要搁置许久，是不是ITN已经失去了其最初促进条目更新的目的，转而成为了展现管理员个人的国际观的舞台？
  4. 如前述，展现管理员个人的国际观的舞台？这个国际观十分有趣。首先一中一台就可以引起许多大陆人的不满。其次，忽视亚洲本来就已经成为了西方的诟病之一，以此判断国际与否，更是奇怪。最后，将本站内的沟通责任推卸到站外，在多次提议后却不去说明改善意见，我不认为这是什么缓解疑虑的举措，反而加深了对你不愿做出更多改进的印象。为自己辩护，可以啊，但是然后呢？忽视掉任何改进的讨论，就像在此处一样，我把的改进意见都给无视掉了？
  5. 我没有说你拒绝，我说“别的管理员要加上什么，都几乎没有不被KOKUYO修改的”，我认为这近似WP:条目所有权。阁下说“模板用語、格式長期以來的統一”，那么这个统一又是什么意思呢？难道阁下认为别人的编辑就不是为了“模板用語、格式長期以來的統一”，而只有“KOKUYO修改的”才是“模板用語、格式長期以來的統一”？“都几乎没有不被KOKUYO修改的”，这不是已经表明了对于其他人的不认可？
--Unravel17（留言）
@Unravel17：KOKUYO似乎修正过来了。
但在下不清楚一点，这位管理员是第几次因为这种问题被在客栈上或者其他讨论页面提及了？还请各位赐教。--痛心疾首（留言） 2019年7月8日 (一) 16:32 (UTC)
  • 仍然建议以具体问题举例来讨论问题，否则社群不容易参与。只有看到具体问题才知道自己有没有正确理解和引用方针指南。举一例，我认为“上海”并不需要前面加国家名称。中文世界不知道上海在哪里的恐怕寥寥无几。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年7月9日 (二) 02:43 (UTC)
    • 我認為需要加上，正如其他國家的城市一樣，應該國名+城市名，否則反而有違反地域中心之嫌，也不見得加上國家名會造成什麼重大障礙。—AT 2019年7月9日 (二) 17:37 (UTC)
      • 部分城市是“国际城市”，我认为这些地方无须加入国家。比如香港。~ viztor ✪ 2019年7月9日 (二) 18:27 (UTC)
        • 如果新闻动态同时出现中国和台湾，就会违反两岸用语方针。所以需要讨论使用。目前依照地域中心的方针，不需要添加，但是KOKUYO一直在缺乏共识的情况下，添加上他自己觉得重要的内容，已经好几次引起争议了。此外，我希望合并新闻动态各类讨论区（包括Template talk:Itn、Portal talk:新聞動態、Wikipedia_talk:新闻动态候选等），并放到互助客栈里面，这样透明度更高一些，我觉得这一方案是可行的，惟需要更多共识。--Unravel17（留言） 2019年7月9日 (二) 18:29 (UTC)
          • 若首页上典范条目中有“中国”，优良条目有“台湾”，是否违反两岸用语方针？ITN 里面不同新闻里，一条有“中国”另一条有“台湾”呢？同一条新闻里同时出现“中国”和“台湾”的情况我想应无争议地违反了两岸用语方针。--Tiger（留言） 2019年7月10日 (三) 02:21 (UTC)
          • (：)回應：我认为均容易令人误解为维基百科认为中国和台湾对立。依照方针，应当是中国大陆作为台湾的对应词语。优良条目和典范条目至少是独立模块，而且有较长的正文，不容易产生误解。而ITN作为独立的模版，按照KOKUYO的话说要保持“模板用語、格式長期以來的統一”，所以应当讨论其如何统一：是否按照其个人见解的统一，还是社群应当有规范？我认为社群应当有所规范，有所监督。--Unravel17（留言） 2019年7月10日 (三) 10:26 (UTC)
      • @AT：任何方针指南都允许例外，惟须证明例外性。上海在汉语圈的城市里，论知名度显然是顶级的。并不会有哪里的中文读者不知道上海是哪里（包括zh-2左右的非母语者）。换言之，提及“上海”时，不在前面加上国名并不会对任何中文维基百科读者造成障碍。（这种城市并不多，普通的中国大陆省会城市都不行。） --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年7月11日 (四) 05:19 (UTC)
        • 我還是比較建議加國名，至少上海的情況，加中國大陸應該是沒有任何問題。在這裡我考慮到的只是城市便應加國名，香港澳門等特殊地區則不用。當然我不是在說什麼強制性，但至少不應該阻止別人添加，因為這是一項完全正常的編輯。—AT 2019年7月11日 (四) 13:11 (UTC)
          • 我也同意AT的意见，能加国名则加国名，这样才是避免地域中心的做法，除非特别情况，否则不加国名就是有地域中心问题。--百無一用是書生 (☎) 2019年7月15日 (一) 07:13 (UTC)
            • 反对两位的意见。“加上了不会变得更坏”不能够支持“应该加上”。我同意“可以加上”，但反对“应该加上”。换句话说，如果别人已经写了“上海”，不可以改成“中国大陆上海”；反过来说，如果别人已经写了“中国大陆上海”，别人不可以改成“上海”。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年7月16日 (二) 02:04 (UTC)
          • (…)吐槽 “中国大陆上海”这种叫法我是第一次听说。个人(－)反对这种拗口、不常用、为了符合方针而强行“拼凑”出的用法。--Jimmyshjj 2019年7月15日 (一) 07:55 (UTC)
            • 如果中國有歧義或覺得中國大陸不順的話，寫中華人民共和國就完全沒有問題了。—AT 2019年7月16日 (二) 15:35 (UTC)

請管理員AT就使用者MeritTim濫用傀儡SmallTim一事做出解釋[编辑]

快速關閉-- Sunny00217 - 2019年7月9日 (二) 22:51 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
SmallTim是MeritTim的合理使用傀儡。

由於SmallTim做出違反文明之行為，警告後仍持續違反，理應被實施封禁，但MeritTim在整起事件中曾未參與。

但是，SmallTim的簽名是導向至MeritTim的使用者頁面，因此AT誤認是MeritTim違反文明，故將MeritTim封禁三日。由於SmallTim並未被實施封禁，因此SmallTim又再次於管理員通告版發言。此舉被AT發現後，AT就隨即對SmallTim以繞過封禁之名實施永久封禁，並同時對MeritTim以濫用傀儡之名延長封禁一個月。此後，SmallTim於其討論頁的封禁申訴上聲明其與MeritTim的關係後，AT隨即就將原違反文明的三日處置自MeritTim轉移到SmallTim上，並對MeritTim實施為期一個月名為濫用傀儡的封禁。

唯AT認為SmallTim不應使用簽名誤導他人和SmallTim違反WP:SIGN在先，因此責任在SmallTim，而非AT。事實上，無論簽名有無誤導性，AT仍可透過編輯紀錄查看發言方的真實身份，因此沒有查證是AT的疏忽，不應責怪SmallTim的簽名具有誤導性。

就算SmallTim的簽名具有極大的爭議，但是AT自始至終並從未針對簽名一事與SmallTim溝通，反而直接實施封禁，SmallTim知道簽名有爭議後，也於封禁結束後就馬上更改了導向頁，因此AT確實應該對於其疏忽道歉。

最後，當AT轉移封禁時已過一日，AT竟未將三日扣為二日，無故多封SmallTim一日。再者，繞過封禁和濫用傀儡並不構成事實，純粹是AT沒有經過查證，隨意對使用者冠上罪名，因此SmallTim於封禁申訴要求AT道歉，但是AT迴避了這個話題，直至封禁過期仍沒有解釋，明顯地溝通無效。SmallTim 2019年7月7日 (日) 04:59 (UTC)

  • 謹ping當事人@AT。—— Eric Liu（留言．留名．學生會） 2019年7月7日 (日) 10:33 (UTC)
  • 当初看您的签名，我也误会是 MeritTim 主账号。如有误会，我觉得也完全可以理解。同时，既然是误会，也算不上是谁的过错，解释清楚就好了。~ viztor ✪ 2019年7月7日 (日) 14:49 (UTC)
    • @Viztor：不，這個誤會我實在是無法理解，因為不實的罪名。SmallTim 2019年7月8日 (一) 07:06 (UTC)
      • SmallTim 何来不实罪名？您确实在主帐号被封禁期间利用傀儡（分身）账号做出编辑。就算主帐号封禁不合理，也不能以傀儡（分身）账号进行编辑并参加讨论，而是应该用主帐号申请解封。--Jimmyshjj 2019年7月8日 (一) 13:59 (UTC)
        • @Jimmyshjj：不實的指控，現在主帳號已是SmallTim了。SmallTim 2019年7月8日 (一) 14:20 (UTC)
          • 行行行。开头的「SmallTim是MeritTim的合理使用傀儡。」&SmallTim用户页上的软重定向皆让我误以为MeritTim才是主帐号。本人承认近期对阁下所有指控皆不实。--Jimmyshjj 2019年7月8日 (一) 14:34 (UTC)
            • @Jimmyshjj：我說的是「現在」，代表從現在開始，可以嗎？您不必如此為難地承認您的指控不實，我並不會因為您的舉動而感到如何。SmallTim 2019年7月9日 (二) 01:49 (UTC)
  • 首先，我封您的理由是違反文明，並不是違反簽名，所以您對簽名的所有抗辯在封禁角度來看沒有任何意義。其次，您的簽名導致誤封問題，一如我之前的說明，誤會的不止我一個人，大家都可以通過編輯紀錄查看發言者是沒錯，但是這並不代表您的簽名就可以隨意指向其他目標。我也不是因為您的簽名問題而採取封禁，而是封禁後才發現您的簽名有問題。至於責任所在，我讓社群判斷，謝謝。其三，封禁期沒有調整好確實是我的失誤，我僅在這一點僅表達歉意。最後，喜見您在解封後已經修改自己的簽名，希望您能繼續作出貢獻。以上，謝謝。—AT 2019年7月7日 (日) 15:17 (UTC)
    • @AT：您並沒有回答MeritTim如何透過SmallTim繞過封禁及濫用傀儡，然後現在MeritTim的封禁理由又是怎麼一回事？SmallTim 2019年7月8日 (一) 07:06 (UTC)
  • 在對我的帳戶有疑慮時，您更應仔細查證，而非將所有責任歸屬全部推給我和簽名。再來，上述提到的事項您並沒有做好。SmallTim 2019年7月8日 (一) 07:16 (UTC)
  • 呃，建議您先弄清楚前因後果，不要倒果為因。由於不存在繞過封禁和濫用傀儡的問題，因此MeritTim我已經解封了。而構成這個封禁的原因則是受您的簽名所誤導。另外，責任問題如我上述提到交社群判斷。謝謝。—AT 2019年7月8日 (一) 13:23 (UTC)

我不认为AT所为有任何不当，三天时间不足以把一些本来就很复杂的事梳理清楚。MeritTim的签名很明显违反WP:SIGN，这几个傀儡账号和主账号之间的关系最开始在几个管理员布告板上还没封禁时就已经把我看花了眼。当事人没有自己在用户页之类的显眼处解释清楚甚至封禁申诉也没有解释清楚；各个用户页、用户讨论页，主账号、傀儡账号之间重定向错综复杂，不出错反倒不正常。既然是误会，就没必要上纲上线。--Techyan（留言） 2019年7月8日 (一) 18:48 (UTC)

  • @Techyan：您要我在封禁申訴和用戶頁解釋什麼？而我又沒解釋清楚什麼？整起事件本來就不存在濫用傀儡及繞過封禁，並也解釋了簽名是我的疏忽，甚至向當事人道歉了，請問我哪裡做得不好？再來，「我擁有傀儡」一事也不一定要公開，甚至MeritTim的用戶頁也有寫道，儘管不是很完善。再請問各个用户页、用户讨论页，主账号、傀儡账号之间重定向如何错综复杂？僅有SmallTim的簽名重定向和其用戶頁軟重定向至MeritTim，別說得太複雜。最後，你說的不錯，既然整起事件是誤會，所以我更希望當事人再遇到相同的事件時，能夠更謹慎地處理，請不要假定我在無限上綱。SmallTim 2019年7月9日 (二) 01:44 (UTC)
“再來，「我擁有傀儡」一事也不一定要公開”。。。。诶，难道不是“我拥有傀儡”一事一定要显著的公开才对嘛？Bluedeck 2019年7月9日 (二) 17:28 (UTC)
这件事情可以快速关闭。双方既然都认可是误会，那么其实没有继续的必要了。~ viztor ✪ 2019年7月9日 (二) 18:20 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

如何翻譯「カイ」[编辑]

本主題全部或部分段落文字，已移動至Wikipedia:知识问答。

—以上未加入日期時間的留言是于2019年7月8日 (一) 00:14 (UTC)之前加入的。

玉皇大帝編輯[编辑]

本主題全部或部分段落文字，已移動至Wikipedia:互助客栈/条目探讨。

—以上未加入日期時間的留言是于2019年7月8日 (一) 00:14 (UTC)之前加入的。

（单纯讨论方针）CIV的管理范围[编辑]

假如说有用户A，和另一用户B产生无法化解的争议。为了鼓励自己的编辑工作，并且以不伤害他人的方法化解自己的心头之怒，A采用了“发泄小工具”技术软件。A在自己的小工具界面加入一行，作用是在页面顶部显示文字：“用户B是蠢货，不要和他谈话”。

目前的状况如下：1、小工具只对A有效，因此只有A能够看到这句话。2、小工具的源码存放在A的设置页面，任何人都能看到源码，而源码中确实包含了B是蠢货字样。

请问在这个情况下，A是否违反了CIV方针？？

我觉得下列几个答案都有自己的道理：

  1. 不管源码是否本身含有蠢货字样，只要这个小工具的效果是显示不良文字，哪怕只有A能看到，也是不文明。
  2. 只要源码中没有不文明的文字，源码效果是什么样子的维基百科管不到。
  3. 小工具效果只有A能看到，不构成伤害，不管源码如何，只要该源码不是放在“显著位置”，那么应该允许源码自由。

我经过一阵思考，仍无法说服自己究竟哪个选项是最有道理的。各个选项在我看来，都有其道理和不足。我把这个艰难的思考和大家分享，想知道你们的看法。

Bluedeck 2019年7月7日 (日) 23:40 (UTC)

CIV适用全站。既然看到了就需要处理。如果对方通过完全本地方式实现，那么不在WIKI管辖范围内。但若是站内可以找到违反CIV的实证，且可以证明。那么就按照规矩处理。这是我的意见。~ viztor ✪ 2019年7月7日 (日) 23:54 (UTC)
大概你是说WG？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月8日 (一) 02:07 (UTC)
我更关心这个问题本身，而不是WG的个案，因此这样提出问题。Bluedeck 2019年7月8日 (一) 20:57 (UTC)
單純討論方針Emmmm那應該放在方針區？—— Eric Liu（留言．留名．學生會） 2019年7月8日 (一) 02:49 (UTC)
和之前其他问题的讨论一样：观测到的、有影响的才是行为。未观测到就不是。既然可以观测到不文明行为，就应该应用CIV。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年7月9日 (二) 02:44 (UTC)
但是“观测到”这个说法没有好的定义。举例：假设用户A把不文明发言做了改变，变成：“用户B是[34850,36008]，不要和他讲话。”，那么是否算能观测到不文明发言呢？经过查询，发现34850=蠢，36008=货，此时是否算不文明呢？如果算的话，那么是不是以后不能出现这两个数字呢？如果不算的话，难道说把骂人的话变成数字就可以不算了嘛？？Bluedeck 2019年7月9日 (二) 17:13 (UTC)
如果是加密的，只有他一个人知道是什么意思，那就无所谓了，因为无法解读。如果仅有一部分人可以解读，但确实可以解读，例如使用摩尔斯电码、黑话、方言之类的，仍然要追究。有影响的才是行为。以你说的这个具体例子来说，那个是十进制的Unicode码，如果写成U+8822, U+8D27/U+8CA8，就是明确的不文明行为，因为可以轻易地通过google搜索来解读；写成&# 34850;&# 36008;也是一样。如果仅仅是写成[34850, 36008]，谜题的难度提高了，但仍然算不文明，因为仍然可以解读。如果写成[1111,2222]则不算。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年7月10日 (三) 06:13 (UTC)
人类不是AI，可以用脑子判断嘛。反正能观测到就在观测到的时候处理呀，毕竟当假如有人使用加密文字，类似[34850,36008]这种，我相信大家都可以注意到不寻常。~ viztor ✪ 2019年7月9日 (二) 18:25 (UTC)
  • 我最為認同2：只要源碼中沒有不文明的文字，源碼效果是甚麼樣子的，維基百科管不到，因為你沒有直接證據證明源碼會對人不文明。惟在此例，小工具的源碼存放在A的設置頁面，任何人都能看到源碼，而源碼中確實包含了「B是蠢貨」的字樣，這就已經是有直接證據，所以此例違反文明。산모사 DC17 2019年7月10日 (三) 08:19 (UTC)
  • 太聰明（還是想過頭？）也是一種錯...--奈威空白鍵|Sign 2019年7月12日 (五) 18:02 (UTC)

蘋果日報[编辑]

蘋果日報在2019年4月10日實施會員免費訂閱制，更在6月17日後需付費HK$3（香港）或NT$10（台灣）成為會員，直至9月1日，否則只限閱覽「編輯推介」的精選新聞及全部新聞標題，但無法閱覽影片、新聞內容，敬請留意。--A1Cafel（留言） 2019年7月8日 (一) 06:58 (UTC)

Special:用户贡献/Des Cascade[编辑]

轉自Wikipedia:当前的破坏#Des_Cascade和Wikipedia:元維基用戶查核請求#SiuMai，此用戶是否為SiuMai？--MCC214#ex umbra in solem 2019年7月10日 (三) 05:21 (UTC)

有關DYK因票數不足而落選問題[编辑]

DYK目前雖然有機制讓票數不足的條目有較長時間可以讓用戶投票，但是在這種情況下仍然不時出現因票數不足而落選的情況（三票支持最為可惜）。我自己也提名過相當多次DYK，僅因票數不足而落選的經驗比比皆是，這對於新手或老手來說都不是一件好事。鑑於DYK大多數只能選一次，而且有時限等問題，因此我建議修訂DYK規定，將投票時間延長至提名條目達四票或以上為止（無論支持還是反對），相信有助改善不夠票落選的情況，也可以促進用戶之間表達意見。在此希望得到各位的意見，謝謝。—AT 2019年7月12日 (五) 14:59 (UTC)

我有好多次2票失败。有几个看法，一，可以3票没有反对通过，就类似关注度30天降低14天，4票至3票，但那儿的反对应该也适用。有坏吗？有数据吗？我会说有。另一个方法是提交1个DYK，投其它4个，QPQ，为了新手前5条免。但可能太多暴力。一直延长也不是办法，新条目可能变成旧条目，机器人可能无法负担。我也不懂应该如何？--Cohaf(talk) 2019年7月12日 (五) 15:36 (UTC)
看起来好像脑内声音XD🤪~ viztor ✪ 2019年7月12日 (五) 15:55 (UTC)
閣下的原意是很好的，不過我覺得始終要有一個最大時限，不能說一直衹有三人以下投票就可以無限拖下去，構成積壓；而且Cohaf的降票方法易惹不公詬病，不太可取。敝人建議是票數要求不改，在現有的「4+3」的限期基礎上再稍作放寬，如改為以下程序：

投票期限：

  • 基本投票期為4天。
    • 當基本投票期屆滿時，如獲得中選所需的最低支持票數或以上，投票即會結束並獲通過。否則，投票將進入第一延長期，為期3天：
      • 當第一延長投票期屆滿時，如獲得中選所需的最低支持票數或以上，投票即會結束並獲通過。否則：
        • 如總有效票已達4票或以上，投票即會結束並以落選論。
        • 如總有效票未達4票，投票將進入第二延長期，為期(X)天：（註：(X)我建議最好是3天）
          • 當第二延長投票期屆滿時，投票必須結束；如獲得中選所需的最低支持票數或以上則獲通過，否則以落選論。
如何？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月12日 (五) 16:11 (UTC)
4+3+3--Cohaf(talk) 2019年7月12日 (五) 16:27 (UTC)
是。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月12日 (五) 16:33 (UTC)
(＋)支持好過沒有、聊勝於無--Cohaf(talk) 2019年7月12日 (五) 16:35 (UTC)
積壓我是覺得還好，畢竟只要多一至兩個人願意投票的話便可以解決。雖然再多三天是聊勝於無，但是這也不代表就一定夠票，因票數不足而落選的問題仍然沒有得到實質的解決。—AT 2019年7月12日 (五) 16:35 (UTC)
在DYK未有時限制的時候，因不夠票而積壓超過三週的情況是有招惹過不滿的，所以才出現了4+3制度。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月12日 (五) 16:55 (UTC)
我偶爾才會提報DYK，最近還有幾次是剛好四票通過的，不過我比較建議維持目前的4+3，若一定要修改，較支持Cdip150提的4+3+3。--Wolfch (留言) 2019年7月13日 (六) 09:44 (UTC)
我覺得可能要換換方法。例如票數不足的提名以高亮顯示（或粗體之類），讓用戶較易看到，從而增加投票意欲，4+3+3固然我也支持，但是需要更加針對性的方法才可以解決票數不足而落選的問題。—AT 2019年7月13日 (六) 14:37 (UTC)
以往舊點票機械人還在運行的時候就已經有類似的方法：夠票和未夠票的提名開頭是有勾號與否的標識之分，但三票落選的情況還是不時出現。而現在也有些活生生的例子：7月7日有兩個即將完結的提名——韩爱萍（2票支持，0票反對，7月7日至今之瀏覽量：105）和圣苏西宫（5票支持，0票反對，7月7日至今之瀏覽量：113），顯然這兩個條目都有相若地被檢閱，但是票數仍出現落差。所以票數不足而落選的問題，「較難看到」在我看來未必是主因。反而應該再深入了解一下為甚麼某些條目會有人不想投票，才好對症下藥，亂用方法我是擔心會助長不良的刷票風氣，畢竟我們投票應是仔細看完條目才投，而不是看着票數多少來投。我們應該做的是引導大家多為符合質量的條目投票，而不是引導大家有理無理為不夠票的條目投票。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年7月13日 (六) 16:14 (UTC)
我認為有一些條目票數不夠的原因是一些人覺得它並不是太達標，但有不至於投反對票（其實很少會投反對），而又覺得投中立過於無謂，這也可能是一些條目票數特別少的原因。-【和平至上】💬📝 2019年7月13日 (六) 17:18 (UTC)。月
我不知道有沒有關係，但是您提過之後，現在韓愛萍已經夠票了。而且，我覺得韓愛萍其實比一般DYK寫得還要好，不夠票很大程度應該是源於投票用戶對該主題沒有趣。我的見解是就算是冷門主題，也不應該因為單純其他用戶沒興趣投而落選。同樣達標，但有些落選，有些通過，我覺得這比刷票問題還要嚴重許多，我認為DYK畢竟門檻較低，而且一次性，因此比重上應該側重於如何增加投票率，這樣才能解決問題。—AT 2019年7月14日 (日) 14:48 (UTC)
无怜悯。如果过了最长限期仍不足票数，那就是条目的问题。不是应该继续抬进去。这种想法，还不如不要投票了，直接报备就是了，何必报批？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月15日 (一) 02:47 (UTC)
有時的確是條目本身有問題，但是與此同時也有情況是條目本身沒有問題，只不過是單純地票數不足。—AT 2019年7月15日 (一) 05:51 (UTC)
条目质量无问题有可能是主观感觉，当然，还是引用一句：“运气也是成功的一部分。”有时候如果你的DYK不足够引起注意没有被投票的话，那就只能说总有些东西缺失吧，即使是DYK本身被提过水票不少了。BTW，我也是见DYK的项目如有有感兴趣才细读再投票。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月15日 (一) 09:09 (UTC)
在我看來這就是冷門主題不受關注，導致同樣達標的情況下，出現冷門落選，熱門當選的不公情況。我不認為這是一件好事。—AT 2019年7月15日 (一) 09:25 (UTC)
当前规则下一个被证明行之有效的方法：继续编辑，延展编辑期，再次推荐。虽然很不优雅，我个人也不喜欢，但是社群认同。不建议做什么规则上的改变。你要么相信投票者都是体面而且负责的人，要么取消一般人的投票资格。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年7月16日 (二) 02:00 (UTC)

我對近期行為的聲明和澄清（嚴肅版，絕不開任何玩笑。比較長篇大論，希望大家能耐心看完）[编辑]

大家肯定會對我最近的行為和說話方法改變感到疑惑。本人最近於新手會的討論頁中發表了一篇比較具爭議性的言論。如果這篇言論對任何有關人士感到人身攻擊的話，本人事先在此致歉。我的確是整個人的性格扭轉了，我似乎不再是兩年前那位如此乖巧可愛的人。反之，我這兩三個月以來我的精神狀態比起以前更為惡劣，例如躁鬱症等的症狀，少許的事情就讓我非常惱火的情況經常出現。我希望能夠控制自己的情緒和言論，但是對我來說，很難做到。希望大家能多多包容我，即使我恍如變成了第二個維基病夫。

另外，我維基病夫必須在此澄清我去和新手會合作等行為。我絕非對維基學生會以至社群不滿才這樣做。只是我對於幫助新手的意見與大家截然不同。我反而認為幫助新手不應只建基於解答他們的疑難，而是應該先和他們建立朋友關係，並加強他們在維基社群的歸屬感和對維基百科的興趣，這樣才可以有效地幫助新手。我知道我這個想法非常荒謬和離譜，因為根本上和我能成為朋友關係的用戶少之又少，並且除了即時求助和互助客棧的求助頁外，幾乎沒有幫助新手的方法。同時我也提出這段時間在動員令幫助編寫條目有困難的新手，不過學生會那邊比較反對。我和維基學生會以至社群的意見格格不入，才選擇自立門戶，望見諒。--𝓢𝓲𝓬𝓴𝓜𝓪𝓷𝓦𝓟寧憑著耐性與骨氣，維持自尊撐過去·到此一遊 2019年7月12日 (五) 17:58 (UTC)

永远再见[编辑]

隐退。原因见用户页。已向原味鸡发送请求。再见。再也不见。Nano Kid C39H42O2 2019年7月13日 (六) 07:26 (UTC)

此人疑似有边缘人格障碍，估计不久的将来还会回来。另外此人混淆“爱国”和“爱党”两个概念。69.158.246.127（留言） 2019年7月14日 (日) 22:06 (UTC)
  • Nobody cares.與社群無關事務，關人屁事。這種行為除了博人眼球真的找不到第二個形容詞，建議不存檔直接刪除P.S.別搞砸知乎人理性客觀分析的形象 P.P.S就是不愛你的黨國，怎樣？-某人✉ 2019年7月15日 (一) 15:07 (UTC)
    • User:AINH知乎上的政治类问题也已经...--Br2 2019年7月15日 (一) 23:37 (UTC)

回退破壞[编辑]

本主題或以下段落文字，在討論結束後不存檔。

本主題或以下段落文字，移動自WP:VPP。执行人：--J.Wong 2019年7月14日 (日) 04:08 (UTC)。

IP被封了。산모사 DC17 2019年7月14日 (日) 00:58 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

@DW YoungDLS ：多次在波斯尼亚航空條目中回退至沒有分類，使Category:波斯尼亞航空公司變成空分類--195.206.107.214（留言） 2019年7月13日 (六) 18:25 (UTC)

  • (※)注意：以上是WP:D17C的扰乱，分类由D17C创建，且并非回退至无分类，而是原有另一不存在页面的分类。# D 2019年7月13日 (六) 18:28 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

關於新竹社群、新竹聚會之頁面，如何解決「新竹」一詞模稜兩可及地域中心之問題？[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新竹維基媒體社群。

經過User talk:Taiwania Justo#Re: 關於Wikimdians in Hsinchu "City"討論未果，乃決定交由這裡進一步討論。起因是「新竹」一詞，請看以下頁面：

以上可知，當時他們並沒有對「新竹」一詞解釋，有的只是每一場聚會有寫地點是在新竹市，比如：新橋B3、NCTU、新竹市立動物園、饗茶交大旗艦店，我根據這些訊息，跑去維基共享資源進行編輯他們的英文類別。然而，我們討論的是中文維基，我就這裡的問題去展開討論。除了新竹維基媒體社群已經修改成「這樣」，有對新竹一詞添加解釋：含新竹縣及新竹市。

不過，我認為這樣還不足以解決，因為那些聚會都是在新竹市發生，如何知道「新竹」一詞是有包含新竹縣？我的意思是，假設我順從他們的話去做，別人看到是我編輯的，一旦對我問起來：「這些聚會都在新竹市，為什麼你會添加新竹縣類別？」，這問題要我如何回答？因為事實也的確是在新竹市，所以我無法反駁情況下，乃決定現在不選擇順從他們的話，改採面對問題，並討論看要怎麼解決。

另一方面，按照User talk:Taiwania Justo#Re: 關於Wikimdians in Hsinchu "City"討論，若是真如他們所言，新竹聚會、新竹維基媒體社群的所謂「新竹」一詞是包含新竹縣，而不是僅止於新竹市，那麼我認為定義是有必要存在，這並非是我個人有無參加新竹聚會或推廣新竹社群的問題，反過來說，即使我參加、我推廣，我還是不能就這樣當成是，因為別人在頁面上訊息也的確沒看見對於「新竹」一詞的介紹，更何況你們聚會及推廣也不是為了這種事而來。我會如此糾結，就是要處理模稜兩可的命名以及地域中心。

此外，這問題也相同發生在維基百科:嘉義維基媒體社群（現在只有聚會頁面），全臺灣只有這二個社群才有這種問題。--Kai（留言） 2019年7月14日 (日) 07:13 (UTC)

基本上用了這麼久只有你一個人有問題。「臺灣維基人新竹聚會」是一個聚會的名字，這個聚會的人如果決定辦一場去台中交流的活動，就算聚會地點在台中，也還是「臺灣維基人新竹聚會」，不會變成「臺灣維基人台中聚會」。--Reke（留言） 2019年7月15日 (一) 06:38 (UTC)
以維基百科做名字空間的頁面，說實話有很多地方都是社群組織者的想法，沒有單一的命名標準，除了申請自治體委員會的認可的維基自治體外，也沒什麼明確要以地理界限為分類的命名規範。再說，之前我與Kai3952便已討論了如果社群經營者沒有獲得知會，達成修改共識前，其他貢獻者就逕自更動維基百科名字空間的內容，這不是以禮相待，結果Kai的回應不但沒有說明他逕自修改符合維基百科編輯五大支柱之一「以禮相待」的邏輯，反而更加執著於編修單一個案。這樣的貢獻與社群互動方式，我著實覺得不但對維基無益，反倒有害社群成長。 —-上官（留言） 2019年7月15日 (一) 07:33 (UTC)
我覺得Kai實在不必在沒有問題的地方硬找一個"問題"，再想方設法、千辛萬苦地為這個根本不是問題的議題找解法方案，這是自尋煩惱、杞人憂天。我建議你一旦有人對你問起來：「這些聚會都在新竹市，為什麼你會添加新竹縣類別？」，你可以反問他「非洲國家從未主辦過奧林匹克運動會，為什麼你會認為非洲國家可以參加奧運？」，儘管我認為根本不會有人問你「這些聚會都在新竹市，為什麼你會添加新竹縣類別？」。220.129.23.152（留言） 2019年7月15日 (一) 09:23 (UTC)
我的回應已在維基共享資源闡述。往後所有討論請集中在這裡（就是這個頁面）進行。臺灣杉在此發言 (會客室) 2019年7月15日 (一) 09:51 (UTC)
@Reke： 我知道是只有我一個人有問題，所以我才會提出這討論來問。即使聚會名字不因地點而變動，但你知道新竹有分「新竹市」與「新竹縣」嗎？我猜想，你們社群應該是不知道。建議你們還是對「新竹」一詞去說明，這才是有助於解決問題。--Kai（留言） 2019年7月16日 (二) 10:27 (UTC)
@Shangkuanlc： 我從來沒有更動你們在維基百科名字空間的內容，請問何來「逕自修改」可言？還有，這種事與維基百科編輯五大支柱之一「以禮相待」的邏輯是有什麼關係？至於你說的命名規範，那是因為新竹有分「新竹市」與「新竹縣」，即使你們要將「新竹」做為社群名稱或聚會名字，那也不能模稜兩可，甚至發生Wikipedia:避免地域中心，所以我們要解決的問題是：使用「新竹」一詞要如何讓大家知道這是在指「新竹市」與「新竹縣」這二個地方合稱的名字。此外，若是你真的認為我的貢獻與社群互動方式是有害，建議你向管理員舉報，這裡是討論事情而不是給你發牢騷。--Kai（留言） 2019年7月16日 (二) 10:27 (UTC)
@20.129.23.152： 那是因為你不知道這問題的源頭是發生在維基共享資源是使用「in Hsinchu」命名，我就是在那裡跑過來這裡，根據這些聚會以及社群頁面所提供訊息，然後回去在維基共享資源進行更改。否則的話，我何必自找麻煩，因為訊息的提供者並不是我，我只是負責執行（編輯及修正），看見什麼就做什麼，就是這麼簡單。--Kai（留言） 2019年7月16日 (二) 10:27 (UTC)
@20.129.23.152： 順便強調一下，既然訊息的提供者是新竹社群及聚會，那麼你說「沒有問題的地方硬找一個"問題"」，顯然「問題」是出自於他們，我看他們的訊息才會發生現在這種事，這是有前因後果。我不是在推卸責任，你們要說我沒先問、我自己胡亂解讀，這些我可以承認，因為事實如此，但是不等於訊息的提供者並沒有問題。我當時就看到他們提供的訊息寫了什麼，既然知道了，我又何必問，而你們要一昧指責我，那也只是在逃避，因為訊息本來就是這樣寫，我不知道我是有什麼錯？--Kai（留言） 2019年7月16日 (二) 10:39 (UTC)

用户兼管理员的与管理员权限无关的个人編輯。十二余年后依然缺乏提供原文来源。如何适当处理？[编辑]

时间发现时间早于去年八月中，本人在该管理员留言，至现时为止半年内该管理员没有就个别条目内容与在下沟通。现时在等侵权的办法。还有没有办法要求该用户沟通呢？-- Ktsquare 留言 2019年7月15日 (一) 20:36 (UTC)

请给出指向内容问题的链接而不是你想批评的人的用户页链接。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年7月16日 (二) 01:55 (UTC)
怎么又是你？如果觉得有问题，请改写并WP:RRD。问题条目是指費爾南·佩雷茲·德·安德拉德。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月16日 (二) 02:02 (UTC)
另外补充：Wikipedia:互助客栈/求助&oldid=52913783 、 Topic:Ut792ticywpmzbih。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月16日 (二) 02:08 (UTC)
无法理解一个重要度低、质量从未超过初级的条目有什么值得争论的。如果确实侵权，应当删除。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年7月16日 (二) 02:34 (UTC)
參見以前多次討論可以得知，此用戶對維基規定異常地不理解，只是在不斷纏繞不同用戶，尋求解決一個不存在的「問題」。如果情況持續，我不日內將會正式作出舉報，敬請合作。—AT 2019年7月16日 (二) 13:28 (UTC)

请求更改内容模型[编辑]

User:DW_YoungDLS/styles.css：修改为sanitized-css以便使用class属性。# D 2019年7月16日 (二) 15:37 (UTC)

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/其他&oldid=55244266”