关于此版块

既往讨论已于2021年03月27日存档至User talk:Lt2818/存檔

希望您可以评估我编写的工具

3
Diskdance (讨论贡献)

您好,为了更好地帮助新人确认自己能否编辑维基百科,以及帮助老维基人确定又有哪些维基媒体项目被墙,我制作了维基媒体服务器连通性面板工具(Wikimedia Server Connectivity Dashboard),地址位于wscd.toolforge.org,源代码仓库位于github.com/diskdance/wscd,欢迎您试用并留下您宝贵的意见!谢谢。

Lt2818 (讨论贡献)

挺不错的。

Diskdance (讨论贡献)

好的,非常感谢您的支持!如果您觉得这个工具有任何问题以及可以改进的地方的话,还请您提出,非常希望听到您的意见!

回复“希望您可以评估我编写的工具”

顺便再介绍一下我的“上海官员补全计划”

1
不慎言行非法师魔女 (讨论贡献)

主旨是为尚无独立条目的上海的行政、司法、立法等分支首脑补全独立条目,详情可参考我的个人用户页,目前已完成第一个该计划的条目冈崎胜男,该条目同时还在申报DYK,欢迎进行质量检阅及评审,以便于我在该计划此后阶段进行改进!

回复“顺便再介绍一下我的“上海官员补全计划””
不慎言行非法师魔女 (讨论贡献)

可否给我一只吴维ip封禁豁免?我最近在搞上海官员补全计划,也想去吴维写一写

Lt2818 (讨论贡献)

完成

回复“侬好!”
SunAfterRain (讨论贡献)
Lt2818 (讨论贡献)

2017文本編輯器應該能完成目標功能吧,只是提示語還要改。相比之下視覺化編輯器似乎完成不了提交審核的功能。該改動在默認的「記住上次編輯器」設置下是能把視覺化編輯器禁用的。

Lt2818 (讨论贡献)

原先的veswitched=0是更好的做法,被您這筆編輯去掉了。

SunAfterRain (讨论贡献)

原來如此,當初拿掉的原因其實是不了解這個參數 囧rz……,感謝提醒。

回复“打擾”

邀请您评估我新编写的HanAssist小工具!

40
Diskdance (讨论贡献)

您好,请问您有时间评估一下我新编写的HanAssist小工具吗?希望它可以给站内小工具的编写带来便利。

介绍位于Diskdance/public/HanAssist。GitHub仓库在此

谢谢。

Lt2818 (讨论贡献)

好的,我看一下,晚些回复。

Lt2818 (讨论贡献)

先回报两个错误:

  1. 消息为null或undefined时不会报错。
  2. 类型错误的报错信息为无效参数“candidates”,应为“Candidates”,这不是预期吧。
Lt2818 (讨论贡献)

有些设计过于复杂了。

  1. “类型检查”我认为没有必要。对于不同变体,转换字符串以外的类型在合理范围内,不必限定在字符串类型。
  2. 原先的wgULS和wgUVS优点在语法简短,实际代码最常用的形式为wgU*S(hans, hant)。废除这两个函数需大费周章,我觉得可把参数限定在前两个,作为HanAssist的语法糖。
  3. 个人认为"en"夹在其中挺怪,已经超出变体转换范畴了。
Lt2818 (讨论贡献)

HanAssist.parse的设计挺好,但感觉使用语法要比现行的wgULS简洁才有吸引力,像消息名: [简体, 繁体]这样子(多数代码用不到地区变体)。{hans: 简体, hant: 繁体}还要比wgULS(简体, 繁体)多打几个字。

Diskdance (讨论贡献)

收到,谢谢反馈。我稍后回复。

Diskdance (讨论贡献)

您好,首先非常感谢您抽空评估我的小工具,感激不尽。

关于报错:

  1. “消息为null或undefined时不会报错。”这点我无论是测试HanAssist.localize( null )还是HanAssist.localize( { hans: null } )都是会报错的。这是预期行为,不知道您指的是?
  2. “类型错误的报错信息为无效参数“candidates”,应为“Candidates”,这不是预期吧。”是这样的,candidateslocalize()vary()的第一个参数的名称,而Candidates是一个TypeScript类型,在代码里面写得很清楚。不过如果大家都觉得很迷惑的话,我可以考虑修改成别的。

关于复杂的设计:

  1. “‘类型检查’我认为没有必要。”首先,我认为wgU*S的初衷就是专做转换字符串用途的,只不过它目前的写法导致可以各种类型通用,而我不认为混用类型是一个好的习惯,因为这样会带来非常多的问题。再者,我搜遍全站的小工具,发现有且仅有这一处传入的不是字符串,且此处可以很方便地用HanAssist.parse()替换掉。因此,我认为有必要仅支持转换字符串。不知道您的看法如何?
  2. “原先的wgULS和wgUVS优点在语法简短”“像消息名: [简体, 繁体]这样子”我一向认为编写代码的时候没有必要过分考虑简短。我认为虽然{hans: 简体, hant: 繁体}wgULS(简体, 繁体)略多几个字,但带来的却是可读性的巨大提升——就算是完全不知道HanAssist的人也能凭借代码本身正确猜出它的用途,而wgULS则做不到这一点。其次,我认为API有变动的时候,有不适应的情况实属正常,但只要适应了,我相信HanAssist使用起来肯定比wgU*S更加直白明了,这也是我编写它的目的之一。然后,如果您是担心语法不简短之后带来性能问题的话,我认为大可不必。毕竟才多出几个字节,又能影响多少性能呢?况且MediaWiki会压缩代码,现代的浏览器传输都有gzip压缩。
  3. “个人认为"en"夹在其中挺怪,已经超出变体转换范畴了”我也认为是这样,但是考虑到本站存在这样的use case,我认为顺带着支持一个en也不是什么太大的问题。我在文档里也写得很明白,如果小工具需要多国语言支持,那么不推荐使用HanAssist。不知道您是什么看法呢?

写得比较多,希望您可以仔细看一下,谢谢!

Lt2818 (讨论贡献)

先回复报错的部分:

  1. HanAssist.localize({hans: null, hant: "abc"})
  2. 反正我在JS里没见到大写的Candidates类型,如果要翻出TS代码才能排错的话,不大方便。
Lt2818 (讨论贡献)
Lt2818 (讨论贡献)

性能无所谓,我是懒,加之长代码会变得很难看。print能解决问题就不用搞出什么System.out.println。MediaWiki:Gadget-fixlinkstyle.js#L-27的处理办法也挺简洁,可以换成HanAssist.parse看看会变成什么样。

Lt2818 (讨论贡献)

我是觉得中文维基百科没必要上英文。或者改成叫other之类的名称也好,提供一个非中文环境下的输出,此时消息不一定非要是英文。

Diskdance (讨论贡献)

HanAssist.localize({hans: null, hant: "abc"})根据现有的代码,只要能根据fallback chain找到正确的message就不会抛出异常,所以我认为此代码按照预期运行。之前版本的代码有非常严格的检查,但我认为累赘,最后删掉了。况且我认为应该没人会故意写这样的代码吧。

根据您的建议,过会儿我稍微改改代码,等改好了再通知您。

Lt2818 (讨论贡献)

HanAssist.localize({hans: 123, hant: "abc"})会报错,如果这是预期的话,那么是个奇怪的特性。

“没人会故意写这样的代码吧”:变量忘记赋值就是undefined,也会有把函数返回值null拿过来直接用的情况,无须故意。

Diskdance (讨论贡献)

因为根据代码逻辑,{hans: null, hant: "abc"}{hant: "abc"}是等同的。而{hans: 123, hant: "abc"}在内部会选择到123,然后判断123非字符串从而报错。

“变量忘记赋值就是undefined”是啊,但是根据目前全站wgULS的用法来看,localize的第一个参数大家都会用literal赋值,为什么会存在undefined的情况呢?按照这个道理,也不可能存在“把函数返回值null拿过来直接用的情况”。希望您能理解。

Lt2818 (讨论贡献)

我知道代码内部是这么跑的,但既然承诺了“类型检查”,为何把null和整数区别对待,看起来比较怪。

不应限定用户怎么用函数,我觉得把变量、函数返回值作为HanAssist的参数是很正常的事情。

Lt2818 (讨论贡献)

再多说几句,这里用抛出异常来检查类型不是很好。维基百科的JS接口时有变化,即使编写代码时保证某函数返回字符串,今后也可能返回null或其他东西;此时脚本核心功能或许仍可用,但若抛出异常则整个脚本将失效。如果是编译内核之类的场景,严格一些是好事,在网站上则可用性比较重要;XHTML为前车之鉴,其严苛的错误处理适得其反。

Diskdance (讨论贡献)

“……在网站上则可用性比较重要”这点我恐怕不能同意。JavaScript的动态类型是非常好,但是在大型的应用程序中我们并不需要这样的动态类型,因为它反而会带来更多问题。这也就是为什么会有TypeScript,它可不是失败品。HanAssist特地使用TypeScript编写,这样其他小工具就能得益于TypeScript的静态类型检查功能,在编写时就能发现潜在的错误。

“今后也可能返回null或其他东西”在写这个小工具的时候,我特地查看了一下全站小工具调用wgULS的方法,结果是,目前绝大多数代码都是直接用类似wgULS("hans", "hant")的方法调用,所以根本不可能返回null或者其他东西。“维基百科的JS接口时有变化”,是,但是我相信其他API的设计者不可能在重大变更时不做好充分的通知、不给足充分的时间供用户迁移。

Diskdance (讨论贡献)

垃圾进,垃圾出。我认为API的使用者有义务知道API的正确用法,如果他们以错误的用法调用API,也就不应该指望API会输出什么正确的结果。再者,我认为与其返回一个不正常的结果,直接报错中止程序运行是更好的选择,这样可以避免错误蔓延开来,导致更大的破坏。不知道您的看法是什么呢?

Lt2818 (讨论贡献)
Diskdance (讨论贡献)

这个问题与本话题无关,要不到我的讨论页上聊?

Lt2818 (讨论贡献)

可以啊,我现在没更多要说的。在哪展开讨论都行。

Lt2818 (讨论贡献)

“直接报错中止程序运行是更好的选择”:理念没错,但不适用于该场景。上面给的这个链接讲得比较详细了,XHTML就失败在这里。

非字符串参数也不是错误的用法呀,先前不限定类型毫无问题。我觉得函数把参数原原本本返回更好(现在不是这样),如此则一句wgULS(true, false)轻松分开繁简环境。动态与静态类型的语言各有优势,也有各自的写法;动态类型更灵活一些,像上述用例就不用开个新函数来实现了。

Diskdance (讨论贡献)

如果可以这样用的话,请问wgULS这个函数的作用是什么?是根据wgUserLanguage选择合适的用户界面消息,还是仅仅作为一个通用的选择器?编写这个函数的人从来没有讲明白,使用者也没有用明白。而我在写localize和vary的时候就写得很明白,这两个函数是专门为了转换用户界面消息而设立的,如果有别的需求,请去使用别的函数。

另外wgULS(true, false)无法正常工作,实测繁体环境下也是true……

Lt2818 (讨论贡献)

如果wgULS只有两个参数的话,其实看一眼就懂了,非常明白。倒是你的函数还要去搞懂啥是hans和hant。

“无法正常工作”确实如此,我上面也括注了“现在不是这样”。

Diskdance (讨论贡献)

嗯?hans和hant不是也是一眼就能看出来一个是简体中文,另一个是繁体中文?为什么凭直觉会判断不出来 囧rz……

反倒是我举的例子,wgULS( undefined, undefined, '显示%s的用户日志', '顯示%s的使用者日誌', '顯示%s的用戶日誌' );,恐怕这个理解起来更有难度吧。

Lt2818 (讨论贡献)

多于两个参数确实理解起来有难度。但使用率最高的还是两个参数,实际代码里看一眼就知道一个简体一个繁体,照猫画虎都不用翻文档。hans和hant的含义却非不言自明。

Diskdance (讨论贡献)

嗯,让我们来设想一下,

HanAssist.localize( { hans: '一天一苹果,医生远离我。', hant: '一天一蘋果,醫生遠離我。' } );

当一个不了解HanAssist但有JavaScript知识和编程经验的人看到之后,他的反应依次是:

  1. Han => 说明和中文(汉语)有关;
  2. Assist => 说明与Helper相关,可能是个工具函数;
  3. localize => 和本地化有关;
  4. 第一个参数传入一个object,且值都是string,再根据小工具上下文 => 此函数的作用是本地化中文消息;
  5. hans => 自然联想到zh-hans,即简体中文,推断为简体中文的消息;
  6. hant => 同上,推断为繁体中文消息。

这样推断下来,我不认为有什么障碍啊。代码中已经给足了提示信息。反观wgULS

wgULS( '一天一苹果,医生远离我。', '一天一蘋果,醫生遠離我。' );

  1. wgULS => 不知道什么意思。
  2. 参数为两个string => 不知道用途是什么。
  3. 好像一个是简体一个是繁体,结合上下文 => 可能是在两者之间选择一个消息?
  4. 找文档 => 找不到。
  5. 硬着头皮直接看实现 => wgUserLanguage是什么东西?用户语言?
  6. 再翻MediaWiki文档 => 终于搞懂了。

我想我解释得很清楚了。

魔琴 (讨论贡献)

我作为一个js-0使用者讲讲我第一次看到wgULS的想法,前提是我已经知道JavaScript需要处理繁简,然后我看到源代码发现所有需要汉字信息的地方都有wgULS( '一天一苹果,医生远离我。', '一天一蘋果,醫生遠離我。' );,就大概能猜到这玩意是处理繁简的了,而且很明显前简后繁。而且这种应该是函数参数的写法也很好记。当然wgULS这个名字到现在还没背下来 囧rz……(这也是为什么我希望HanAssist.localize.vary要改成.interface.variant)至于“第一个参数传入一个object,且值都是string”,“找文档”,“看实现”,“MediaWiki文档”,这些就是我不懂的东西了。

Diskdance (讨论贡献)

嗯,了解。但是interface有一个问题:它还有一个很常用的意思是“接口”,怎么保证他人不会误解函数的意思?

“第一个参数传入一个object,且值都是string”指的就是{ hans: '一天一苹果,医生远离我。', hant: '一天一蘋果,醫生遠離我。' }这里。您可以讲讲您第一次看到这个的看法,哈哈。

Lt2818 (讨论贡献)

我可不认为Han和zh-hans是人人都知道的东西……

HanAssist和wgU*S都好。即使从兼容性角度考虑,保留wgU*S也没坏处。

Diskdance (讨论贡献)
Lt2818 (讨论贡献)

我的想法写在了User:Lt2818/vector.js,改动如下:

  1. 公开可用的有四个函数:localize、vary、原先的wgULS和wgUVS(保留前两个参数作为语法糖)。parse用例少且语法复杂于wgULS,砍掉了。原先的wgUXS在MediaWiki命名空间未被使用,也砍掉了。
  2. 消息不限类型,原样返回,唯有undefined视为消息不存在。
  3. localize不接受第二项参数,与vary统一。文档中localize第二项参数的样例输入zh-hans与第一项中的格式hans形式有别,会造成困扰。若目的只为兼容wgUXS,相信没有必要,毕竟wgUXS未被使用。
  4. 原先调用HanAssist.localize("abc")HanAssist.vary("abc")不会报错,改掉了这个怪异行为。

现在的代码只是原型,如果您觉得这些思路可行的话,就能继续打磨。

Diskdance (讨论贡献)

嗯。不过我应经说过了,我认为wgULS和wgUVS这两个函数的命名令人费解,无法表达其作用,所以我编写HanAssist的目的就是deprecate这两个函数并取而代之。您也应该注意到了,HanAssist会自动shim掉wgU*S为自己的实现。

另外还是得重复一句,不能因为字数少就认为简洁,关键要考虑代码在语义上是否明确。就比如说wgULS虽然字数少,但是它的函数原型实在是让人难以理解,具体我上面解释过了。

还有,我认为用户既然都在编写本站的小工具了,势必要和用户界面打交道。因此,对本站的字词转换系统也应该要有必要的了解。所以zh-hans之类的,就算不是人人都知道,作为一个小工具编写者也应该要知道吧。

然后我过会儿会做一个failsafe的版本出来,到时候您可以看看。

Diskdance (讨论贡献)

如果您实在不满意的话,HanAssist在开发中曾经支持过这样的语法:

HanAssist.localize( [ '一天一苹果,医生远离我。', '一天一蘋果,醫生遠離我。' ] );

不知道您对此意见如何?

Lt2818 (讨论贡献)

除了MediaWiki命名空间,用户空间脚本还有几百条要替换。因为和先前产品不兼容而失败的产品太多,可以看看IA-64

HanAssist.localize([a, b])反而增加了接口的复杂度。

我觉得你的理由说服不了其他人把print换成System.out.println。不妨提案看看更多人的反应,我可以不作评论。

Diskdance (讨论贡献)

好的,谢谢您的理解。

第一条我已经考虑过了,可以让HanAssist长期shim wgU*S(几年时间吧),在调用旧函数的时候在控制台显示deprecate warning,例如:

Use of "wgULS" is deprecated. Use HanAssist.localize instead.

“我觉得你的理由说服不了其他人把print换成System.out.println”嗯,我没搞错的话,类似的事情早就有先例。例如把wg***改为mw.config.get('wg***'),不是成功了吗?

Diskdance (讨论贡献)
Lt2818 (讨论贡献)

当然,系统不支持了你不换都不行。

Lt2818 (讨论贡献)

感觉有些时候抛出异常是合理的,比如一个参数都没有的时候。现在也行。但HanAssist.localize("abc")还是别原样返回比较好。

Diskdance (讨论贡献)
回复“邀请您评估我新编写的HanAssist小工具!”
Ericliu1912 (讨论贡献)

請在移動話題的時候加入移動模板,謝謝。

Sanmosa (讨论贡献)

你要是想重開AFD討論的話,拜托別做一半不做一半,不然其他人會很為難。

Lt2818 (讨论贡献)

寫重開討論的理由要花些時間。

回复“(無題)”

模版删除标准讨论(续)

2
Bluedeck (讨论贡献)

你好,我今天再看您在客栈提出的模版删除讨论,发现已经存档。因此您的留言我在这里回复一下。

“請問是哪個重要模板經過存廢討論被刪除了?“

当时,WP:AR项目开始运行没多久(此前,这个项目是一个通过用户讨论页实施的非正式项目),和很多项目页面一样,使用大量subst模版,有一天这些模版全被提删了,理由是0连入无用。这才使我想起来修改当时的删除准则。WP:AR目前经过几次改版,我不确定能找到当时的存废了,也是没下功夫找,但是这件事肯定是有的。[1]

倒是您應當說明2017年修訂是否有實際上的正面影響。“

其实这不太合理,如果这个方针导致哪个模版没有被删,甚至没有被提删,那我也不会收到一条短信通知,告诉我方针产生了正面影响。相反,我可以合理的推测,您想修改此方针,必定是受到了一定的负面影响。您不妨把您个人具体受到了哪些不便说一下,这样我们才能有意义的讨论。

您的發言我只感覺到opinionated,繼續解釋或許意義不大。

绝非本意。

回复的晚,见谅!

[1]: 如果您实在想找,可以试试去2017年10月7日开始往前翻VFD,看有没有T:AR开头的记录。

Lt2818 (讨论贡献)
  1. 我往前翻了一个月存废讨论没找到T:AR开头的记录,但看到一个Wikipedia:頁面存廢討論/記錄/2019/06/01#Template:ARNP。修改方针的起因当然看过。我的话是回应此前维基人“凭常识”判断错误导致重要模版被删除一句,它不符我的认知,需要举证
  2. “您想修改此方针,必定是受到了一定的负面影响”:并非如此,可以看到两次讨论都不是我发起的,只是认同他人修改的理据,调整下措辞罢了。据我观察,2017年修订没有实际影响,该提删的模板照样提删,我对这种情况是满意的。
回复“模版删除标准讨论(续)”
SunAfterRain (讨论贡献)

我的觀點是他強烈執著於基準時間不對,刻意強調「基準時間」必須於開始投票之時,即「惡意使用維基百科方針和指引,阻礙維基百科目標實現的行為」(copy from WP:GAME),同時追求一定要和自己認為的方針(觀點)一模一樣而去(闡釋)開啟這種討論(擾亂)。以上為本人判定為GAME+POINT的原因。

Lt2818 (讨论贡献)

「惡意使用維基百科方針和指引」和「阻礙維基百科目標實現」我都沒看出來。WP:POINT寫明「通過討論達成共識,而不是單方面行動」,陳白腸君的做法是前者。

回复“re VPO edit”
Renamed user xyBW847toYwJSYpc (讨论贡献)

部分用户口口声声说不要相信伪基百科上的破坏者说的话,拿来指责MCC214。 又知道QCHM、HMGY等人长期有欺骗和演戏倾向,于是宁可相信所谓的编辑倾向,而不相信技术数据。自WMC到虫虫飞到此从无一丝改变。

如果虫虫飞滥用傀儡是核实的,经过一系列的“绑架社群”就可以居高位,我不难理解部分破坏者为何至今为止仍难以对付了。

Lt2818 (讨论贡献)

从虫虫飞案就能看出,中维社群的问题并不只在单一个人或用户组。他人的问题我无能为力,只能做好自己的事,毕竟维基百科比社群伟大。对于是非不分的人,说难听点,尔曹身与名俱灭,不废江河万古流。

Renamed user xyBW847toYwJSYpc (讨论贡献)

今晚发生了一些事情,很是不舒服,我这更理解在ccf事件后阁下的体验了。谢谢您!

回复“真是遗憾”