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

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

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

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


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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 關於部分詞彙的翻譯(續) 148 26 12З4567 2022-01-23 15:57
2 假如有很簡潔扼要的方法能解決繁簡轉換問題,是否有必要特地使用複雜的手工轉換標籤? 37 16 Xiplus 2022-01-23 17:47
3 苹果日报台湾版确定凉了 23 19 Ericliu1912 2022-01-16 10:24
4 关于Unblock-zh邮件列表的一些事 43 16 魔琴 2022-01-15 19:09
5 提请解任管理员User:Iokseng 49 20 Ericliu1912 2022-01-16 03:46
6 条目同文堂及相关的警告模板 6 5 Tigerzeng 2022-01-20 23:05
7 IPBE權限能否考慮下放? 29 10 桐生ここ 2022-01-19 03:24
8 一月十五日至一月十六日屏東維基編輯工作坊 2 2 Ghrenghren 2022-01-16 02:14
9 千村狐免疑为基金会行动的罪魁祸首 5 5 LuciferianThomas 2022-01-19 11:49
10 拉票相關問題 2 2 Cdip150 2022-01-21 20:14
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

關於部分詞彙的翻譯(續)[编辑]

本討論接續Wikipedia:互助客栈/其他/存档/2020年6月#關於部分詞彙的翻譯,內文轉自translatewiki.net由Lakejason0發布的討論「关于通用术语表的部分错误的建议和部分条目相关疑问」 https://translatewiki.net/wiki/Thread:Portal_talk:Zh/关于通用术语表的部分错误的建议和部分条目相关疑问

Sincerely,

Winston Sung留言) 2021年9月11日 (六) 17:13 (UTC)
Fandom ZH Community Central Admin[回复]

註:部分討論已整併存檔至Wikipedia:互助客栈/其他/存档/2021年10月#關於部分詞彙的翻譯(續)

關於zh-hans/zh-Hans-CN中account的翻譯[编辑]

已通過:
僅調整「户=>号」之部分,即以「账号」作為zh-hans/zh-Hans-CN account之譯名。
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • 原文:account
  • 当前zh-Hant使用的翻译:帳號(已确认)
  • 当前zh-Hans曾使用的翻译:
    • 帐户
      • 根據討論走向可先排除
    • 账户
      • 根據討論走向可先排除
    • 帐号
    • 账号

由于当前翻译不一致,故在此希望各位能提供意见。--Winston Sung留言) 2021年9月17日 (五) 17:41 (UTC)[回复]

  • 那跟着用“帐号”比较省事。“账号”正确与否在大陆本身也争论不休,虽然我蛮喜欢的。--YFdyh000留言) 2021年9月19日 (日) 09:45 (UTC)[回复]
  • 这事有趣了,巾字旁长的结果小于贝字旁长,帐户(1,570,000)<账户(6,180,000)<帐号(11,800,000)<账号(11,900,000),也许Zhang户就此可以弃用了,稍微倾向支持账号。--Liuxinyu970226留言) 2021年9月20日 (一) 00:47 (UTC)[回复]
  • 「帐号」或「账号」均可,但如果想統一譯名的話,那就自然是前者。Sanmosa Outdia 2021年9月20日 (一) 13:41 (UTC)[回复]
  • 的本字,用之有合理之處。調了下Windows 11與本人的中國大陸產手機,簡體也用的帐。--紺野夢人 肺炎退散 2021年9月20日 (一) 15:21 (UTC)[回复]
  • @Yumeto:您的解释似乎只限台湾(甚至更有可能仅限台湾岛内,连澎湖金门马祖太平岛都不能适用),两字在大陆及欧洲华人圈内仅限会计学可以混用,前者多专用于纺织物或印刷相关(XX布、XX本……),后者则常用于金融、公务及普遍文字内容。( 囧rz……百度结果我向来不看,单独搜两字直接爆满“结果约100,000,000个”),Bing上单独搜两字 site:.cn,705,000跟2,180,000条结果相比,我都不知道后者甩前者几段第五大道了。
手机、电脑系统用字问题牵涉谷歌和微软,就目前老美对华日趋强硬鹰牌的现状下,这两家公司的系统开发部门指望有几个大陆血统的员工呢?想必大半的华人员工祖籍基本港台新马菲居多吧,基本可以肯定对大陆用词半知不解。由于当下疫情影响很难劝说两家公司改变有关做法,我打算先劝说一些对华还很友好的阿尔斯通、特斯拉等改变两字取舍问题,待国门放开后再设法择机访问两家公司总部当面讨论该等事宜。--Liuxinyu970226留言) 2021年10月13日 (三) 15:42 (UTC)[回复]

  • 考慮到简体中文輸入法問題,以「账号」作為zh-hans/zh-Hans-CN account之譯名公示七日。--Winston Sung留言) 2021年11月27日 (六) 16:30 (UTC)[回复]

  • 百度使用帐号,腾讯使用帐号,因此认为应该用帐号。另外个人认为账号通常用于金融,比如银行、电子支付、购物网站等,非金融的应该用帐号。桐生ここ[讨论] 2021年12月4日 (六) 18:41 (UTC)[回复]
    • 有资助功能,不能认为维基百科与金融无关,当前公示版本并无不妥。--Liuxinyu970226留言) 2021年12月5日 (日) 06:18 (UTC)[回复]
    • “用于金融,比如银行、电子支付、购物网站等”。我认为你对金融相关的理解与大多数人(至少是我个人)的理解不符。
      我对此译名没有任何意见,选一个即可。个人觉得在实际观感上没什么区别。
      顺便一个比较神奇的现象吧,虽然挺原创研究的:银行account称账户(号),计算机系统account称帐户(号),感觉这正在变成业界本地化惯例,可以观察到微软、谷歌等都这么干。反而是大陆本地的公司,比如腾讯,完全不在意这一点。--Lakejason0) 2021年12月5日 (日) 06:29 (UTC)[回复]
    • Wikipedia:2021年基金會針對中文維基百科的行動/中國大陸維基人用戶組相關討論#WMC對「維基」一詞的使用了解一下(趁着没存档),基金会全名有“Inc.”。--Liuxinyu970226留言) 2021年12月5日 (日) 06:43 (UTC)[回复]
    • 没错,是个公司就是金融相关的网站。这个逻辑恕我无法接受。您的逻辑也与其他人的实际意思不符。
      不再回复。--Lakejason0) 2021年12月5日 (日) 07:03 (UTC)[回复]
    • 您这个理论有点不好理解,要是说账号是中国规范汉字我倒是认可,但是维基百科主业是百科全书,而不是金钱交易,明显和支付宝、京东不一样,说维基百科是金融网站就不能理解了。桐生ここ[讨论] 2021年12月5日 (日) 09:20 (UTC)[回复]
    • 就算有资助功能,资助跟你在站内的account完全没有绑定关系啊。就站内的account而言,它的功能完全就跟钱和资金没有关联,想不出为什么这能成为要使用账号的理由。--Milky·Defer 2021年12月6日 (一) 14:51 (UTC)[回复]
  • 意見分歧,中止原公示,繼續討論。--Winston Sung留言) 2021年12月7日 (二) 16:56 (UTC)[回复]
  • (※)注意:“帳號”在大陆简体模式下会转换为“账号”,这在字词转换已早有讨论。中国大陆规定无论金融还是非金融都应使用“账号”而非“帐号”。“账号”既符合大陆规范,又能体现出维基百科的严谨性,故应坚持使用“账号”。--12З4567留言) 2021年12月9日 (四) 15:22 (UTC)[回复]
    同意意见,这就跟信息跟讯息两词的关系一样。--Liuxinyu970226留言) 2021年12月10日 (五) 01:05 (UTC)[回复]
    1. 规定的话,有没有相关具体的reference,我这边似乎没有查到。见上方全国科学技术名词审定委员会以及《互联网用户公众账号信息服务管理规定》
    1.1. 词典收录不算“规定”,如果确实有规定,那也最多算“体现”。
    2. 信息和讯息的关系同账号和帐号的关系似乎并不等价,前者在《现代汉语词典》(第7版)都有收录,且没有将某一方列为非推荐词形(即都出条并解释,并不是一个解释一个写见“xxx”)。而账号在《现代汉语词典》(第7版)中出条,帐号则既没有出条另见,也没有任何括号注释(见凡例标注非推荐词形的两种形式)。--Lakejason0) 2021年12月10日 (五) 04:59 (UTC)[回复]
    经过相关检索后,我不反对账号。
    但讨论一定要遵守最基本的逻辑,不要把正确的选择套一个(显然完全或者掺杂)错误的逻辑,以免误导讨论方向。--Lakejason0) 2021年12月10日 (五) 05:08 (UTC)[回复]
  • 不反对账号。桐生ここ[讨论] 2021年12月10日 (五) 01:55 (UTC)[回复]
  • 虽然不反对账号但在下还是更倾向于帐号。或者可否给用户一个可以自行决定用哪个字的选项( --千夏❀留言直接ping我回复 2021年12月12日 (日) 15:14 (UTC)[回复]
    • 如果是在translatewiki翻譯時處理,窒礙難行。--Winston Sung留言) 2021年12月13日 (一) 16:57 (UTC)[回复]
  • 用哪個字真的沒有關係,用的人多就用哪個,誰管你中國政府甚麼規定,你在中國銀行還是中國政府的條目裡再改成「账号」阿。我投帐号,Microsoft, Apple, Google 都用的帐号,上面也有人提到百度騰訊也一樣 (and no offense 但如果你天天在糾結這些事, you need to get a life)。--Austin Zhang留言) 2021年12月15日 (三) 15:15 (UTC)[回复]
  • “帐”字有传统字书收录,在大陆使用量不小,加之这里仅涉及术语翻译,用词统一为上,不用理会北京当局的规定。如果社群意见长期不能达成一致,我觉得开个投票未尝不可。--Lt2818留言) 2021年12月16日 (四) 13:59 (UTC)[回复]
  • 再次表达自己的意见:选一个即可。不要过于将一些决策带上政治色彩,没有必要。--Lakejason0) 2021年12月16日 (四) 16:39 (UTC)[回复]
  • 这里先前也收集了一下知乎上关于这个词汇的使用看法,基本和目前这里已有的信息一致。差别在于,一部分人认为“本字论”不足以支撑要用“帐”的观点(不能拿前朝的规矩斩后朝的官),反之也有人认为虽然政府文件和推荐术语都只有账号,但是也不足以支撑要用“账”的观点。从我自身的想法来看,任何想要把“用xx字”定义为政府要求的都是在拉偏讨论,实际情况就是“在意的人不多”,并且“现时无法得出这个词汇在大陆简体下的分化倾向”。如果中维既不能参考先前已有的中维处理方法(见上方的已经启用的转换规则),也不愿意参考任何大陆来源的资料,那我建议直接投票。--Lakejason0) 2021年12月16日 (四) 16:55 (UTC)[回复]
  • (!)意見:考虑了一下,我认为这里的讨论要针对“名从主人”做出一定的例外。例如微软帐户(Microsoft Account)就不应该替换成微软账号或者是被选定的其他选择。Lakejason0) 2021年12月18日 (六) 18:05 (UTC)[回复]

  • 重新/繼續公示,以「账号」作為zh-hans/zh-Hans-CN account之譯名公示七日。--Winston Sung留言) 2021年12月26日 (日) 10:43 (UTC)[回复]

  • 我倒是覺得按上面的討論來看沒什麼共識耶。—— Eric Liu 創造は生命(留言留名學生會 2022年1月4日 (二) 17:07 (UTC)[回复]
  • 这个词语个人觉得没有日后再议的必要。除去Liuxinyu的讨论以外,大家基本上是没有很强烈的某种偏好的。
就我个人而言,用账有道理(列举政府文件的目的是在于论证“有人而且有很多人这么用”),而用帐也有道理(除去有人对用“帐”字的解释我不认为正确(也就是所谓“这是本字”,我的意见见上)以外,事实层面是,微软、Apple、Google、小米,等等,都用帐字)。用哪个都不至于有人很不舒服。如果阁下认为应当以无共识作结,我建议开个投票,反正该说的理由差不多都说完了。--Lakejason0) 2022年1月5日 (三) 17:25 (UTC)[回复]
  • 查了几部词典,表示簿记相关意思,多用"账",此时“帐”通“账”,繁简差不多。--Kethyga留言) 2022年1月5日 (三) 09:31 (UTC)[回复]
  • @Winston Sung:公示早已结束了。--BlackShadowG留言) 2022年1月9日 (日) 08:00 (UTC)[回复]

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

關於各變體中wikitext的翻譯[编辑]

已通過:
「wikitext」使用原文不另翻譯。
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

無共識:
暫時擱置,日後再議。
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • 原文:wikitext
  • 曾使用的翻譯:
    • 使用原文:wikitext
    • wiki文字/wiki文本
      • 註:字詞轉換(含地區詞轉換)後,「文本」轉換為「文字」。
    • wiki代碼/wiki代码
      • 註:因wikitext屬標記式語言,故「代码」不轉換為「程式碼」。
    • wiki語言/wiki语言(wiki語言會和$wgContentLanguage混淆)
    • wiki語法/wiki语法(wiki语法会和m:Wiki syntax混淆)

注意:此討論不影響「wiki markup language」譯為「wiki標記式語言」/「wiki标记语言」。


由於目前翻譯不一致,故在此希望各位能提供意見。--Winston Sung留言) 2021年10月12日 (二) 14:53 (UTC)[回复]

  • 大陆这边倾向于(+)支持“wiki文本”,港台不好说。--Liuxinyu970226留言) 2021年10月13日 (三) 15:00 (UTC)[回复]
  • 在下主要的顧慮是「wiki文字」/「wiki文本」有誤解為wiki內之文字的問題,且「wiki文字」/「wiki文本」此翻譯在Fandom/Gamepedia/Wikia中文基本上已不再使用。--Winston Sung留言) 2021年10月13日 (三) 17:32 (UTC)[回复]
  • 我希望直接用wikitext。我认为wikitext本身既然是专有名词还是保留不翻译为妙。我举个例子,如果专有名词要翻译的话,gitignore是不是要翻译成“Git忽略”?EditorConfig又是否要译成“编辑器配置”?如果这样的话,专有名词变成了普通名词,反而引起误会。--Tranve () 2021年10月14日 (四) 14:59 (UTC)[回复]
    • 补充一句,如果有人想用“用惯了”来反驳我的话,我是不能苟同的。我认为译名标准化本身就会破坏掉一部分习惯。总之期待大家的意见,谢谢。--Tranve () 2021年10月14日 (四) 15:01 (UTC)[回复]
    • gitignore是标签名,自然不能翻译,后者翻译成编辑器配置我倒支持,毕竟VisualEditor都翻译成可视化编辑器了。--Liuxinyu970226留言) 2021年10月15日 (五) 04:11 (UTC)[回复]
    • 我记得今年六月份@Shizhao曾经把一些翻译从wiki文本改为wikitext的,请问Shizhao可以征询一下您的看法吗?--Tranve () 2021年10月15日 (五) 13:08 (UTC)[回复]
    • Tranve的意见正是我的想法。另外,wiki代码可能和wikicode混淆。wikitext又叫做wikicode,见en:Help:Wikitext,所以wikitext和wikicode虽然有时指同一个事物,但是两个词,中文也应该作为两个词对译。另外,wikicode还可能指m:WikiCode。如果非要翻译,wiki文本我认为是最合适的,与Plaintext(纯文本),richtext(富文本)相对应,容易理解,wiki文字有些莫名,其他几个则都和text扯不上关系。或者干脆点,维基文本?--百無一用是書生 () 2021年10月18日 (一) 11:57 (UTC)[回复]
    • 另,wiki语法会和m:Wiki syntax混淆--百無一用是書生 () 2021年10月18日 (一) 12:01 (UTC)[回复]
    • > wiki文字有些莫名
      這是字詞轉換(含地區詞轉換)下的結果。--Winston Sung留言) 2021年10月18日 (一) 14:16 (UTC)[回复]
      • 解釋:文本=>zh-tw:文字,plaintext(純文字)、richtext(富文字)。--Winston Sung留言) 2021年10月29日 (五) 02:52 (UTC)[回复]
    • > wiki代码可能和wikicode混淆
      該頁面描述的是姊妹計畫提案,故wiki的部分(相對於非WMF站點譯為「wiki」)應會譯為「維基」。--Winston Sung留言) 2021年10月18日 (一) 14:16 (UTC)[回复]
    • > wiki语法会和m:Wiki syntax混淆
      這部分的確沒注意到,可以排除此候選譯名。--Winston Sung留言) 2021年10月18日 (一) 14:16 (UTC)[回复]
  • 新譯名候選:「wiki語言」/「wiki语言」。--Winston Sung留言) 2021年10月17日 (日) 16:34 (UTC)[回复]
    • 「wiki語言」/「wiki语言」有誤解為wiki使用之語言($wgContentLanguage)的問題,排除。--Winston Sung留言) 2021年11月2日 (二) 04:44 (UTC)[回复]
  • @Winston Sung:香港一向把短英文當成日常用語(例如Facebook),因此香港(與澳門,如適用)的翻譯直接沿用原文“wikitext”即可,語感上比較舒服。@Shizhao:其他地方的翻譯是否沿用原文“wikitext”看討論走向,雖然我也傾向支持這樣做,但我不保證語感。Sanmosa WÖRK 2021年10月18日 (一) 13:33 (UTC)[回复]
  • 就「wikitext」(使用原文)、「wiki文字/wiki文本」(地區詞轉換後,文本轉換為文字)、「wiki代碼/wiki代码」(地區詞轉換後,標記式語言之代码不應轉換為程式碼)三譯名候選繼續討論。--Winston Sung留言) 2021年11月19日 (五) 15:30 (UTC)[回复]
    • 个人认为争议过大,建议暂时以无共识结案,待几个月后再重启讨论。--Liuxinyu970226留言) 2021年11月25日 (四) 10:33 (UTC)[回复]
  • 存檔。無共識:暫時擱置,日後再議。--Winston Sung留言) 2021年11月27日 (六) 16:38 (UTC)[回复]

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

  • 原文:wikitext
  • 曾使用的翻譯:
    • 使用原文:wikitext
    • wiki文字/wiki文本
      • 註:字詞轉換(含地區詞轉換)後,「文本」轉換為「文字」。參見:plaintext(简体:纯文本;繁體:純文字;)、richtext(简体:富文本;繁體:富文字;)
    • wiki代碼/wiki代码
      • 註:因wikitext屬標記式語言,故「代码」不轉換為「程式碼」。

注意:此討論不影響「wiki markup language」譯為「wiki標記式語言」/「wiki标记语言」。


  • (轉自#其他讨论)另外本人来迟了,wikitext就像Markdown一样是专有名词,不需要翻译,namespace翻译为命名空间是很常用的,几乎大部分计算机语言都用命名空间。桐生ここ[讨论] 2021年12月4日 (六) 19:29 (UTC)[回复]
  • 繼續討論。--Winston Sung留言) 2021年12月11日 (六) 04:25 (UTC)[回复]
    • (!)意見这讨论确定可以两岸四地统一?我反正希望至少大陆称作“wiki文本”。--Liuxinyu970226留言) 2021年12月16日 (四) 10:40 (UTC)[回复]
  • (+)支持wiki文本,markdown在大陆有些教材也会翻译为标记下语言。--Liuxinyu970226留言) 2021年12月15日 (三) 01:41 (UTC)[回复]
    • 标记下语言过草--Milky·Defer 2021年12月15日 (三) 03:29 (UTC)[回复]
    • 同上,太草了。桐生ここ[讨论] 2021年12月15日 (三) 03:47 (UTC)[回复]
    • 「標記下語言」一詞未曾聞之。閣下可有參考文獻?--Winston Sung留言) 2021年12月15日 (三) 15:02 (UTC)[回复]
    • 同上,闻所未闻。可以断定只有极其业余的教材才会这样翻译。--Tranve () 2021年12月26日 (日) 07:56 (UTC)[回复]
  • @MilkyDeferTranve桐生ここWinston Sung(※)注意根据d:Q1193600有部分语言确实翻译了这个词:阿拉伯语“ماركداون”、阿塞拜疆语“Endirim”、波斯语“مارک‌داون”、韩语“마크다운”和泰语“มาร์กดาวน์”。--Liuxinyu970226留言) 2021年12月16日 (四) 10:30 (UTC)[回复]
    • 阿拉伯语、波斯语、韩语、泰语不算,这些最多算纯音译/转写。
      判断依据是由机器标注的读音。--Lakejason0) 2021年12月16日 (四) 16:48 (UTC)[回复]
    • 至于阿塞拜疆语,不清楚是不是机器翻译(毕竟Google翻译会把Markdown这一词给出很多“Discount”的翻译出来,惊人的一致),我个人也不能排除是否为语言特性。
      个人倾向还是,不翻译比翻译的多得多。转写纯粹是为了符合语言本身的规则,不能认为是“翻译”了。--Lakejason0) 2021年12月16日 (四) 16:58 (UTC)[回复]
    • 同上。按本詞情況而言,不應將「轉寫」、「翻譯」混為一談。--Winston Sung留言) 2021年12月16日 (四) 18:02 (UTC)[回复]
    • 其他语言的习惯不能代替中文习惯作为依据。--Tranve () 2021年12月25日 (六) 12:06 (UTC)[回复]
  • 支持不翻译,reStructuredText也没有翻译。桐生ここ[讨论] 2021年12月15日 (三) 03:47 (UTC)[回复]
    • @桐生ここ:不知阁下是否可以接受“再结构化文本”,我只是不明白为啥一碰见编程就死皮赖脸非得不翻译,Autodesk在大陆都得叫“欧特克”,有什么不能翻译的。这东西在世界语中称作“ReStrukturitaTeksto”,波斯语叫做“متن مجدد ساختار یافته”--Liuxinyu970226留言) 2021年12月16日 (四) 10:30 (UTC)[回复]
    • “再结构化文本”您见过哪里用过?AsciiDoc,PostScript,YAML您再给翻译下?桐生ここ[讨论] 2021年12月16日 (四) 11:39 (UTC)[回复]
    • 可以:美国信息交换标准代码文档、后脚本(反正post quantum都翻译成后量子了PostScript还有何理由维持英文?)、雅梅尔--Liuxinyu970226留言) 2021年12月16日 (四) 12:52 (UTC)[回复]
    • 提醒一下这个官网把LilyPond称作“荷花池”。--Liuxinyu970226留言) 2021年12月18日 (六) 03:18 (UTC)[回复]
    • 至少平常使用時不太會說「我用荷花池編寫樂譜。」吧……。--Winston Sung留言) 2021年12月18日 (六) 12:01 (UTC)[回复]
    • 开什么玩笑?这样翻译会出现多少理解错误,您不考虑考虑?上边已经有多少人觉得这样的翻译很奇怪了……--Tranve () 2021年12月26日 (日) 07:53 (UTC)[回复]
  • 重点是半中半洋不觉得奇怪吗?wiki您给翻译一下,由于维基被注册为商标,我觉得它需要一个新翻译。桐生ここ[讨论] 2021年12月16日 (四) 11:46 (UTC)[回复]
    • (*)提醒关于“维基”商标状态,台湾我没能力查,大陆这边我在测试维基上搞了一个子页面:testwiki:User:Liuxinyu970226/wikitrademarkcn,“维基”一词没有一个注册方是WMF,有8个是已注册状态,其中一个“李友成”注册的涉及社交网络服务,但除此之外没有一个跟互联网相关的,所以用维基来翻译wiki倒也不为过。--Liuxinyu970226留言) 2021年12月16日 (四) 12:36 (UTC)[回复]
    • 至于由维基媒体基金会有限责任公司(WMF全称的中文翻译是这样吧)注册的商标基本都是“维基百科”,有4个是注册状态:14347544(国际分类25)、14347545(国际分类18)、26726637(国际分类16)和28106628(国际分类9),基本都跟儿童玩具、衣物、床单床铺、书籍等有关。好几个仅仅是注册公告,甚至最新的一个44682724(国际分类42)是驳回复审状态。综上我不认为“维基”一词商标可以阻碍将wiki正常翻译为“维基”(至少跟计算机相关的各种领域)。--Liuxinyu970226留言) 2021年12月16日 (四) 12:48 (UTC)[回复]
    • 维基这条目该更新了,话说维基一词是怎么来的,好像是当时编者翻译的?WMF有权注册为商标?我查了,确实在台湾是商标,“维基百科”等也都是商标;香港没有“维基”二字商标,但有几个“XX维基”商标,是其他机构注册的;澳门没有记录。桐生ここ[讨论] 2021年12月16日 (四) 15:36 (UTC)[回复]
    • 当然,不仅这条目得改写,就连页面底部“维基™是维基媒体基金会的商标。”也可以重新检讨存在的意义了。而且我从Python基金会那边听说ta们也在积极申请中文商标?不知道叫啥,不过商标综合检索搜了一下,有好几项结果里该基金会提供的中文名是“皮东软件基金会”,应该是要申请“皮东”吧。--Liuxinyu970226留言) 2021年12月18日 (六) 03:03 (UTC)[回复]
    • 是不是商标只是次要的,重要的是怎么翻译能让文案保持统一并且让用户易于理解。--Tranve () 2021年12月26日 (日) 02:58 (UTC)[回复]
    • 「維基™是維基媒體基金會的商標」一句於臺澎金馬區域屬實於中國大陸區域則未有註冊。故不反對简体將wiki譯為维基,但顧及翻譯及轉換之一致性不建議再另外分化譯名。--Winston Sung留言) 2021年12月26日 (日) 10:33 (UTC)[回复]
  • 支持不翻译。不能说好翻译就翻译,不好翻译(Markdown这类字面语义与实际内容关联不算太大的)才接受不翻译的。这也根本不是“碰见编程就不翻译”,仅仅只是在讨论界面文本的统一而已,你写条目该翻译还翻译就是。--Lakejason0) 2021年12月16日 (四) 16:43 (UTC)[回复]
  • 同之前意见,(+)支持不翻译。--Tranve () 2021年12月26日 (日) 02:57 (UTC)[回复]
  • 別翻譯了吧,每種譯名都會丟掉wikitext這個語言的特性,倒不如不要翻-- Sunny00217  2021年12月26日 (日) 06:44 (UTC)[回复]

以「wikitext」使用原文不另翻譯公示七日。--Winston Sung留言) 2021年12月26日 (日) 10:36 (UTC)[回复]



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

關於zh-hans/zh-Hans-CN中widget的翻譯[编辑]

  • 原文:widget
  • 当前zh-Hans曾使用的翻译:
    • 小工具
      • 与gadget译名冲突。
    • 微件
      • Android 11採用的翻譯。
    • 挂件
    • 小部件
    • 小组件
      • 可能与components译名冲突。
    • 小器件
    • widget(使用原文)

https://phabricator.wikimedia.org/T296583https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/742246 --Winston Sung留言) 2021年12月1日 (三) 05:34 (UTC)[回复]

  • 我选择(+)支持小部件,只是因为搜索结果远多于其他的(必应1,130,000条),PS:貌似小器件更多(1,150,000条)但是就担心考古学家可能不买账。--Liuxinyu970226留言) 2021年12月2日 (四) 01:02 (UTC)[回复]
  • (+)支持微件,作为一个同时兼顾音译及意译的翻译,是一个较好,不算差的选择。使用频率确实低了一些,但是凡事不应只看搜索结果,最好也看看搜索结果的相关程度,以及翻译本身的好坏。--Lakejason0) 2021年12月2日 (四) 16:39 (UTC)[回复]
    • 就像不要强迫大陆人接受“武汉肺炎”用法一样,我反对强迫大陆接受“微件”,该词如今更可能在大陆被误解为:
    1. 微软公司的相关法律诉讼案件
    2. 微信文件--Liuxinyu970226留言) 2021年12月5日 (日) 06:16 (UTC)[回复]
    • 强迫大陆接受“微件”这句话我不想说什么(我是不是得说你在代表大陆?不敢说不敢说)
      如果阁下继续以这样的逻辑反驳,我将不再回复。--Lakejason0) 2021年12月5日 (日) 06:25 (UTC)[回复]
    • 顺便,大陆人不会把微件理解成微软公司的相关法律诉讼案件或微信文件。我问的要么知道,要么只说不知道。--Lakejason0) 2021年12月5日 (日) 06:33 (UTC)[回复]
    • 怎么可能会有人这么理解?按照这个逻辑“天才”是不是会误解成“天生的蠢材”?显然不会,凭常识都可以反驳。希望您以后发言能注重逻辑,谢谢。--Tranve () 2021年12月6日 (一) 11:18 (UTC)[回复]
      • 然而腾讯视频用天才指代天生蠢材已不少见,这种“反驳”自身便漏洞缠身,例如这个。--Liuxinyu970226留言) 2021年12月16日 (四) 10:43 (UTC)[回复]
    • 本大陸人表示用「微件」指代上述兩個東西的做法聞所未聞。--Nrya ✰武漢肺炎兩週年•Xi病毒來襲 2021年12月14日 (二) 23:44 (UTC)[回复]
    • 使用频率确实很低。我也是Android新版本zh-CN改译了微件才知道有这个翻译。--Lakejason0) 2021年12月16日 (四) 16:40 (UTC)[回复]
    • 看错了一些文本,抱歉。--Lakejason0) 2021年12月16日 (四) 17:09 (UTC)[回复]
  • (+)支持“微件”。--东风留言) 2021年12月4日 (六) 16:22 (UTC)[回复]
  • (+)支持小部件,微件使用频率有些过低,并且微件的字面意思可能不足以反映真实含义,小部件相比之下更加的易懂。——HornCopper(C·T·P 2021年12月4日 (六) 16:59 (UTC)[回复]
    • 您好,目前正在讨论的是widget,完全不是一个东西。相关言论已移除,故不再有这方面的意见。--Lakejason0) 2021年12月4日 (六) 17:25 (UTC)[回复]
  • (+)支持小部件。components是组件,widget是部件,不一样。桐生ここ[讨论] 2021年12月4日 (六) 18:50 (UTC)[回复]
  • 小部件和微件我都可以接受。--Tranve () 2021年12月7日 (二) 13:24 (UTC)[回复]
  • (!)意見:是不是也应该考虑一下“插件”?这个才是CS语境下widget最常见的译名。--菲菇维基食用菌协会 2021年12月7日 (二) 04:37 (UTC)[回复]
    • 插件会和plugin混淆,个人认为不妥当。--Lakejason0) 2021年12月7日 (二) 04:44 (UTC)[回复]
    • > 插件会和plugin混淆
      同上。--Winston Sung留言) 2021年12月7日 (二) 06:34 (UTC)[回复]
    • 需要提醒一下此处的“widget”所处上下文位于mw:Extension:Widgets中,因此即使排除重名的因素,我也认为不合适。@Winston Sung:能否在讨论和加入术语表的时候明确上下文?上下文可能会对术语翻译有影响,谢谢。--Tranve () 2021年12月7日 (二) 13:28 (UTC)[回复]
    • 確實在考慮到語境包含扩展的情況後插件明顯不適合。--Winston Sung留言) 2021年12月7日 (二) 14:52 (UTC)[回复]
    • > 能否在讨论和加入术语表的时候明确上下文?
      @Tranve:感謝提醒。我會認為這邊考慮一致性可能會同時包含非mw:Extension:Widgets的部分。--Winston Sung留言) 2021年12月7日 (二) 14:52 (UTC)[回复]
  • 那,挂件呢?--Milky·Defer 2021年12月7日 (二) 11:02 (UTC)[回复]
    • 会不会和某些人给手机加挂的饰品称谓有冲突?--Liuxinyu970226留言) 2021年12月16日 (四) 10:48 (UTC)[回复]
  • 目前看来大陆“小部件”支持者比“微件”略多,不然就小部件公示吧?--Liuxinyu970226留言) 2021年12月23日 (四) 01:08 (UTC)[回复]
  • 目前2比3,不能說有明顯共識。--Winston Sung留言) 2021年12月23日 (四) 03:51 (UTC)[回复]
  • Android 11上用的是“微件”--百無一用是書生 () 2022年1月13日 (四) 02:34 (UTC)[回复]
  • (+)支持“微件”。--12З4567留言) 2022年1月23日 (日) 07:57 (UTC)[回复]

關於zh-hant/zh-Hant-TW中widget的翻譯[编辑]


https://phabricator.wikimedia.org/T296583https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/742246 --Winston Sung留言) 2021年12月1日 (三) 05:34 (UTC)[回复]

  • 能否麻煩您也看一下 Android 是怎麼翻譯的?手邊沒有不過應該也是個不錯的參考基準,畢竟是很多人會接觸到的軟體。wctaiwan留言) 2021年12月1日 (三) 05:44 (UTC)[回复]
  • Android之zh-Hant-TW widget翻譯未變更,仍為「小工具」,與gadget譯名衝突。--Winston Sung留言) 2021年12月1日 (三) 06:02 (UTC)[回复]
  • 既然如此我還是傾向於小元件,感覺上意義比較接近,台灣人(因為微軟譯名的關係)應該也比較熟悉。未來有需要的話 components 可以翻譯成元件或者是組件,不是專有名詞的話應不至於有衝突的問題。wctaiwan留言) 2021年12月1日 (三) 06:21 (UTC)[回复]
  • 我目前是傾向於譯為「微件」,一方面同時顧及音譯及意譯,另一方面顯示時與其他命名空間名稱二字對齊。參考資料:中華民國專利資訊檢索系統[原文如此] https://twpat1.tipo.gov.tw/twpatc/twpatkm (無法產生靜態連結。公開公告號: I459314,專利名稱: 微件個人化及互動之架構及其方法 A STRUCTURE AND METHOD FOR WIDGET PERSONALIZATION AND INTER-WIDGETS COMMUNICATION。)--Winston Sung留言) 2021年12月1日 (三) 16:18 (UTC)[回复]
  • 按照在Microsoft Language Portal查到的資料,除了「小工具」以外大部分譯為「控件/介面控件」或不翻譯。--Winston Sung留言) 2021年12月2日 (四) 07:32 (UTC)[回复]
  • 依此看來台灣最常見的翻譯應該是小工具(Windows + Android + 國教院 + iOS)。根據 Google,微件看起來應該是大陸用語,我個人還是覺得多數台灣人看到當下大概無法會意。與 Gadget 衝突這點確實是個難題,如果直接使用原文呢?還是乾脆讓它衝突算了...(不過說真的如果過個兩三天都沒有其他人有意見,我大概也不會堅持反對,畢竟只是我一個人的偏好。)wctaiwan留言
  • 台湾翻译是“小工具”,有冲突的话,不如直接用zh-Hans-CN翻译。桐生ここ[讨论] 2021年12月4日 (六) 18:54 (UTC)[回复]

回覆工具翻譯問題[编辑]

  • 这回复工具底下“并同意根据the CC BY-SA 3.0 License and GFDL发表您的贡献”粗体部分确定不能翻译?好歹叫CC BY-SA 3.0许可证和GFDL也行啊--Liuxinyu970226留言) 2021年12月16日 (四) 10:45 (UTC)[回复]

其他討論[编辑]


  • 上面的消息框不是我加上去的就是了。實際上不是完全不受中文維基百科方針約束,但不完全受中文維基百科方針約束,比如公示等部分實際上在translatewiki不存在。--Winston Sung留言 2021年12月5日 (日) 16:27 (UTC)[回复]
  • 我稍微修改了一下,如果有意见的话请直接提。--Tranve () 2021年12月6日 (一) 11:14 (UTC)[回复]
  • 好的。感謝。--Winston Sung留言) 2021年12月7日 (二) 06:35 (UTC)[回复]

  • 要不以后单独开设一个互助客栈板块讨论这些事?--Liuxinyu970226留言) 2022年1月11日 (二) 06:27 (UTC)[回复]
  • TWN的事情在TWN讨论。--Tranve () 2022年1月13日 (四) 11:24 (UTC)[回复]
  • 不建議,畢竟一般是人數不足、在 translatewiki.net 無明顯共識或是影響層面大才會在維基百科討論。--Winston Sung留言) 2022年1月15日 (六) 09:42 (UTC)[回复]

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

假如有很簡潔扼要的方法能解決繁簡轉換問題,是否有必要特地使用複雜的手工轉換標籤?[编辑]

大家好。這邊在編輯冬季战争時,發現其實我們有很簡單的方法可以解決繁簡轉換:

原文
蘇聯空軍在整場戰爭中都緊握著[[制空權]]
手工轉換法
蘇聯空軍在整場戰爭中都緊握-{zh-hant:著;zh-hans:着}-[[制空權]]
更改文字法
蘇聯空軍在整場戰爭中都緊握着[[制空權]]

手工轉換法大概是現行維基百科所推薦的方法,然而這方法複雜,感覺不但會有許多類似的情況,還不利於機器語義分析。相形之下,更改文字法簡潔多了,也方便人類閱讀。假如就這種不更改就會產生繁簡顯示錯誤的情況,特別通融以簡單扼要的方法解決繁簡轉換問題,不曉得大家認為會有哪些顧慮?--Kanashimi留言) 2021年10月10日 (日) 07:02 (UTC)[回复]

我也覺得這樣比較方便。說實話,這跟刻意的繁簡破壞應該有差,很好辨別,不然也可以指定編輯摘要。—— Eric Liu 歡慶雙十中國國慶留言留名學生會 2021年10月10日 (日) 08:09 (UTC)[回复]
诶?原来这还是方针不允许的吗?我已经这么干了有段时间了(捂脸)--Milky·Defer 2021年10月10日 (日) 10:14 (UTC)[回复]
  • 理论上说“为了更简便的修复/避免错误的繁简转换而更改文字”可以视作繁简转换的正当理由(参WP:CST#勿手动转换条目繁简语句),不过可能会产生争议。Itcfangye留言) 2021年10月10日 (日) 11:37 (UTC)[回复]
  • 我认为这种理由不够尊重“不转换”,所以主张使用手工转换。--7留言) 2021年10月11日 (一) 10:46 (UTC)[回复]
  • 這邊發現手工轉換還可能造成參差不齊。例如上面舉的例子其實不夠完善,較完善的的確該使用{{}}裡面的-{zh-hans:着;zh-hk:着;zh-tw:著;}-。也就是說不同人可能就有不同的、有缺陷並且必須再修正的手工轉換修正方法。比較保險的應該採用更改文字法,或{{}}。然而假如正規使用這些文字轉換模板(包括簡繁轉換一對多列表、繁簡轉換一對多列表裡面所有的文字),猜測其中一些恐怕會成為使用率前百名的模板。如此恐怕會有前述效能問題。這或許不是偏好問題,而是技術性問題。--Kanashimi留言) 2021年10月11日 (一) 11:03 (UTC)[回复]
  • 希望有其他管理員看看是否還有其他疑慮,否則就上面討論看來,似乎應該允許此類型修正?--Kanashimi留言) 2021年10月11日 (一) 20:23 (UTC)[回复]
    • 如果非要点名管理员的话,那我说一下。我记得以前是不时有见到或进行此类修改的,也没见有人提出异议,虽然我不知道近些年有没有其他讨论。{{}}这类模板,我觉得只有必要在上下文比较复杂的时候使用(具体例子没想到),而不是把每一个遇到的着/著字都改成模板。另外说一点,虽然对这个案例并不适用,以前大家会单独使用里面没有东西的-{}-来提示分词,然后让系统自动转换,好像现在这么用的越来越少了,而是更倾向于在-{}-里面具体指定需要的转换效果?(直接写或者用类似{{}}的模板)我提及这个是从标题的“簡潔扼要的方法/複雜的手工轉換標籤”想到的。Liangent留言 2021年10月11日 (一) 21:21 (UTC)[回复]
  • 作为(前)繁简转换维护者来说两句:简繁转换并不是一一对应的,大多情况都是一简对多繁,而像“著”和“着”则是一繁对多简。我觉得手工把“著”改为“着”,是符合Wikipedia:繁简处理#勿手动转换条目繁简语句中要求的“正当理由”的(因此,现有规则即允许这样做)。反过来的例子会更多,比如ref group用“註”而不用“注”,表示动词时用“幹”不用“干”等等。这些一多对应的文字,的确可以为常见组合增加转换规则,但我不觉得这个能覆盖完整,而且也不是所有情况都能加规则解决,比如<ref group="註"><ref group="注">。因此,遇到了这种毛病,手改没问题,提报一下看能不能安全地将其文字组合加进全局转换则是进阶要求。--菲菇维基食用菌协会 2021年10月11日 (一) 22:15 (UTC)[回复]
    同上。Sanmosa WÖRK 2021年10月12日 (二) 14:47 (UTC)[回复]
    通商。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC)[回复]
感謝各位的意見。感覺更改文字法應該可以算作共識了。--Kanashimi留言) 2021年10月13日 (三) 22:43 (UTC)[回复]
是否應該考慮明文寫入指引,作為案例?—— Eric Liu 創造は生命(留言留名學生會 2021年10月14日 (四) 13:49 (UTC)[回复]
或許在方針裡提一下比較好?--Kanashimi留言) 2021年10月14日 (四) 20:30 (UTC)[回复]
附議。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC)[回复]
我也認同「现有规则即允许这样做」,支持指引加一句提醒。——遲來的HTinC23留言) 2021年10月23日 (六) 13:45 (UTC)[回复]
反对写入规则,选择“不转换”的用户不希望强制看到外语文字。--7留言) 2021年10月30日 (六) 15:25 (UTC)[回复]
又不是規定一定要這樣做,只是「除罪化」,保證不會因此觸犯方針或指引而已。偏好手工轉換者,大可繼續手工轉換。—— Eric Liu 創造は生命(留言留名學生會 2021年10月30日 (六) 20:25 (UTC)[回复]
实际效果一样,“保證不會因此觸犯方針或指引”也就意味着能够以此为理由强行把他人使用的手工转换改掉,而且有方针支持的情况下还能对3RR豁免。--7留言) 2021年11月1日 (一) 08:58 (UTC)[回复]
如上述討論,這或許不只是個偏好問題。您可以針對上面討論的贊同論點一一提出您的解方,如此更能說服人。--Kanashimi留言) 2021年11月1日 (一) 20:02 (UTC)[回复]
他就是不想處理而已,反正他也沒打算認真進行討論。--Sanmosa Ázijská Práca 2021年11月2日 (二) 08:19 (UTC)[回复]
我的主张就是当其他用户已经用手工转换时不以这种“理由”去改(等于阻止)。如果双方都坚持原来的用法,那要么先到先得,要么就不管谁坚持改都按3RR处理。如果修改前后在“不转换”下显示的文字一样,我没有意见;如果为了所谓“簡潔扼要”,代价却是强制不转换用户看到不同文字,这我无法接受。--7留言) 2021年11月2日 (二) 12:43 (UTC)[回复]
現在的情況就是一個合法,一個可能違法,需要明文「除罪化」;在已經有既有轉換方式之下,採納「先到先得」原則應該是沒有問題。—— Eric Liu 創造は生命(留言留名學生會 2021年11月10日 (三) 14:38 (UTC)[回复]
「選擇『不轉換』的用戶不希望強制看到外語文字」這句我看不懂,不轉換不是本來就一堆所謂「外語」文字嗎?--路西法人 2021年11月28日 (日) 16:11 (UTC)[回复]
同意。--Nrya ✰我聽見有個聲音~ 2021年10月31日 (日) 03:41 (UTC)[回复]

@Kanashimi:如果要擬文說明以上這種變更的性質,您會怎麼描述?—— Eric Liu 創造は生命(留言留名學生會 2022年1月17日 (一) 02:51 (UTC)[回复]

或許可這樣:
改成:

--Kanashimi留言) 2022年1月17日 (一) 03:40 (UTC)[回复]

原本 改為 能否接受
修正轉換錯誤
{{著}} 修正轉換錯誤
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 可以,但不推薦的修復方式。
-{zh-cn:着;zh-tw:著;}- 造成轉換錯誤
-{zh-hans:着;zh-hant:著;}- 造成轉換錯誤
造成轉換錯誤
{{着}} 不必要的行為
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 不必要的行為
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 造成轉換錯誤
-{zh-hans:着; zh-hk:着;zh-tw:著;}- {{著}}{{着}} 簡化原始碼
{{著}}{{着}} 造成轉換錯誤
{{著}}{{着}} {{著}}{{着}} 不必要的行為
錯誤用詞
其他繁簡文字可類推
子弹 子弹 修正轉換錯誤以避免「头發」
一刀不剪布影片 一刀不剪布影片 修正轉換錯誤以避免「剪發」

提供涵蓋所有變換的表格,看看是否符合上面的共識。--Xiplus#Talk 2022年1月22日 (六) 03:22 (UTC)[回复]

唉,這表格真是太簡單明瞭了。--Kanashimi留言) 2022年1月22日 (六) 06:22 (UTC)[回复]
我觉得{{著}}{{着}}改成其实应该允许且鼓励。一来提高源码可读性,二来减少不必要的模版调用。--菲菇维基食用菌协会 2022年1月22日 (六) 06:25 (UTC)[回复]
感覺只要不會造成轉換錯誤,「着」比「{{}}或{{}}」略優。「著」到「{{著}}」一類可以在手頭沒有簡體輸入法時,只打括號做權宜之計。但長久來看,使用視覺化編輯器或語法凸顯工具時,模板太搶眼。--洛普利寧 2022年1月22日 (六) 06:36 (UTC)[回复]
以更改繁體以避免加入切斷標記的方法也是可以囉?例如將「一刀不剪发布影片」改成「一刀不剪發布影片」以避免「剪发」被轉換也是可以的?--Ghren🐦🕘 2022年1月22日 (六) 13:30 (UTC)[回复]
是這意思。我加上了這個例子。 --Kanashimi留言) 2022年1月22日 (六) 23:48 (UTC)[回复]
那可以把{{}}的內容改成「」,並將使用方式改成{{subst:}}。--Xiplus#Talk 2022年1月23日 (日) 09:47 (UTC)[回复]

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

苹果日报台湾版确定凉了[编辑]

消息见彭博社的这篇报道Jimmy Lai’s Flagship Apple Daily to Shut Taiwan Operations,很明确说出苹果日报的资金将在12月底耗尽,到时台湾分公司也会跟着倒闭。报社的官方消息不愿证实,这次可以肯定连苹果新闻网也要彻底凉了。台湾分部似乎也找不到买家的说[1][2][3]

现在最该讨论怎麽大量备份,维基百科一定有数不尽的Apple Daily链接。--贝塔洛曼外交公务箱 2021年12月5日 (日) 23:11 (UTC)[回复]
近几个月不时有HK苹果的引用被以死链为由删除,我只能发现一个救一个,但被发现而救回来的相信只是少数。--Benevolen留言) 2021年12月5日 (日) 23:56 (UTC)[回复]
蘋果日報作為一份實體報紙,無論鏈是死是活都可以作為來源。--🎋🎍 2021年12月6日 (一) 01:53 (UTC)[回复]
就怕WG之流沒事找事。--中文維基百科20021024留言) 2021年12月6日 (一) 01:56 (UTC)[回复]
如果来源是实体报纸那就没有这个问题,如果来源是站点的话,应该考虑如何存档,而且一直有Wikipedia:失效链接如何操作,WG就是卷牛角尖而已。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年12月6日 (一) 02:21 (UTC)[回复]
留意到今日曾穎彤條目出現與Walter Grassroot風格相近的移除來源的編輯。--Mewaqua留言) 2021年12月15日 (三) 10:57 (UTC)[回复]
LTA:米記123也會移除蘋果日報來源(Special:Diff/69160057)。-- 2022年1月11日 (二) 07:50 (UTC)[回复]
苹果日报在本wiki的链接一般archive.is网页时光机会有存档。以死链为由而删除链接是违反方针的。--CCPSupporter留言) 2021年12月22日 (三) 11:02 (UTC)[回复]
应该可以通过IA来对特定网站进行批量存档?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年12月6日 (一) 01:10 (UTC)[回复]
台灣蘋果否認這一消息。但台蘋一年多來不斷傳出將要被出售,故認為即使沒錢了也只是易主的問題,不見得會關閉。--🎋🎍 2021年12月6日 (一) 01:51 (UTC)[回复]
比如改成旺旺集团收购?--Milky·Defer 2021年12月6日 (一) 06:29 (UTC)[回复]
水晶球?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年12月6日 (一) 08:19 (UTC)[回复]
千万别!--Txkk留言) 2021年12月8日 (三) 13:01 (UTC)[回复]
不親中共的台灣報章已經不多了,真的別啦-- Matt Zhuang表示有事按「此」留言 2021年12月9日 (四) 17:21 (UTC)[回复]
先不要好嗎--Nrya ✰武漢肺炎兩週年•Xi病毒來襲 2021年12月14日 (二) 23:41 (UTC)[回复]

題外話,需要大量備份的清單除蘋果外恐怕又要加上立場新聞了。——HTinC23留言) 2021年12月29日 (三) 00:52 (UTC)(2021年12月29日 (三) 13:47 (UTC)修改)[回复]

把“恐怕”两字去掉,今天这铁拳砸过来谁都来不及反应啊。--🔨留言) 2021年12月29日 (三) 10:17 (UTC)[回复]
11點關站了。根據經驗,備份是追不上清算的。我就曠工了一天去補國安法案件列表,同樣的時間花在wayback machine貼連結根本是不切實際。全網站備份也不是一般維基編輯做到的事,有時間不如平常多引用這些媒體內容寫條目(眾新聞應該活不久了)。Oneam 01:00 AM留言) 2021年12月29日 (三) 15:44 (UTC)[回复]
相比之下端传媒机智多了早在8月跑路去新加坡。对于有关门迹象的媒体,当下能做的事情只有趁他们还没正式关门之时将链接进行存档(法轮功系媒体除外,本就不适合优先使用),台湾苹果如果能维持正常经营或找到下家倒还好,没法继续活的话也得存档去。网上应该有工具可以批量存档。--🔨留言) 2021年12月30日 (四) 01:11 (UTC)[回复]

Next,眾新聞--S叔 2022年1月2日 (日) 16:58 (UTC)[回复]

既然你们这么喜欢苹果日报,等旺旺收购后再救链接也不迟。--維基小霸王留言) 2022年1月16日 (日) 01:19 (UTC)[回复]

可能有點晚了w —— Eric Liu 創造は生命(留言留名學生會 2022年1月16日 (日) 02:24 (UTC)[回复]

关于Unblock-zh邮件列表的一些事[编辑]

目前unblock-zh邮件列表的主要业务有:

  1. 帮助被迫使用代理者注册账号
  2. 授予IPBE以便编辑
  3. 回答关于普通IP段封禁的问题
  4. 普通封禁申诉

其中前两项占比约7成,第三项2成,封禁申诉最少。近30天内主要是我在回复收到的邮件,但因个人安排,约一周后,我能承担unblock-zh的工作量会下降到目前的1/4左右,若届时没有其他管理员来帮忙处理,我担心会出现邮件太长时间没有回复的问题。下面是一些我在回复unblock-zh邮件过程中遇到的问题,也顺便和大家分享:

  1. 此前因为我个人的问题,有几次让邮件积累了一周甚至更长,才一次性回复完。导致的问题是:有些人时隔一周多才收到回应(当然有些人发信后几个小时就恰好遇到我在回信)。理想的状态:我没有在回信的时候有其他管理员帮忙,其他管理员有事的时候我可以帮忙,总之持续有人在回信,这样大家工作量都不大。
  2. 从IRC等渠道,我发现有些人的邮件因为没写主题或含有特定的词汇等等,被邮件列表的反垃圾系统拦截。导致的问题是:管理员没收到邮件,发信人不知道自己的邮件没有被收到。
  3. 不同管理员授予IPBE时不同。虽然我本人遵照方针要求,会至少确认申请者有需要使用网络代理(确认其封禁信息),但其他管理员中也有并不要求这一点的(当然也有不认可我的做法,认为应该更严的)。而且,我在邮件沟通中能确认的也只有对方提供给我的,声称是自己看到的封禁信息,有心人完全可以仿造一个出来,我没办法辨别。导致的问题是:我对自己的工作(要求对方提供封禁信息以证明需求)产生了怀疑,不知道是否应该继续这样下去。
  4. IPBE授权后被证实使用傀儡者,有。即便有IPBE,使用代理,也有人因为编辑行为,甚至技术证据,而被发现运用傀儡账号。换言之,IPBE并不完全阻断对傀儡账号的查核。但是,也有没被发现的持有IPBE的傀儡,是可以想见的。

开这个讨论串,原本是想找人帮忙一起受理unblock-zh的工作,让社群了解unblock-zh的现状,但是发现有些问题,使得是否继续使用unblock-zh可能应该打个问号。需要解决的问题有:

  1. 如果有管理员有意愿帮忙回复邮件,但不知道怎么帮忙或操作上有困难的话,可以在这里弄明白。
  2. 当前情况下,IPBE的授权应当满足什么条件?我想这个条件在各种申请渠道应该相对统一。授权后应留下什么记录?例如unblock-zh的邮件记录链接是我授权中最常用的,里面可以查到申请人受到IP封禁影响的证据。

--Tiger留言) 2022年1月2日 (日) 18:28 (UTC)[回复]

是不是應該ping所有管理員來討論啊?—— Eric Liu 創造は生命(留言留名學生會 2022年1月2日 (日) 21:21 (UTC)[回复]
沒有管理員佈告板主頁的問題。要所有管理員注意的議題永遠要全ping。--路西法人 2022年1月3日 (一) 09:12 (UTC)[回复]
据我在(你们所不承认的)QQ群中帮助新手的经验,大部分大陆新手都不能再一周之内收到邮件反馈。这对于新手的打击是致命的,有很多人因为长时间收不到邮件而放弃了编辑维基。有很多人因此在QQ群里质问,而目前在QQ群内没有站内管理员,因此我们只能表示无奈。--三万光年 GBAW 2022年1月3日 (一) 02:07 (UTC)[回复]
毕竟去年9月份基金会大挥铁拳之后管理员人手开始出现短缺,而关于管理员投票是否使用SecurePoll也是最近才出结果。--🔨留言) 2022年1月3日 (一) 03:40 (UTC)[回复]
和基金会行动关系不达,被除权的几位在邮件列表里本来也不算活跃,或者根本没有加入邮件列表。--Tiger留言) 2022年1月3日 (一) 04:46 (UTC)[回复]
关于第一个问题,我个人的意见是或许可以推举一到两位专门负责处理unblock-zh邮件的管理员来协助处理积压。如果目前的管理团队内部不能满足,就从社区里招募合适人选,推举有条件有经验愿意长期接手unblock-zh邮件积压的人去参选管理员,当然被推举的参选者应当能在协作处理unblock-zh积压的问题上有所承诺,能保持长期的耐心不是五分钟热度。
关于第二个问题,我个人认为只要我们坚持假定善意原则,就没有理由收紧IPBE。有一个统一的具体筛查标准固然最好,但在这个领域应该没法真正适用任何统一的标准。需要IPBE的理由应有尽有,洞察这些理由虚实的金科玉律却没几条,最后自然就只能统一放行,那些明显不成立的理由总归是少数。哪怕是全域IPBE,只要表明自己已经获得本地IPBE,监管员基本上也只能要一个就给一个,因为在这个问题上无法对别人刨根问底。当然每个管理员的个人标准不尽相同,愿意在这个问题上更加负责和仔细审核总是好的,只是整体上的收紧在我看来还是不贴合维基社区长远发展的需要,而且客观上增加了管理员自身的负担。况且在大陆没有IPBE约等于无法参与编辑,而纯破坏者却总是有各种各样的门路和歪点子来蒙混过关。所以把IPBE收的太紧到底是防君子防不住小人。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年1月3日 (一) 03:43 (UTC)[回复]
关于筛查标准,我的意思不是你说的这个部分。事实上并没有管理员会去质疑“我住在中国大陆不得不用代理”、“我不会乱用权限”这个部分。邮件受理请求时,会要求申请者给出封禁详情,也就是多少挡一下其实根本不需要代理但是假装自己被封的人。但是这一点在站内申请的时候基本上从来不要求。这里就产生差异了,也就是我希望统一的部分。要么都要封禁信息,要么都不要。如果选择都不要的话,需要先把WP:IPBE方针改掉,因为里面要求用户需要“有真实的需求”。--Tiger留言) 2022年1月3日 (一) 04:45 (UTC)[回复]
另外,如果社群认为不需要封禁信息即授权,以及差不多完全放开授权的话,我会建议直接给所有注册用户加上这个权限,就是把ipblock-exempt直接添加到user用户组,还省掉申请和授权的麻烦。--Tiger留言) 2022年1月3日 (一) 04:53 (UTC)[回复]
如果是这个统一的意思我也是很赞成的诶,所谓“有真实的需求”本身就无法完全查证,其实也就只能靠自觉。况且WP:IPBE方针和中维的实际情况已经偏离了。IPBE原本是提供给有极端特殊原因被广域封禁误伤的极少数个例的,所以作为一种管理员权限的分支是会谨慎授予。这在其他社区是适用的,比如英维有单独IPBE的用户比管理员还要少的多,他们都各自有特殊原因。但到了中维反而正相反,一批批大陆新用户普遍需要获取IPBE才能参与编辑。IPBE原本的特殊前提根本就是完全不适用的,按照方针还要查阅申请者的编辑记录,这在中维等于逆反因果。IPBE在中维反而更像是一种辅助处理防火墙封锁问题的通行证。所以我个人完全支持简化授权过程,改成统一走一遍形式留个记录就是,减少审核负担。
再从这个角度出发,进一步考虑把IPBE直接下放的话阻力就大了。个人是觉得是有些冒进,但有可操作性,值得让社区仔细讨论讨论,我个人先给一个保守的支持。毕竟当下一个IPBE权限的申请问题就直接挡住很多潜在的编辑者了,很多人好不容易翻墙来维基了,一看自己IP是被封禁的估计就直接打消了今后的编辑欲望,潜意识里会产生“我编辑不了”的想法。而会进一步考虑“为什么怎么办”然后来申请IPBE的必然只剩下这当中的一部分人了。所以把IPBE直接添加到User用户组里对中维发展一定是有很大正面收益的。当然也和风险并存,IPBE说到底最初是管理员权限之一,IPBE变成默认持有可能会对日后查核锁定破坏者留下隐患。但如果申请流程本身已经极大简化,考虑这个问题意义也不太大了,所以我给一个保守的支持,不知社区整体态度如何。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年1月3日 (一) 06:30 (UTC)[回复]
元维基的m:NOP全域方针本身禁止了在全域范围内随意使用代理的这种行为。到底要不要给中维开这个特例,让其豁免于全域方针,或是直接修改NOP全域方针,都应该不仅仅是由中维社群得出结论;如果中维开了这个先例,那土耳其,伊朗相关语言维基要不要这么做?中文其他维基项目要不要这么做?元维基和维基共享资源要不要因为有中文维基用户参与,所以也取消代理使用限制?因此这种类似“把ipblock-exempt直接添加到user用户组”这种请求可能会被直接拒绝,而且这个提议无论从各个方面上来讲也都是很令人疑惑的。--Yichen Ding留言|主账户) 2022年1月3日 (一) 14:02 (UTC)[回复]
你说的没错,但是见人就给的授权方式本质上和“把ipblock-exempt直接添加到user用户组”没什么区别,又和现行成文的方针矛盾,令我(作为方针的执行者)十分困惑。--Tiger留言) 2022年1月3日 (一) 14:37 (UTC)[回复]
LIPE的大量分发是无奈的情况,建议参考en,非带权限的用户可以分发短期得临时授权,时编辑强度情况来再申请时延长,逐渐为长期;有权限的可以提高初始值。不过有些地区的,过度依赖LIPE的就有点惊弓之鸟了。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月4日 (二) 09:37 (UTC)[回复]
当前实践已经是直接对所有使用代理者授予不限期的权限,同时六个月无编辑后除权的规则仍适用。--Tiger留言) 2022年1月4日 (二) 20:37 (UTC)[回复]
我早前已直接把自己的TG ID添加至相關頁面,當積壓過久的話,可以讓申請者直接通過TG聯繫到我。--AT 2022年1月5日 (三) 07:51 (UTC)[回复]
能在QQ那边也给一个快速处理渠道么?--三万光年 GBAW 2022年1月5日 (三) 14:15 (UTC)[回复]
那您要看看有誰願意去開通這個渠道囉。--AT 2022年1月5日 (三) 16:54 (UTC)[回复]
@AT:不知关联到tg的wikipedia-zh-help群组的QQ群组是否可以作为这个渠道。亦或者是否可以由大陆用户帮助注册账号并代替其申请ipbe?--三万光年 GBAW 2022年1月7日 (五) 02:12 (UTC)[回复]
我覺得把郵箱公諸如世不是好事,始終是個人資料。後者我更傾向由管理員處理,始終個人郵箱不宜隨便給陌生人,管理員至少會保密,一般用戶卻無法排除洩漏風險。--AT 2022年1月7日 (五) 06:16 (UTC)[回复]
那就没办法了,乖乖等rfa呗(耸肩--三万光年 GBAW 2022年1月7日 (五) 09:25 (UTC)[回复]
如果给所有用户IPBE那么为什么还要封禁代理。改为被封禁的开放代理IP也可以注册帐号只是不能编辑,需要在讨论页用unblock模板,并且设立“IPBE授予员”或“IPBE授予者”用户组可以授予他人IPBE权限?桐生ここ[讨论] 2022年1月5日 (三) 13:50 (UTC)[回复]
初步支持给新用户授予ipblock-exempt的想法,但需不需要保持六个月无编辑就除权?如果保持这个规定,是不是可以用户注册时自动加入IP豁免用户组? ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月5日 (三) 15:54 (UTC)[回复]
不太同意自动授予,相当于所有用户豁免用户查核。而且对于破坏者的IP封禁将不起作用。现在的流程还可以检查来自哪里,是因为代理被封禁{{Blocked proxy}}还是破坏者{{Range block}}。桐生ここ[讨论] 2022年1月5日 (三) 16:14 (UTC)[回复]
  • 通过站内申请,可以根据用户贡献判断是否可信。
  • 通过邮件申请,可以判断申请者邮件地址是否临时邮箱,根据封禁ID判断是Blocked proxy还是Range block,根据IP判断是家庭网络还是服务器,根据这些内容判断陈述是否可信。
    比如一个中国大陆需要IPBE的用户,应该是被Blocked proxy,IP是服务器;如果是Range block,而且被封禁的IP是家庭网络,称其在中国大陆被封禁代理就值得怀疑。甚至是最近被封禁LTA的一个IP地址(不是IP段而且还是家庭网络),可以直接拒绝,但可以建议对方更换网络环境以免误伤。
桐生ここ[讨论] 2022年1月5日 (三) 16:38 (UTC)[回复]
我无论身在哪里都可以开proxy,都可以装作来自中国大陆啊。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:16 (UTC)[回复]
实际处理的过程中,我也经常对一些申请人有这个怀疑,然而没法去求证,也就都给权限了。--Tiger留言) 2022年1月6日 (四) 14:41 (UTC)[回复]
用户查核还可以看UA ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:21 (UTC)[回复]
复述。参考en的做法,说明合理就可以给一个临时的,非职权的时间较短(可以参考为6个月),之后如果编辑强度足够可以提高阈值,有职权起初阈值可以大些。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月6日 (四) 01:12 (UTC)[回复]
我觉得还有建立帐号的问题。如果不经过unblock-zh,要怎么给中国大陆用户注册帐号?反正我现在登录状态下都注册不了帐号。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:27 (UTC)[回复]
我觉得,动大的(比如自动授予、新设用户组等)都需要共识;然而目前应该优先讨论的是三天之后,避免IPBE授予积压的紧急方案。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:27 (UTC)[回复]
要讨论紧急方案的话,恐怕要把所有管理员都ping过来,目前似乎只有两位管理员参与了本节讨论。--Steven Sun留言) 2022年1月7日 (五) 07:36 (UTC)[回复]
Xiplus刚刚处理了七则请求,看起来这部分应该还是有管理员接手的。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 09:53 (UTC)[回复]
實際上是44則。--Xiplus#Talk 2022年1月7日 (五) 12:29 (UTC)[回复]
目前技术上能否做到允许通过代理注册账户并编辑自己的讨论页?--Steven Sun留言) 2022年1月6日 (四) 06:45 (UTC)[回复]
“允许通过代理注册账户”不行,这样 IP block 就没有意义了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 11:34 (UTC)[回复]
支持建立后自動封禁以方便管理員儉省一層功夫--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月6日 (四) 13:33 (UTC)[回复]
还有个不知技术上是否可行的想法:将“授予IPBE权限”的权限下放,分拆Unblock-zh,允许非管理员参与到授予IPBE权限的工作上来。因为目前本地缺少用户查核,管理员似乎也没有什么特殊的渠道去了解申请者是否可信。--Steven Sun留言) 2022年1月6日 (四) 13:47 (UTC)[回复]
即“IPBE授予员”。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 04:28 (UTC)[回复]
我反而觉得通过Unblock-zh处理IPBE等申请,可能存在个人隐私问题,甚至怀疑可能与m:Access to nonpublic personal data policy存在冲突--百無一用是書生 () 2022年1月12日 (三) 02:30 (UTC)[回复]
郵件列表不受隱私政策保護,自然沒有違反Access to nonpublic personal data policy的問題。--Xiplus#Talk 2022年1月13日 (四) 14:03 (UTC)[回复]
郵件列表目前的處理方式是基於雙方互相信任,申請人信任管理員不會洩漏郵件內容,管理員信任申請人提供的資料真實無誤。如果想要保護申請人的隱私,目前想到2個辦法: 1. 使用VRT郵件列表,VRT成員必須簽NDA,優點除此之外還有方便管理郵件,標記未處理/已處理、合併多張工單、回應內容模板等等模板都是目前郵件列表無法做到的;缺點就是中國大陸的管理員就無法參與了。 2. 落實WP:CUP#3處理方式,優點有全面在站內處理、申請者不用再提供隱私資料、管理員也不用擔心提供的資料是否可能偽造;缺點就是大大增加CU處理量,需要等待CU程序。--Xiplus#Talk 2022年1月13日 (四) 14:18 (UTC)[回复]
魔琴這連結是哪時候的新功能-- Sunny00217  2022年1月15日 (六) 09:10 (UTC)[回复]
@Sunny00217Google introducing a feature in Chrome 90 to create links to highlighted text on a webpage. 其实我还写麻烦了,写成这样就行了,可惜不支持字词转换。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月15日 (六) 11:09 (UTC)[回复]

提请解任管理员User:Iokseng[编辑]

User:Iokseng通常只处理移动请求,这点我佩服他的坚持,其他管理员关注这方面的很少。但是,常年来我发现这位管理员在处理移动请求时有些按自身意向、喜好随意行事。而且面对质疑也不会解释说明,这对于普通用户来说没什么,对于有特殊权限的管理员不合适,故提请解任。--7留言) 2022年1月3日 (一) 06:22 (UTC)[回复]

請移步Wikipedia:管理員解任投票 紺野夢人 肺炎退散 2022年1月3日 (一) 07:24 (UTC)[回复]
既然都能丟出連結了,要不要先看看Wikipedia:管理員解任投票#发起解任投票第一行寫了些什麼?--Xiplus#Talk 2022年1月3日 (一) 07:45 (UTC)[回复]
有沒有例子?--Dotaoffice 邀請您加入邊緣人小組 2022年1月3日 (一) 12:37 (UTC)[回复]
(▲)同上,希望能给出具体例子。--Yichen Ding留言|主账户) 2022年1月3日 (一) 13:48 (UTC)[回复]
看當事雙方最近的貢獻應該就能明白了。—— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 00:13 (UTC)[回复]
同意解任,管理員在任何決策都必須保持中立,我很清楚他對移動請求有不中立的立場,實在不適任。 2022年1月5日 (三) 07:33 (UTC)[回复]
@Iokseng 。我希望管理員作出一個合理的解釋讓我們得知一個更加全面的情況。Dotaoffice 邀請您加入邊緣人小組 2022年1月5日 (三) 13:40 (UTC)[回复]
@Dotaoffice:就是拉法耶特侯爵的移動請求。我說明一下我對於名稱沒有偏好,如果覺得我的處理不適當,都可以與我溝通。至於更多的面向,此討論串大概都有提到,在此就不重複了。--Iokseng留言) 2022年1月6日 (四) 00:10 (UTC)[回复]
以一件事解任,並不合適。且這裡說似乎沒有用處。--老衲留言) 2022年1月5日 (三) 13:42 (UTC)[回复]

只有在沟通无效的情况下才可以发起取消管理员权限的投票。
取消管理员权限的投票內容必需詳細,指出管理濫權的原因,並根據編輯記錄及用戶貢獻提出相關證據,如內容不符或原因不合理,可視作申請無效。

桐生ここ[讨论] 2022年1月5日 (三) 13:48 (UTC)[回复]
这是Jarodalien对管理员的骚扰 施压:关于该移动,Jarodalien自己就说过“请社群和管理员判断”,管理员做出的判断与他的要求不符,就在这对管理施压?--LarseKun留言) 2022年1月6日 (四) 10:02 (UTC)[回复]
@LarseKun:所以你需要請求管理員處理Jarodalien的如此情形嗎?Sanmosa Immortal 2022年1月7日 (五) 04:02 (UTC)[回复]
@Sanmosa:也不明确这算不算对管理员骚扰。--LarseKun留言) 2022年1月7日 (五) 09:51 (UTC)[回复]
@Sanmosa:别的管理介入等一等。我想请问下:你觉得搜索引擎搜索结果和专业的文献相比,哪个更适合作为维基参考来源。--LarseKun留言) 2022年1月8日 (六) 05:46 (UTC)[回复]
依照Wikipedia:管理員解任投票,需要「等待討論共識」,不知大家的意見如何,我認為目前的說明還不足以解任管理員--Wolfch (留言) 2022年1月6日 (四) 10:08 (UTC)[回复]
我覺得不至於解任。—— Eric Liu 創造は生命(留言留名學生會 2022年1月6日 (四) 11:36 (UTC)[回复]
假如提請人沒法寫出「詳細投票內容,指出管理濫權的原因,並根據編輯記錄及用戶貢獻提出相關證據」,建議關閉。--Ghren🐦🕗 2022年1月6日 (四) 12:11 (UTC)[回复]
我覺得他無非就是在清除異己,這點讓我想起了WMCUG。Sanmosa Immortal 2022年1月7日 (五) 04:02 (UTC)[回复]
由于提请人未能提出相关证据,建议关闭。桐生ここ[讨论] 2022年1月7日 (五) 11:06 (UTC)[回复]
(-)反对提早关闭,建议尽快达成沟通无效,启动联署的共识。--Liuxinyu970226留言) 2022年1月11日 (二) 06:29 (UTC)[回复]
我不是提請人,但是我能提出證據:時雨羽衣的非法移動。根據命名常規的先到先得規則,如果存在符合名從主人慣例的名稱,並於至少一處中文使用地區為常用名稱時,條目標題應當使用該名稱,而先到先得規則不起作用。然而,時雨羽衣的官方頻道顯示的名稱為繁體中文,並至少於臺灣等地區使用,該管理員卻無視規定恣意移動。此外,根據地區詞處理指引(當時指引地位未被確認,但是仍可起參考作用),當一個機構或人物已經有官方的漢字或中文名稱時,臨時解決方案為條目名稱遵從名從主人原則。題外話,之前該管理員也有幾起移動爭議,但是被解任的機率也不大,就不浪費力氣了,只是希望提出證據能起警告作用,畢竟管理員的行為不能太過放肆。 2022年1月7日 (五) 15:27 (UTC)[回复]
@Pseudo Classes:你這是典型誤解方針的情形,名從主人不限制條目名稱是用繁體或簡體,他這樣做是在回退繁簡破壞,是遵守並執行方針的情形。Sanmosa Immortal 2022年1月7日 (五) 15:50 (UTC)[回复]
您才誤解吧,哪裡說明名從主人不限制條目名稱是用繁體或簡體? 2022年1月7日 (五) 15:59 (UTC)[回复]
這點你大可以問其他(與事件無關的)管理員,我認為我的理解無誤。--Sanmosa Immortal 2022年1月7日 (五) 16:01 (UTC)[回复]
我直接引用方針的說明,怎會有誤解的情形?方針從沒寫到不限制條目名稱是用繁體或簡體,那就不應該恣意延伸解讀,一切皆以方針所述為主。 2022年1月7日 (五) 16:01 (UTC)[回复]
我可以告訴你十個管理有十一個都會這樣處理。--Ghren🐦🕛 2022年1月7日 (五) 16:19 (UTC)[回复]
見下。 2022年1月7日 (五) 16:39 (UTC)[回复]
我认为100个监管员至少99.99999...个都不同意这种处理方式--Liuxinyu970226留言) 2022年1月11日 (二) 06:29 (UTC)[回复]
我們可不是維基文庫啊。名從主人原則如果限制繁簡那會是很恐怖的;總不可能把所有中國古代人事物移動到繁體名稱吧。反過來說,命名常規亦無規定中文名稱之繁簡也要名從主人,法無禁止即可為。—— Eric Liu 創造は生命(留言留名學生會 2022年1月7日 (五) 16:08 (UTC)[回复]
法無禁止,但是有共識:討論存檔。舉個例子,如果將中西區 (台灣)移動至中西區 (臺灣)屬於繁簡破壞,但是將東山區 (台南市)移動至東山區 (臺南市)則不屬於繁簡破壞,因為臺灣是主權有爭議的地名,而臺南市是屬於中華民國的行政區域,即臺南市的主權為中華民國,如果今天要建立屬於中國的行政區域,則可能另建立東山區 (台南市)的條目。簡而言之,名從主人具有尊重主人選字的條件,這是共識,並不是自行延伸解讀。您可以查看我的移動日誌,您就能明白我一直關注名從主人的領域。 2022年1月7日 (五) 16:38 (UTC)[回复]
台與臺之問題屬於特殊情形,還牽涉異體字與顯示問題,不可一概而論。—— Eric Liu 創造は生命(留言留名學生會 2022年1月7日 (五) 18:10 (UTC)[回复]
@Ericliu1912:請不要混淆視聽,該共識包括但不限於台臺異體字,這裡只是用來引出共識,沒有一概而論。更何況地區詞處理指引也有提到,當一個機構或人物已經有官方的漢字或中文名稱時,臨時解決方案為條目名稱遵從名從主人原則。 2022年1月14日 (五) 11:25 (UTC)[回复]
我不認為有什麼共識就是。該等情形應當屬於例外。另外地區詞和單純繁簡是兩回事。—— Eric Liu 創造は生命(留言留名學生會 2022年1月14日 (五) 14:20 (UTC)[回复]
你反對我的意見,當然會認為當時沒有共識,真是令人遺憾。此外,該共識不存在例外不例外的適用時機,也不僅限定台臺異體字,請不要混淆視聽。最後,地區詞和繁簡轉換確實不同,為避免混淆視聽,已對留言逕行刪除。然而,唯一不會改變的是當時的共識,除非你另起討論將其推翻,謝謝。 2022年1月14日 (五) 23:01 (UTC)[回复]
那是您自己的看法,頂多也只能算是一個特定範圍內的共識。對我來說,該討論完全集中在臺台問題,要用此框架下得出的一些討論結果放大套用於全站,實在不能說是妥當。這並不符合現實,也顯然不應該得到執行,否則將破壞本站多數條目的基礎,AT跟我所提到的只是其中一小部分而已。考慮到命名常規名從主人原則一段一字未提繁簡,再考慮到其前後文字內容、延伸指引內容,我認為該方針所說的名從主人完全只有地區詞上的名從主人,而其繁簡只要顯示上相同,便無差別。臺台問題之所以需要另外討論,便是因為顯示起來不同,且為異體字,不單純適用一般命名常規。—— Eric Liu 創造は生命(留言留名學生會 2022年1月15日 (六) 02:33 (UTC)[回复]
你認為,不代表方針如此,結果真是令人遺憾。然而,就算不論方針,該管理員在有反對意見的情況下,未經溝通協調,貿然移動頁面,很明顯就是濫權,更何況是有爭議的移動和不明確的方針下執行。 2022年1月15日 (六) 06:30 (UTC)[回复]
關於對方針與指引的看法,我原句奉還閣下。我同意Iokseng閣下有時候行事上不一定完全正確,但他顯然不是不能溝通,故我認為不至於解任。—— Eric Liu 創造は生命(留言留名學生會 2022年1月15日 (六) 19:46 (UTC)[回复]

應維持條目第一個重要版本所採用的標題

條目建立時是使用「时雨羽衣」

另外,

以下為「名從主人」原則僅起參考作用的情況:
1.人物:其所工作或隸屬的機構、組織、公司的中文資料中出現他的中文姓名或譯名的,「名從主人」原則僅起參考作用

--0906(回復請Ping我) 2022年1月7日 (五) 16:39 (UTC)[回复]
參考仍有作用,而先到先得則是直接不適用,請看清楚,謝謝。 2022年1月7日 (五) 16:41 (UTC)[回复]
这次移动似乎是依据讨论申请来执行,不过的确存在没有检查适用的规则,而且在讨论有反对的情况,就照常执行。的确需要注意到其中的问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月8日 (六) 03:42 (UTC)[回复]
上上次提请人发起的移动,也存在反对但是通过了,提请人倒是没来提请接任。最近的几次移动,提请人的申请没过,就来客栈提请解任了。--LarseKun留言) 2022年1月8日 (六) 05:46 (UTC)[回复]
@AT:可能要勞煩行政員解釋一下了。究竟我和Pseudo Classes的解讀哪個才是正確的?--Sanmosa Immortal 2022年1月9日 (日) 02:11 (UTC)[回复]
我用例子來回應。請問中國相關條目在中國使用簡體之前是否都應該以繁體來命名,反之亦是如此?港台則只能用繁體來命名嗎?--AT 2022年1月9日 (日) 04:43 (UTC)[回复]
@空氣小貓(順便給個例子:老隆福建會館)。Sanmosa Immortal 2022年1月9日 (日) 07:13 (UTC)[回复]
用字模式差异导致先到先得,似乎是基于创始初期就出现过抢位问题来避免这个问题(例如同一个事物的名称的不同用字模式,繁体抢简体或者反之),其中的核心就是认为只因用字模式差异不影响命名差异。现在的规则没有明确这个,但基于早期情况,似乎是这样去解读。——Sakamotosan路过围观 | 避免做作,免敬 2022年1月10日 (一) 01:27 (UTC)[回复]
@Sanmosa:同上,但是恣意錯誤解讀沒有訂定的規則絕對不被允許,更不用說執行方面。 2022年1月14日 (五) 11:28 (UTC)[回复]
(=)中立。--夏雪若留言) 2022年1月9日 (日) 12:33 (UTC)[回复]
  • 我不太同意Pseudo Classes君关于台南市的那段论断。東山區 (台南市)属于标题繁简混用。内地地铁车站条目也有很多全繁体命名的,按Pseudo的说法把他们移动到简体也不是繁简破坏了。Itcfangye留言) 2022年1月15日 (六) 10:51 (UTC)[回复]

条目同文堂及相关的警告模板[编辑]

同文堂于2018年9月29日被移动到新同文堂,后于维基百科:页面存废讨论/记录/2021/12/01中删除。由于此条目链接被用于繁简破坏相关的警告模板,有大量用户讨论页因此出现一个红色链接。最近一次该条目因G5删除时,Seele2021提出应当清理这些红链。我认为红色链接多少会有人去点,点了以后看到删除讯息确实不太合适,可能容易误解。另外,该软件仅为自动繁简转换软件的一个示例,没有链接也不是太大的问题,因此提出从警告讯息和方针指引页面中移除至此条目的链接。至于是否移除大量已发出的警告讯息中的链接,由于涉及修改既有留言,留待各位讨论。若决定移除,则可由机器人一次性处理完。

备注:含有该链接的方针、指引和警告讯息页面:

其他含该链接的页面各位可自行查询该页的链入。 --Tiger留言) 2022年1月8日 (六) 17:49 (UTC)[回复]

(+)支持 至少现在模板里的先移除,让新的警告模板没有红链,以往的留言是否修改还可以再讨论。如果几个小时内没有反对意见我就先行移除。桐生ここ[讨论] 2022年1月9日 (日) 02:08 (UTC)[回复]
假如這是一個維基百科用者常用的工具,是否能能移至專案便查閱?--Ghren🐦🕑 2022年1月9日 (日) 18:13 (UTC)
(▲)同上--夏雪若留言) 2022年1月11日 (二) 13:28 (UTC)[回复]
@Tigerzeng:如何?—— Eric Liu 創造は生命(留言留名學生會 2022年1月20日 (四) 04:25 (UTC)[回复]
什么如何,关于是否修改已存在链接,好像完全没有新的意见吧。--Tiger留言) 2022年1月20日 (四) 15:05 (UTC)[回复]

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

IPBE權限能否考慮下放?[编辑]

有用戶User:Zorua Fox在QQ群反應最近ipbe沒人受理,而據我所知似乎這一業務都是user:Tigerzeng一人在處理,所以有必要把這個權限拆分出來。--中文維基百科20021024留言) 2022年1月11日 (二) 01:53 (UTC)[回复]

经搜索发现完全没有收到此人的邮件,可能是被邮件列表的反垃圾功能拦截了。另外最近Xiplus也有在帮忙处理。--Tiger留言) 2022年1月11日 (二) 02:26 (UTC)[回复]
現在權限發放已經很寬鬆了,下放發放權限恐怕只會讓情況更加寬鬆。—— Eric Liu 創造は生命(留言留名學生會 2022年1月11日 (二) 02:30 (UTC)[回复]
@Ericliu1912:特殊情況要特殊處理,考慮到中國大陸的狀況,更加寬鬆未必不行。--中文維基百科20021024留言) 2022年1月11日 (二) 03:18 (UTC)[回复]
那管理員全部預設批准不就好了,設那麼多規定做什麼。這樣流程也會快很多。—— Eric Liu 創造は生命(留言留名學生會 2022年1月11日 (二) 03:25 (UTC)[回复]
可以啊,只要他們願意。--中文維基百科20021024留言) 2022年1月11日 (二) 03:27 (UTC)[回复]
这不就上面那个讨论串在说的事么。--Tiger留言) 2022年1月11日 (二) 05:19 (UTC)[回复]
(▲)同上--夏雪若留言) 2022年1月11日 (二) 13:25 (UTC)[回复]
這樣做有沒有任何弊處?—— Eric Liu 創造は生命(留言留名學生會 2022年1月11日 (二) 14:05 (UTC)[回复]
覺得有弊端就直接提出來。--中文維基百科20021024留言) 2022年1月11日 (二) 14:07 (UTC)[回复]
这么长时间基本上没啥门槛的授权下来,感觉还行,有影响也不至于太大。详细的在上面的讨论串里有说。--Tiger留言) 2022年1月12日 (三) 01:46 (UTC)[回复]
所以預設或下放權限其實沒太大問題?--中文維基百科20021024留言) 2022年1月12日 (三) 03:02 (UTC)[回复]
我还不敢给这样的结论。毕竟我自己也不算是抓傀儡很熟练的人。只是凭感觉来讲,“明明很像的两个账号,CU结果却是不相关”(也就是因为被允许使用代理而成功利用代理逃避CU的情况)的情况似乎相比多年以前并没有明显变多。--Tiger留言) 2022年1月12日 (三) 03:46 (UTC)[回复]
其實讓對方把帶有賬號名稱以及禁止編輯的提示截圖發過來就好了。--中文維基百科20021024留言) 2022年1月12日 (三) 03:51 (UTC)[回复]
现在邮件申请的话就是这样的呀。只是因为邮件列表收图片不是很方便,所以让直接把封禁信息文字复制粘贴到邮件里。--Tiger留言) 2022年1月12日 (三) 04:21 (UTC)[回复]
所以其實是不難的雜活,讓更多願意參與的人處理是好事。--中文維基百科20021024留言) 2022年1月12日 (三) 04:25 (UTC)[回复]
而且就算是VPN,那麼CU結果也會有提示,到時候可以用一望而知來封禁。--中文維基百科20021024留言) 2022年1月12日 (三) 03:53 (UTC)[回复]
看了一下讨论串,发现到目前为止,申请IPBE的方法似乎已经由“编辑unblock模板+邮件申请”转为单一的“邮件申请”,之所以Tigerzeng没有找到邮件是因为我使用的是前一种方法。作为普通编辑者,目前来讲我只了解WMF的事件,并不甚了解这个事件之后对Unblock模板和申请IPBE流程的影响。若现阶段只能通过电邮方式解封,那么是否可以重新考虑Template:Unblock模板的实际作用并在模板文档中加以告知(例如添加:“该模板不再适用于申请IPBE”的字段),以及关于QQ群“维基百科(2018)”群文件“如何解决无法编辑中文维基百科问题_修正版.pdf”的方法指引问题。-- Zorua 欢迎指教嗷! 2022年1月12日 (三) 18:30 (UTC)[回复]
OA2021对申请流程没有影响,现在依然可以用unblock模板和邮件两种方式申请。邮件申请的数量比较大,我个人主要是关注邮件申请,站内讨论页unblock模板关注的管理员更多一些,我关心得少。以上是目前的情况。unblock模板申请有几个问题,一是没有账号的人没有自己的讨论页,所以连账号都没有的人基本上只能用邮件。二是在讨论页上公开封禁信息(含IP地址)之类的细节,多少有点涉及隐私之类的问题,不太合适,邮件基本上不用担心这方面(当然了,有的管理员索性就不要求提供封禁信息)。--Tiger留言) 2022年1月12日 (三) 18:37 (UTC)[回复]
但现在还有一个问题是那个unblock已经在我的讨论页挂了6天了,还没有任何动静,以及在我讨论页那个模板点击“此用户”会出现英文字母乱码(也有可能是我的编辑问题),总之目前unblock模板由于种种原因貌似处理速度已不如前-- Zorua 欢迎指教嗷! 2022年1月12日 (三) 18:43 (UTC)[回复]
你那个有结构式讨论页的因素,这种方式它甚至不会出现在封禁申诉的分类里面,也就难以引起注意。我等下帮你调整一下,但是我不会批准你的申请,因为按现行的方针你没能证明需要得到权限的必要性,而且你最近也正常编辑。--Tiger留言) 2022年1月12日 (三) 20:46 (UTC)[回复]
(...) 吐槽 真用傀儡的话我到也没必要QQ群说一遍来这再说一遍了
以及那个Unblock模板,貌似是没啥用了(至少对于ipbe来说)-- Zorua 欢迎指教嗷! 2022年1月12日 (三) 18:37 (UTC)[回复]
經常有人以申訴模板來要求IPBE權限,雖然我覺得這不是申訴模板本身應有的作用,不過實際上對於看不懂相關說明的用戶來說,確實是挺直接,而且有效。--AT 2022年1月15日 (六) 11:43 (UTC)[回复]
我倒是認為封鎖申訴模板就是拿來申訴封鎖的,而IP封鎖自然也包含在內。—— Eric Liu 創造は生命(留言留名學生會 2022年1月15日 (六) 19:48 (UTC)[回复]
根據方針,申請IPBE是解封請求的一部份。桐生ここ[讨论] 2022年1月18日 (二) 19:16 (UTC)[回复]
我在想,如果CU回到中维的话,是否可以完成对授予IPBE条件的统一,对新申请的用户进行查核以确认其IP是否被封禁,也可以对已有权限用户进行一次大范围查核以确认当前是否仍需要此权限。--东风留言) 2022年1月18日 (二) 01:35 (UTC)[回复]
方針板討論擴展HAM至SPI用途的討論中有子案正在討論設快速用戶查核請求通道供WP:CUP#1-3,WP:CUP#3正是對應此案用途,故想請各位關注該討論。--路西法人 2022年1月18日 (二) 03:44 (UTC)[回复]
  • (-)強烈反对預設下放,現在門檻基本上已經跟沒有一樣了,預設下放將會使技術性規避CU易如反掌。任何預設下放的討論都至少應該等到本地資料恢復有熟悉本地破壞者風格的CU員(而不是監管員)進行CU才應繼續-某人 2022年1月18日 (二) 18:25 (UTC)[回复]
  • 本地CU员恐怕会难产,不如设立IPBE授予员,而且授予者关注获得IPBE者的编辑一段时间。桐生ここ[讨论] 2022年1月18日 (二) 19:24 (UTC)[回复]

一月十五日至一月十六日屏東維基編輯工作坊[编辑]

如主旨,1/15-16 將於屏東進行線下的維基百科編輯教學活動。 編輯條目主要為高雄市、屏東縣境內村里,如學員有觸犯編輯規則請海涵,會在編輯活動結束後五天盡可能排除問題,如有漏網之魚再煩請通知,非常感謝。 相關編輯紀錄可參閱活動編輯紀錄。 --Allenwang6212a留言) 2022年1月14日 (五) 11:19 (UTC)[回复]

閱,感謝告知。WP:VPD#关于可能的利用维基百科进行教育训练及其条目是否可能存在问题中的是你們的社團嗎。--Ghren🐦🕑 2022年1月15日 (六) 18:14 (UTC)[回复]

千村狐免疑为基金会行动的罪魁祸首[编辑]

笑話一則。不要給LTA關注度。--路西法人 2022年1月19日 (三) 03:49 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

这边(在伪基冲浪无意发现的)有证据表明,破坏者中的哈密瓜油、玛丽莲梦、Tongtonggood,本次GB的游魂、Walter Grassroot(正好是回退员,可以查看过滤器)为其真人傀儡。--680XtalkX签名白い雪が街に 优しく积もるように 2022年1月18日 (二) 13:37 (UTC)[回复]

旧闻。桐生ここ[讨论] 2022年1月18日 (二) 17:25 (UTC)[回复]
Old new is so exciting。而且LTA的話一個字都不要信。--Ghren🐦🕑 2022年1月18日 (二) 18:17 (UTC)[回复]
这都2022年了,还有人信LTA的任何一句话吗……too young too naive--三万光年 GBAW 2022年1月19日 (三) 00:17 (UTC)[回复]

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

拉票相關問題[编辑]

如果ping先前參與GA投票的編輯再次參與投票算不算拉票? --Loving You Is A Losing Game 2022年1月21日 (五) 03:36 (UTC)[回复]

如果被ping的人於之前的GA投票中僅投票而沒有就條目內容作出討論的話,個人認為算拉票(因為這是WP:JUSTAVOTE,是連討論都算不上,繼而不符合WP:APPNOTE所指的「曾經參與先前相同主題(或緊密相關主題)討論的編輯」,當然如果有更多理據證明符合APPNOTE者則可以除外)。而如果被ping的人全部都在之前的GA都是投支持票的,則有可能干犯「在討論中拉攏少部分你認為將全部支持你的立場者,也是不適當的」。--街燈電箱150號 開箱維修 2022年1月21日 (五) 12:14 (UTC)[回复]