维基百科:互助客栈/条目探讨/存档/2022年8月
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
长号条目内容疑似错误
关于{{lang-sr}}
学术期刊/学报 标题
人 (消歧义)的编辑争议
香港电影条目内容被大规模删除
关于图片描述拍摄时间的问题
请求合并Rupe重排反应和Meyer-Schuster重排反应
阿兹海默症论文涉嫌造假
轨距命名
请香港维基人协助查阅条目内容是否侵权
乌克兰语译音表
请问艺人爱好者内容的清理范围?
关于声生不息收视率的探讨
关于Infobox China County模板的问题
关于人格障碍的内容
瑞典及丹麦市镇条目名
条目四角矮菱的显示问题
打算创建维基百科:条目质量提升计划的新计划
Template:Thblink的外部链接
请问Template:Thblink可以使用外部链接吗?他是THBWIKI。--Sim Chi Yun(留言) 2022年7月23日 (六) 13:58 (UTC)
- 不好说。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月2日 (二) 05:25 (UTC)
匈牙利人物命名规范
古希腊字母条目标题无法正常显示
跨年份(度)的体育赛季条目命名
对动词条目进行了一定程度的扩充,希望各位检查是否有不当之处
一些小行星的音译名
寮国主席诺哈·冯沙万的出生地
T:金庸人物中的血缘/家庭一栏的适用范围
请求关注宏达国际电子条目
优良条目审查应否参考过往成功审查的纪录?
新闻动态错得离谱
有关基础条目, 性 (生物学) 的扩充
论“效忠”
漫画章节列表是否应该收录并作为独立条目?
“XXXX年X月某地”条目是否应该收录
东正教相关
关于{{第二次国共内战}}
建议将卡缅卡第聂伯罗夫斯卡亚改名聂伯河畔卡梅扬卡
是否应该保留早期机翻译名
早期有用户批量创建了大量的意大利市镇条目(以及其他国家的地名条目),应该是根据译音表用程序生成译名(所谓的机翻译名)。但该机翻有一个典型的错误,就是有时音节划分错误(@Bigbullfrog1996:分析过)。这些意大利市镇的关注度不高,但十多年来有一些维基镜像网站、旅游旅店等据维基内容自动生成的网站也会使用这些译名(Google搜索也就是几千个结果,最相关结果才几十个)。当根据权威辞典或标准调整译名后,有管理权限的编辑一般都会移动后不留重定向(即所谓的“红移”),可是像我这样一般的编辑移动后就会留下重定向。当我用d|R3的理由申请快速删除(如最近的@Peacearth:皮亚恩泰多、耶拉戈科诺拉戈、基耶萨伊恩瓦尔马伦科、蒙特乌贝卡里亚),有的管理员会接受,有的却认为有必要保留这些重定向。个人觉得没有必要保留这些重定向。一为那些镜像和自动网站以后慢慢从维基拷贝新的译名,二是在Google及维基上用这些错误翻译的名字来搜寻的话,大概率还是能找到正确的条目,三是如果在维基上保留这些重定向的话反而会给其他网站或搜索引擎认为维基确认了该错误译名。不知其他人的看法如何?--万水千山(留言) 2022年7月28日 (四) 08:01 (UTC)
- 首先,感谢您为此开启讨论,希望这个讨论能让社群对于此类重定向之处置形成共识。
- 个人是认为此类错误译名有助于读者进行搜寻,且维基百科本就存在类似像Category:错字重定向这种虽然错误但有助读者搜寻的重定向页面(虽然误译可能不能算是“错字”,但同样是错误名称的重定向,性质类似),因此个人比照办理而保留之。
- 关于第一点,该类镜像网站要拷贝的话也会从新的名称去找而非重定向,所以保留应不致造成问题,何况维基百科应该是不需要主动配合、考虑他们的。
- 关于第二点,个人目前存疑。如果单纯错字可能还有较大机会找到正确条目,但如果像是音节划分错误那种用字有显然差异者,不一定能那么好找,还可能会造成红连甚至日后重复建立的情形。
- 关于第三点,或可对此类误译重定向采类似{{错字重定向}}的模板标示之(唯目前似未有相关模板,可能需另行建立)。
- 以上拙见供参。-Peacearth(留言) 2022年7月28日 (四) 10:46 (UTC)
- (!)意见 可以把待移的或是已蓝移的攒起来然后告诉我,我统一进行消灭。--Bigbullfrog1996(𓆏) 2022年7月28日 (四) 21:34 (UTC)
- 前提是如何确定这是用户机翻?而不是的确有这么翻译的可靠来源?或者可靠来源就是机翻的,维基百科不过是使用了这个可靠来源的译法?--百無一用是書生 (☎) 2022年7月29日 (五) 03:46 (UTC)
- 我所碰到的这些机翻地名是由Tianyamm2和Trymybestwikipedia两个用户创建的。他们在短时间批量创建了大批地名,应该是机翻译名,而没有去找任何来源。我在整理这些地名时,先在线确认该译名在《世界地名翻译大辞典》是否相同或收录,没有收录的话再根据译音标准或类似地名才来确定是否移动。如果没有强烈或确定理由的话我也不会去移动。移动后我也再评估一下新的重定向是否该保留,比如Monte在标准中一般译为“蒙特”,而机翻则译为“蒙泰”,这种情况下我也会选择保留重定向。不过对于这些首先从维基散发出去的这些“错误”译名,个人觉得没有必要在维基中保留重定向,应该让这些译名慢慢在网上消失。如果在维基中保留重定向的话,可能会强化这些译名在网上的地位。退一步来说,即使现在在维基中删除了这样的译名,但如果将来有人有充足的理由的话还是可以重新建立的。--万水千山(留言) 2022年7月29日 (五) 08:02 (UTC)
- 前提是如何确定这是用户机翻?而不是的确有这么翻译的可靠来源?或者可靠来源就是机翻的,维基百科不过是使用了这个可靠来源的译法?--百無一用是書生 (☎) 2022年7月29日 (五) 03:46 (UTC)
- 不管是否保留,是否可以把这些需要移动的做个备份,也方便后来者查看或者恢复?--Kethyga(留言) 2022年7月30日 (六) 03:16 (UTC)
- 我之前都是移动过后再把链入页面修改至新的条目名,然后申请快速删除。有的申请通过了,有的申请被拒绝,但没有保留为一个列表。现在整理没有精力去手动整理了。也许以后的条目可以保留为列表备份。有能力经验的管理员可以搜索在“Category:意大利各大区市镇”之下的条目的没有链入页面的重定向而整理出一个列表,然后再去分析是否有必要保留这些没有链入的重定向。--万水千山(留言) 2022年7月30日 (六) 11:43 (UTC)
- (○)倾向保留。如果是两年前展开此讨论的话,那我大概率会强烈支持机翻译名全部红移。但是在近几年的编辑过程中,我越来越感觉到中文译名仅仅是一个标注符号,而并不需要是最贴合原名的中文译写,所以只要不是把A翻成B,比如把“Paris”翻译成“北京”这种,其它什么“帕里”、“派瑞斯”、“法国首都”、“卢泰西亚”乃至各类机翻名称作为重定向的我都可以接受。除此之外,以下为倾向保留机翻译名的两点实际理由:
- 如何确定某些商业网站使用的机翻名称是单纯“来自维基机翻条目”,而不是“作者采用了与维基机翻相同的方法而得到的译名”?比如Louveciennes,按照“机翻标准”所产生的译名为“卢韦谢纳”,事实上,该地对应的中文条目由人工创建,该机翻译名也从未在中文维基中留下过痕迹,但“卢韦谢纳”依然在维基之外的新华社报道中出现。
- “卢韦谢纳”是新华社自拟的,因为Tianyamm根本就没有批量机翻伊夫林省市镇,而且谷歌地图上是“路维希恩”,这是早年间被人用绿链输出到谷歌地图上的。再者根据Tianyamm调试的垃圾机翻规则,Louveciennes会生成“卢韦谢内”而非“卢韦谢纳”。--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 17:54 (UTC)
- 我压根没提到“路维希恩”。并且,您的回答依然无法回答“如何确定某些商业网站使用的机翻名称是单纯“来自维基机翻条目”,而不是“作者采用了与维基机翻相同的方法而得到的译名”?”。--Patriotard 2022年7月30日 (六) 18:10 (UTC)
- 简单的概率问题,对于超过三个字以上的译名的地名,如果自拟译名恰巧完全符合某规则,那概率是非常低的(排除Alatata这种简单的且画风正常译字可供选择少的例子,我想大部分人不论有没有译音经验都会译成“阿拉塔塔”,只有少部分人会译个“阿腊塔塔”、“阿拉达达”之类的),反正我见过伪装译音表译名伪装得最像的传统译名是“布里夫拉盖亚尔德”,当年把您都忽悠住了。更何况要仿的还不是译音表,而是天涯妹妹的调试错误的反常的译音规则?而且就算是其他商业网站使用自己译名规则的机翻名称,基本上不会有天涯妹妹的译名这么奇怪,比如XXXbœuf译成“XXX博厄”,“quillaxxx”译成“屈伊拉xxx”之类的,有天涯妹妹味的铁定是搬的维基机翻,一查一个准。最后,要做的单纯就是干掉维基里的机翻误译,关其他商业网站用什么样的机翻什么事?--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 19:22 (UTC)
- 首先,概率再低,只要不是零,那就无法排除。本人五年前毫无经验翻译的“欧别”就神奇地与工具书不谋而合(倒是被阁下红移的时候反咬了一口)。此外,“采用了与维基机翻相同的方法而得到的译名”的可能性依然存在,比如谷歌地图上的“克勒斯河畔阿让通”,这个名字仅在2019年7月6日至9月7日间为该地的维基条目名,且未在wikidata中留有任何痕迹;而同一时期内与该地相邻且已得到更正的Le Menoux、Badecon-le-Pin、Mosnay则均未被谷歌收录。在此名不是工具书名称的情况下,如何判断该名称是否出自维基?--Patriotard 2022年7月30日 (六) 20:33 (UTC)
- 关于“欧别”,我之前是看过您整的一堆其他的“别”,看到这个“欧别”想当然以为又是您整的狠活(当然这确实是您自己独立整出来的狠活,只不过恰好工具书也整烂活了,帮您挡了一枪。此外,工具书上还有一些其他的“别”,还有像“阿尔夏克”的“夏”这样的不合理连译,所有这些我也一同都更正了,对此也不存在分歧),这我承认是我的锅。说来也巧,您刚才在忙“莱米罗”,我想起了相同结构的“莱叙利斯”,去年我红移圣地亚哥的“于利斯”并鞭尸了一番,您不还是同样想当然以为是我喷的您然后还去我留言板给我警告了一番?(当然了,您可以解释说“啊,我当时其实知道你喷的是圣地亚哥,我这其实是为圣地亚哥路见不平拔刀相助啊”,格局一下子就上来了)同样说来也巧,在您举“克勒斯河畔阿让通”的例子之前,我想您应该回忆一下您扩写过的“格雷”以及在条目里说的以“Gray”命名的相邻市镇“Arc-lès-Gray”亦被《世界地名翻译大辞典》译为“'阿尔克莱格赖”这句话,事实上书籍也干过不少转正了某传统译名却又把含该传统译名的另一地名给纯按译音表翻译了的事例。在您说“此名不是工具书名称的情况下”这句话的时候,您最好真的查证一下此名是不是非工具书名称。--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 22:59 (UTC)
- 我确实是刚才疏忽了,因为在翻PDF大辞典的时候看到“Aubiet”和“Ambierles”时误以为“Argenton”也检查过,这个是我的失误。不过我不明白您提“于利斯”和此处的讨论有什么关联,此处我提到“Aubiet”可没有任何警告您的意味,只不过认为您当时在没有得到考证的情况下就口吐芬芳的做法确实有待商榷,并且,您在确认了“欧别”有工具书做参考的情况下也丝毫没有要改回去的意思,连红链都得不到重建,所以同样是工具书小地方译名,阁下的采用标准究竟如何?难以捉摸。话说回来,Argenton-sur-Creuse不行,那我换举个例子,里昂旁边的“Vénissieux”按照机翻大概率会是“韦尼西厄”,不过这个译名从未在维基中出现,但是却被外网文献收录;附近另一个市镇“Villeurbanne”严格按照译音表译为“维勒尔巴讷”,这个译名在工具书和维基内亦都从未出现,却同样被媒体记录;在加上前面“欧别”这个例子,不正好都说明了不同的翻译渠道亦可出现相同的“误译名称”吗?--Patriotard 2022年7月31日 (日) 00:18 (UTC)
- “欧别”红移后发现其为工具书译名但未再重建回去这一点确实是我的失误,我已经补回去了。一般情况下红移后发现维基误译同时也是书籍译名时,我都会补建重定向(建的太多了我记不清了具体例子了,但最典型的是一些经视频确认后末尾s发音的“XXXs”但被机翻成“XXX”的市镇,有时翻一下工具书,发现该地的书籍译名也是“XXX”,我都会把“XXX”的重定向补回去)。至于“Vénissieux”,要是让天涯妹妹机翻确实是会被翻成“韦尼西厄”,但是您要知道,天涯妹妹把“-ieu”译“-厄”是按人名译音表译的,要是他没给末尾“ieu”设置规则,“Vénissieux”妥妥会被译成“韦尼谢于”,看看词中间的“ieu”未设置规则的情况下天涯妹妹造的垃圾吧(所以话说回来,是天涯妹妹本意就是想用人名译音表翻译地名吗?不是,他把“Argonne”、“Neuville”、“sur-Vingeanne”都设置好规则了,翻译出来的都是地名译音表的“阿戈讷地区”、“讷维尔”、“万雅讷河畔”,所以他整的这些人名译音表的幺蛾子纯是因为他缺心眼,或者糊涂蛋一个,因此我才把他整的这些用了人名译音表译字的问题译名都定义为误译)。而且,当前40年历史《大辞典》系列丛书的直系始祖——商务印书馆1983年的《外国地名译名手册》,之前还有一本名字相同但内容已被大换血(所以我并不认为其为今《大辞典》系列丛书的直系始祖,只有1983年版的才是一脉相承)的工具书——商务印书馆1978年的《世界地名译名手册》,在这本书里便有之前讨论的Revel,其译为“雷维尔”,还有其他一些例子:Mézières译为“梅齐埃尔”、Auxerre译为“奥塞尔”、Epinal译为“埃皮纳尔”……这里不难看出,其译字等同或接近如今的人名译音表。而“Vénissieux”也正好在里面,其正是被译作“维尼西厄”(与“韦尼西厄”稍有出入)。即便那人不是看的1978版《世界地名译名手册》,但如果那人平时常接触一些法语人名译名,比如“马蒂厄”之类的就很知名,那他自己能拟出个“韦尼西厄”也完全不是难事。我想您应该晓得为什么有时看到的那么多民译私译地名的用字这么偏人名译音表了,因为不是老资料的散发余温就是受法语人名的影响。所以不是说天涯妹妹没设置好机翻规则然后翻出个“韦尼西厄”,然后那人也随便翻就能翻出个“韦尼西厄”,而是说两个人都用人名用字翻地名,那么二人都翻译出“韦尼西厄”就是大概率事件了。他要是能造出个“韦尼谢于”,那我才真的服。至于“维勒尔巴讷”就更好说了,中国那么大14亿人,肯定有我的同道中人呗。比如Ouisteham,我惊喜的发现,早在2015年就有人将其按实际发音更正至“维斯特雷阿姆”了,那还是个除了书籍误译“乌伊斯特勒昂”就是机翻“乌伊斯特雷昂”的蛮荒时代,而我独立更正至“维斯特雷阿姆”则已经是2019年2月27日的事儿了。在2008年,各书籍资料已经刊录“圣莫代福塞”的情况下,Hennessy还是独立创建了一个书籍资料味儿非常浓的“圣莫尔-德福塞”(仅说此次以及其他多数时候,不代表Hennessy的每一个译名都是完全完美的“书籍味儿译字译名”,但他还是比斯诺里和圣地亚哥甚至天涯妹妹本体不知道强到哪里去了)。所以说,有人真要能独立于工具书造出个“维勒尔巴讷”那完全没有意外。最后再强调一下,我一直以来意思和目标都很明确,我的目标就是打击谷歌地图上的维基污染,谷歌地图译名是不是维基误译我能很精确地判断,至于其他网站上爱怎么野译自拟随他的便,我又没建“百家号误译模板”、“野论坛误译模板”等各种模板,它再怎么跟维基机翻误译巧合关我P事,我能确定谷歌地图译名是维基误译就足矣了。--Bigbullfrog1996(𓆏) 2022年7月31日 (日) 02:56 (UTC)
- 首先,判断是否是维基误译需要有确凿的证据,比如外网某处有明确标注“内容来自维基”之类描述。单纯的“我能很精确地判断”依旧有原创研究的嫌疑。其次,我不认为需要将维基译名和其它译名进行区分对待,译名众多是很正常的事,尤其当某地华人关注度高但又缺乏强势传统译名(如巴黎、马赛)时,如Aubervilliers,这种情况下非要去批判或者消灭那些异类译名显得毫无必要;而即使是按照维基“先到先得”的标准,十多年前出现的天涯妹妹译名也理应保留。假设Vénissieux一开始真的是机翻“韦尼西厄”条目,请问阁下会红移吗?“维勒尔巴讷”和“科尔马尔”、“加莱”、“XX勒沙托”一样,都属于未使用通名的译名。天涯妹妹亦使用符合人/地译音表的“圣昂德雷”、“圣若尔热”、“阿利耶河畔XX”,还曾神奇地把“奥约纳克斯”移到与工具书统一的“瓦约纳克斯”身上,这些译法也是“我的同道中人”?总而言之,我不认为因翻译标准不同而产生的译名属于“污染”,只要能查证,被使用,那就有存在的价值。法国前十大城市的译名只有两个符合译音表(南特和尼斯),而天涯妹妹属于译名当然也是历史的一部分。至于这些译名出自何处,以及如何减少非主流译名带来的影响,这些似乎不像是需要在维基内深入讨论内容。--Patriotard 2022年7月31日 (日) 11:12 (UTC)
- 我只是判断谷歌地图上的是不是抓的维基误译,谷歌地图上抓的是不是维基误译地球人都能判断出来,有什么问题吗?除了天涯妹妹杰作,我对其它出现在非微博及论坛性质的网站、书籍、报刊等上的译名都能有足够的包容性(实在是太狗屎的除外),欧贝维利耶条目里我可一个没剔。还有,还要告诉您个事,这些机翻误译天涯妹妹是知情的,他造了一堆赛博狗屎他自己是知道的,且他自己也红移了一部分(其实是他自己主动请求删除的,应该是他没有红移权限只能蓝移。为了方便表述,以下对天涯妹妹蓝移后再请求删除也称之为红移。从这里能看出来,天涯妹妹对这些误译内心是想红移不留的),只不过他可能对自己的法语译音水平没信心(因为很多西班牙、德国地名机翻误译他是移了的),或者说他是条懒狗(因为即便是别的不好判断,但一些音节简单的“XXXque”这样的不难吧,至于留着一堆“XXX屈埃”?),于是把大部分误译法国地名都摆着发烂发臭了。我做的不过是把他偷的懒用我自己的汗水补偿了,如上所述,天涯妹妹本人都不想留,还给他留个锤子?“假设Vénissieux一开始真的是机翻“韦尼西厄”条目,请问阁下会红移吗?”,当然移啊,我只负责把天涯妹妹的机翻误译,有可能的话再核对一下书籍(防止之前提到的误杀“XXXs”),其它网站及个人用什么野译不关我事。这么说吧,德语地名里的“-berg”根据书籍是要通译作“贝格”的,但是真要译成“贝尔格”倒也不违背译音表,“贝格”和“贝尔格”的差别相比“雪”和“西厄”的差别岂不是小很多?早期天涯妹妹机翻德国地名没设置好规则,都是清一色“XXX贝尔格”,后来他把大部分都红移成“XXX贝格”了。可跟“韦尼西厄”一样,是不是也有可能有零星几个“XXX贝尔格”早在2012年之前存在于个别网站及资料中?这些“XXX贝尔格”不还是照样都红移了?您要是真闲的,那就劳烦发扬“发掘韦尼西厄、维勒尔巴讷精神”去把所有的“-ieu”挨个在互联网上核对一遍看看在2012年之前有没有对应的“XXX厄”译名使用,有就去建回重定向,别搁这儿绑架我。“圣昂德雷”、“圣若尔热”、“阿利耶河畔XX”……,还是如之前所说,这纯属天涯妹妹老糊涂或是缺心眼,不是他想另辟“维勒尔巴讷”的蹊径成心这么翻,瓦兹河谷省的“XXX-sur-Oise”市镇他都准确翻成“瓦兹河畔XXX”,阿列省的“XXX-sur-Allier”至于成心翻成“阿利耶河畔XXX”?约讷省的“XXX-sur-Yonne”市镇他能准确翻成“约讷河畔XXX”,但涅夫勒省的“XXX-sur-Yonne”市镇却翻成了“伊翁河畔XXX”,这不是缺心眼忘设置规则这能是什么?“圣昂德雷”、“圣若尔热”也是,纯纯忘设置规则罢了,因为另一个人名他就设置上规则了,没错,就是您的一生之敌——马( )。“还曾神奇地把“奥约纳克斯”移到与工具书统一的“瓦约纳克斯”身上”,不神奇,他偶尔也真身现身干点把机翻误译移到书籍译名的人事。“总而言之,我不认为因翻译标准不同而产生的译名属于“污染”,只要能查证,被使用,那就有存在的价值”,翻译标准不同起码得是“标准”,天涯妹妹的狗屎译音规则调教纯属他的错误酿成的灾难,不属于一种标准,连他自己都不觉得那是标准。“法国前十大城市的译名只有两个符合译音表(南特和尼斯)”,2019、2020年您莱赖雷隆龙博伯波不辨随手出错就算了,去年“说‘梅茨’符合译音表”、“地名里的人名用字不能用‘娜’”我也忍了,现在都2022年了还“南特和尼斯符合译音表”,我实在是不知道该说什么了,只能奉劝您再熟诵一下译音表,然后想想上塞纳省的省会叫什么。一张破表背四年,不至于。法国前十大城市,甚至乃至前二十大城市,大部分都是有传统译名的,它们都诞生在我之前,甚至是诞生在我父辈乃至祖父辈之前,这些我自然触动不了。但是2012年的且本身自带误译原罪的天涯妹妹狗屎机翻误译,我动的了,而且我动定了。如果您非要认为“诞生过了就是历史的一部分了”,那我原话奉还您,2018年诞生的Bigbullfrog1996也是历史的一部分,且他消灭天涯妹妹狗屎机翻误译这一事件也是历史的一部分。--Bigbullfrog1996(𓆏) 2022年8月2日 (二) 23:45 (UTC)
- 事到如今,我认为应该强调针对本讨论原始问题两个基本观点:第一,这里讨论的是机翻译名的重定向而不是修改条目名,本质上是讨论面对客观存在事物的解决方案,而不是去深究其来源,所以我还是倾向可查证译名一视同仁的原则;第二,维基机翻归根结底是死抠音译表和机械化找规律的结果,而不是具有特异性的“维基行为”,这种错误实际上任何不熟悉法语的人都有可能犯。像在这篇搜狐文章里,“Bourniquel”就被译成了维基模样的“布尔尼屈埃”,而“克勒斯河畔”这种出现在工具书里面的错误、上文提到的“韦尼西厄”、加上阁下曾经原创的圣迪耶德孚日、勒克勒索等,更是进一步证明了机械化翻译绝非维基百科的专利。“我对其它出现在非微博及论坛性质的网站、书籍、报刊等上的译名都能有足够的包容性”:所以您在沙托鲁#地名当中对“夏斗湖”的批判到底是在打谁的脸?“这些机翻误译天涯妹妹是知情的,他造了一堆赛博狗屎他自己是知道的”“本人都不想留,还给他留个锤子”,但是事实就是这些名称已经被中文网页大量收录,所以请参考本段前面提到的第一点。就算他现在重现维基并亲自批量红移添模板也是应该进行维基商议的。顺便提一下,阁下去年在讨论的时候亲口说过“我对我的输出毫不掩饰”,所以您对自己原创的孔夫朗-圣奥诺里娜当中敢加一句“本条目译名来自中文维基用户”吗,或者去狠狠地把法新社和大使馆批判一番?。“韦尼西厄”条目...当然移啊”:暂且不论“误译”这个混沌不堪的概念,您要是真红移了“韦尼西厄”,那您挂的“该名称为地图从Wikidata上抓取的中文维基早期机翻误译”模板就是妥妥的原创研究。贝格/贝尔格我不了解,但如果“贝格”是类似于“堡”这种典型通名的话,那我肯定是支持移动的,当然是否红移还得看目标是Strasbourg还是Thizy-les-Bourgs。“Martin马丹”可完全达不到鄙人“一生之敌”的高度,只不过我认为出自人名的地名用人名译名更为恰当,我也不打算红移任何“马丹”。这个译名在冥冥之中有一种被钦定的感觉,大概率有语感贴近的因素,就连我自己也曾“马丹”过,所以我或许也是您的同道中人。但是您觉得天涯妹妹设置“马丹”是因为查看了工具书吗?我看不像,就如同TA把“XX-les-Bois”设置成“森林XX”一样。另外,天涯妹妹并没有使用同一机器进行翻译,目测01省是试验,03到68省是BOT,81省以上是自助浏览器,另外02、08、59、62、80省出自Stevenliuyi之手,大概也是自助浏览器,总的来说后面的翻译明显好了不少,像带“约讷河畔”的市镇就在89省得到了纠正。“翻译标准不同起码得是“标准””:参考本段前面提到的第二点,机翻译名绝大部分是死抠音译表的结果,依旧是有规律可循,而不是放飞自我的天马行空,像本人早期在百度百科创作的某些词条一样。“法国前十大城市的译名只有两个符合译音表(南特和尼斯)”:这锅我背,我的本意是指“死抠音译表”而不去管别的导则内容,当然音译表里也是有“南(楠)”的,所以我又错了。“2012年的且本身自带误译原罪的天涯妹妹狗屎机翻误译,我动的了,而且我动定了”“2018年诞生的Bigbullfrog1996也是历史的一部分,且他消灭天涯妹妹狗屎机翻误译这一事件也是历史的一部分”:这差不多是我在维基讨论中见过阁下最牛X的语录了,和梅朗雄的“La République c'est moi”简直异曲同工,我还是劝您别老想着依靠绑架维基来改变客观世界。天涯妹妹原创的译名再“狗屎”,可它们就是被各大网站收录了,维基红链在可预期的未来里并不会削弱它们中文网络里的影响力;大辞典工具书“马丹”“于连”这么多年,到头来能找到的讯息屈指可数,还时不时被大使馆新华社环球网各种新闻轮番打脸。怎么办?要怪就怪您没有早十年进军维基,把天涯妹妹圣地亚哥Snorri全部干翻,这样绝对“方丹”“赛姆”一统天下;或者早一两个世纪在中国人接触法国的最开始就“帕里”“利永”“马尔萨耶”,把一切不符合标准音译表的译名全部扼杀在摇篮里。可惜呀,历史和现实都不能被假设,只能去尊重。--Patriotard 2022年8月3日 (三) 15:47 (UTC)
- 维基人User:Bigbullfrog1996在修正原法国机翻地名条目内往往添置有“误译”模板,但其对应的机翻误译名称却已被红移,这意味着读者不可能通过搜索机翻译名前往指定页面。既然机翻名称的重定向都已不存在,那么该系列模板还有何实际意义?--Patriotard 2022年7月30日 (六) 17:32 (UTC)
- @AirScott:少搁这儿借机作梗,意义在于告知多数不懂法语及法语地名翻译的读者为什么地图上的译名是错的以及维基机翻历史,起的就是让人摒弃掉误译译名的作用,与“消灭误译重定向”这一点正好相符。我早就说过,对于这种机翻的小地方,基本上所有人都是Google这个地方的外文名然后点击右侧Infobox进入维基百科对应条目,或者是点开谷歌地图到处浏览然后点击左下信息框维基百科对应条目,没有人是先进维基百科,然后再手动输入误译名进入条目。--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 17:54 (UTC)
- 维基百科当然首要考虑维基内部的搜索,而不是外网。“没有人是先进维基百科,然后再手动输入误译名进入条目”只不过是您自己的习惯,然而维基本身必须考虑这点。您要解释“为什么地图上的译名是错的”相当于您绑定了维基和中文谷歌地图,先不说此举是否可行,如果某天谷歌地图修复了各类中文译名,或者取消了维基链接,请问您会马上会删掉各类误译模板吗?--Patriotard 2022年7月30日 (六) 18:10 (UTC)
- 我巴不得谷歌地图早日修复这些破逼烂活,甚至说我得掏腰包几百欧谷歌他们才肯删我都愿意,真的,我不知道是当年是谷歌地图哪个卧龙凤雏产品经理一拍脑袋整出的提取维基百科条目名和Wikidata中文名用作谷歌地图中文名的法子,也不知道为什么2019年中旬谷歌地图方面大脑升级了,放弃了从维基提取中文名的人才行为,不知道是不是他们产品经理刷地图发现画风奇怪的地方不太对然后赶紧叫停了,但是后续他们也没有把原来抓取的那些译名清空。我已经尝试过不下几十次提交修改“博格斯”了,除了一堆“您就‘博格斯’提交的 Google 搜索反馈”的机器生成屁话邮件,卵信都没收到。我也给谷歌地图方面写过邮件(后来找到联系方式了),但不出意外的石沉大海。所以说等谷歌地图修复这些烂活,可能性比那谁主动下台还小。对于那些小地方,谷歌地图上的译名对大众来说可以说是最大影响因素,冷门书、野网站等与之对比都可以忽略不计。而谷歌地图上垃圾误译污染源正是维基百科,虽然是谷歌方面自作主张搞的抓维基译名,但垃圾误译是从维基对外输出的也是事实,所以对读者交代一下事情的缘由以及为什么地图上的是误译是有必要的。话说回来,要是哪天谷歌真修复了抓的维基译名(快点吧🙏🏻),删地图误译模板这事儿都不用您催。但至于取消了Infobox维基链接,之前我说过,误译提示模板是给愿主动进维基的人看到,不愿进维基的哪怕附上了维基链接他也不会进,所以取不取消维基链接与去留误译模板没影响。--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 19:22 (UTC)
- 首先您的回答还是没有考虑维基内部搜索的情况,若保留误译模板,至少得实现“手动输入误译名进入条目”,要不然就别挂,否则花大力气介绍一个已不存在的名称实在不值得。结合阁下前面的“单纯就是干掉维基里的机翻误译”,我已经说了,不符合音译表规则的机翻不等于误译,译音表及各种规则只适用于中文维基,外网如何使用是他们的事,但是中维没有理由去要求外网摈弃误译译名,也没有义务去给别的网站擦屁股。不管译名出自何处,只要能够查证,那就有收录建立重定向的意义。--Patriotard 2022年7月30日 (六) 20:33 (UTC)
- 关于内部搜索,我要的就是强化更正后的正确译名,弱化乃至消灭机翻误译,我追求的就是从条目名到wikidata层面再到读者认知层面的彻底毁灭误译名,我要的就是让已经进来的人知道原来那个译名为什么死了,而不是让人顺着那个本该死的译名进来然后发现“虽然它该万死,但却仍能苟活着”,“至少得实现“手动输入误译名进入条目”,要不然就别挂”无稽之谈。当然了,从谷歌地图层面的毁灭才是最彻底、最根本的,但如上所说,各种与谷歌互动的办法我都试过了,没用,所以我最终才不得以这样。还有,从根本上讲,我不是给别的网站擦屁股,而是给天涯妹妹擦屁股,并且把他酿成的海量恶果解释给读者。还有,不要觉得“维基是维基,其它网站是其它网站”,“两者一定是前者不能含后、老死不相往来”,维基和其它网站一直是存在联动的,比如维基里的网页archive用的就是互联网档案馆,YouTuber条目有链入了YouTube Channel的YouTuber的模板,wikidata里也有Google知识图谱ID、推特号等Properties,甚至在维基百科里的地图服务替换成OpenStreetMap之前便是用的Google Maps,所以有什么不能加的?同我之前所说,我也不是为一堆网站各建了一堆种类的模板,而是为了最大的影响——谷歌,只建了一种(当然细分了很多子类别),这就足矣。我又不是建的“百家号误译模板”、“野论坛误译模板”说“这个百家号文章用的这个译名“xxx”是误译”、“那个野论坛帖子用的那个译名“xxx”是野译”然后把条目开头塞满。最后,若您还是满脑子打转,言之必“手动输入误译名进入条目”,要不然就别挂”,那我很简单地一言以蔽之:我就是想让它们死,没那么多为什么,要不是托天涯妹妹的福,这些恶心的畸形怪胎就不应该诞生在这个世界上,它们就是纯纯的赛博医疗垃圾,我所做的一切努力就是让它们从各个层面上死透。“否则花大力气介绍一个已不存在的名称实在不值得”,我觉得值,很值,我这两年来爆的肝都tm是值的。--Bigbullfrog1996(𓆏) 2022年7月30日 (六) 22:59 (UTC)
- 既然阁下对于机翻译名如此的仇恨,那我也就不多说什么了。我的观点还是很简单:可查证即可保留。--Patriotard 2022年7月31日 (日) 00:18 (UTC)
- 但需要辨清循环报道/Citogenesis。如果错误首先是从维基散出去的,就不应该再作为维基的来源。我的观点与Bigbullfrog1996相似。我也有证据证明谷歌地图上的中文译名是从Wikidata上取的(如:[1])。批量创建条目这种重数量而不重质量的做法值得商榷。我觉得无内容比错误内容更好。--万水千山(留言) 2022年8月1日 (一) 07:32 (UTC)
- 我个人还是偏向保留机翻译名的重定向。首先重定向不是条目正式名,本质上是隐藏页面,不影响“正确译名”的传播使用。其次,维基输出不假,关键在于输出并有了结果,红移相当于否定或不认可机翻译名XXX的客观存在,但倘若如此,Bigbullfrog1996建立的误译模板中“此条目所述地在部分地图类app/网页中的名称为XXX”这句话就明显缺乏来源,所以我认为这个系列的模板和红移不应该同时使用:要么红移并删模板,要么机翻重定向和模板同时保留(个人偏向后者)。现阶段已不存在“批量创建条目这种重数量而不重质量的做法”,新建条目大概率会有人工校正,所以从维基输出新的机翻译名基本已无可能。再参考一些外维的做法,英维中“Lu'an”“Laoting”“Bengbu”这些存在官方名称(汉语拼音)的地方也有“Liuan”“Leting”“Bangbu”的重定向,后者虽然不是维基输出的,但也属于无可非议的错误名称。我建议若要建立机翻译名重定向可以统一归个类,之后好管理。--Patriotard 2022年8月3日 (三) 15:47 (UTC)
- 我举个通俗的例子,小明大一时写的某篇论文被一位知名教授引用发表,等小明毕业后他的学弟小华发现论文某些内容有欠缺,于是及时进行了修改,小华还同时通知了知名教授,只不过教授自始至终也没有要修改的迹象,这种情况下如果您是小华,您有必要去帮小明擦屁股或者死皮赖脸地去纠缠教授吗?--Patriotard 2022年7月31日 (日) 11:12 (UTC)
- 不知道为什么您要拿学术方面举例子,但我就是我,我不管他小华怎么想,他爱什么立场什么立场,反正我的立场是坚定的,在维基方面我就是雷打不动地跟狗屎误译杠上了。--Bigbullfrog1996(𓆏) 2022年8月2日 (二) 23:45 (UTC)
- 我觉得吧,看不顺眼就“狗屎”,看的顺眼就“历史”,这种强势的自我意识对维基讨论没什么太大帮助。--Patriotard 2022年8月3日 (三) 15:47 (UTC)
- 既然阁下对于机翻译名如此的仇恨,那我也就不多说什么了。我的观点还是很简单:可查证即可保留。--Patriotard 2022年7月31日 (日) 00:18 (UTC)
- 我建议先用专门模板与列表页面标注有疑问的机翻名称,之后再统一或分别作专门讨论。速删乃至一般的存废讨论,都难以辨别译名是否合格,也难以留下历史记录备查。--YFdyh000(留言) 2022年7月30日 (六) 18:45 (UTC)
- 又见“维基百科不保证其内容正确无误”。国外事物的译名,个人认为也有WP:列明来源的必要。个人习惯写到国外的事物,在遇到译名问题,都会在讨论页写明为何使用这个译名(1、2、3)。--Nostalgiacn(留言) 2022年8月1日 (一) 09:18 (UTC)
- 但大多数案例没有遵循此原则。免责声明感觉不适用,本例涉及到媒体引用维基的“不正确”内容后,维基是否能引用此来源作佐证。--YFdyh000(留言) 2022年8月2日 (二) 02:51 (UTC)
- 对于循环报道的情形,我觉得维基百科不应该引用。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月2日 (二) 05:26 (UTC)
- 没来源的,加{{暂定名称}},如果一开始有这些维护模板,应该可以减少这种原创译名的流通。原创译名反传着传着变成官方译名的情况也有,ACGN作品这种情况也有不少(如《紫罗兰永恒花园》)。还不如搞个类似WP:ACGNAME的译名共识,给译名分个三六九等,那些可用,那些就挂个{{暂定名称}}应付。--Nostalgiacn(留言) 2022年8月3日 (三) 07:07 (UTC)
- 感觉作用有限,抄这些译名的作者/机构,可能不是很在意或者无法判断权威性。很多例子可能是没有“官方译名”,“口口相传”的译名、误称有时反而成为正确。同理,有来源的译名,来源是否可靠、其他机构是否用,也是两说。--YFdyh000(留言) 2022年8月3日 (三) 07:21 (UTC)
- 但大多数案例没有遵循此原则。免责声明感觉不适用,本例涉及到媒体引用维基的“不正确”内容后,维基是否能引用此来源作佐证。--YFdyh000(留言) 2022年8月2日 (二) 02:51 (UTC)
- 有关Google地图上地名的问题,刚在meta上和Google有合作的团队页面上留了个言希望看看能否提供协助。meta:Talk:Wikimedia_Foundation_Partnerships_team#Problematic_content_from_Chinese_Wikipedia_keep_by_Google_after_correction.——C933103(留言) 2022年8月7日 (日) 12:48 (UTC)
- 我这边有一个类似的问题,有些误译已经被可靠来源采用,甚至被当事国的驻华机关采用,例如Talk:蒙特塞克山脉。我之前按照常用原则恢复到误译,但现在觉得还是提出来供社群讨论为好,所以大家认为这种该如何处理?--——🦝Procyon rolandae Luo, 2022 「我々は堅く同志小林の血路に沿って前進し握手するのだ」(留言・贡献) 2022年8月9日 (二) 15:21 (UTC)
- 从列明来源角度,如果编者坚持蒙塞克山脉是正确译法,最好举一例该译法的可靠来源,或者得讨论共识,不赞成自行矫正被其他来源佐证的内容,这也不符合维基百科三手来源的作用。从发音角度,一些英语TTS的确将“Montsec Range”中的t发音省略,但也有一些TTS针对“Montsec Range”或“Sierra del Montsec”的发音中能听到“特”的发音(虽然有时去掉“t”不影响结果),我不确定发音或音译中省略“特”做法的正误。像是azure中使用“Spanish (Costa Rica)”,“Sierra del Montsec”的发音能听到“特”,而“Monsec”发音会有区别,虽然我也不确定TTS结果正确,但至少有可能是口音差异。 --YFdyh000(留言) 2022年8月10日 (三) 11:32 (UTC)
- 是的,我当时也是这样考虑的,但是如果这个误译本来就是来自维基百科该如何处理?生者传记有提到应当避免这种情况,但我不确定这个方针是否在其他地方适用--——🦝Procyon rolandae Luo, 2022 「我々は堅く同志小林の血路に沿って前進し握手するのだ」(留言・贡献) 2022年8月16日 (二) 00:41 (UTC)
- 从列明来源角度,如果编者坚持蒙塞克山脉是正确译法,最好举一例该译法的可靠来源,或者得讨论共识,不赞成自行矫正被其他来源佐证的内容,这也不符合维基百科三手来源的作用。从发音角度,一些英语TTS的确将“Montsec Range”中的t发音省略,但也有一些TTS针对“Montsec Range”或“Sierra del Montsec”的发音中能听到“特”的发音(虽然有时去掉“t”不影响结果),我不确定发音或音译中省略“特”做法的正误。像是azure中使用“Spanish (Costa Rica)”,“Sierra del Montsec”的发音能听到“特”,而“Monsec”发音会有区别,虽然我也不确定TTS结果正确,但至少有可能是口音差异。 --YFdyh000(留言) 2022年8月10日 (三) 11:32 (UTC)
两个名称相似的分类,以及其追踪分类
如题,Category:被保护的模块、Category:受保护模块两分类命名过于相似,虽然可理解前者是受到一般保护,后者是根据软件版本周期、由编者自评的保护分类,但还是希望在命名上有所区隔,邀请两分类创建者User:Quest for Truth、User:Great Brightstar及各位一起讨论。此外追踪前者的分类Category:使用受保护Lua模块的模板也应随之更名。--回廊彼端(留言) 2022年7月30日 (六) 14:01 (UTC)
- 建议把这两个分类合二为一。-- ⚞︎★⚟︎ 2022年7月30日 (六) 15:10 (UTC)
- 可是这两个分类,一个应该是技术上的,而另一个不是,将分类合并怕是会招致混淆。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月1日 (一) 05:17 (UTC)
- 实务上连后者的英文对应分类都有点鸡肋我觉得,Template:Module rating的protect参数似乎只能提醒编者此模组有被保护,不是挂上此模板就自动被保护。--回廊彼端(留言) 2022年8月9日 (二) 11:20 (UTC)
- emmmm⋯⋯ —— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月17日 (三) 03:25 (UTC)
- 实务上连后者的英文对应分类都有点鸡肋我觉得,Template:Module rating的protect参数似乎只能提醒编者此模组有被保护,不是挂上此模板就自动被保护。--回廊彼端(留言) 2022年8月9日 (二) 11:20 (UTC)
- 可是这两个分类,一个应该是技术上的,而另一个不是,将分类合并怕是会招致混淆。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月1日 (一) 05:17 (UTC)
提议修改Expert needed模板
Bingobingo君再次建立诸多疑似原创研究名称的动车组列车
有关此话题之前的讨论请见此。在去年11月我及@Lantx、Itcfangye二君对@Bingobingo102080建立诸多疑似原创研究名称的动车组列车条目进行质疑后,该君在近期又再次创建诸多类似条目,如:
- 津哈高速动车组列车:天津至哈尔滨,百度搜索结果、谷歌搜索结果,均无结果。
- 武昆高速动车组列车:武汉至昆明,百度搜索结果、谷歌搜索结果,均无结果。
- 商蓉高速动车组列车:商丘到成都,百度搜索结果、谷歌搜索结果,均无结果。
该君创建大量疑似原创研究名称的动车组列车条目,已对WP:NOR形成严重违反,且在去年被提醒后再犯。请社群酌情处理。 --三万光年 GBAW · 6000+ 2022年8月11日 (四) 03:03 (UTC)
- ping人解释下?已有的条目有没解决方案?(例如参考Z类的命名方式,如Z1/2次列车)——Sakamotosan路过围观 | 避免做作,免敬 2022年8月11日 (四) 03:48 (UTC)
- 已经ping过了。要我说,这类条目存在的必要性存疑,因为中铁调图很频繁,平常变更始发/终到站情况很多,到时候这类车次条目的维护会很头疼。--三万光年 GBAW · 6000+ 2022年8月11日 (四) 07:06 (UTC)
- 附议。--懒癌哪天行→Lazy, as no today's excuse. 2022年8月11日 (四) 05:25 (UTC)
- 在下意见与去年相同,Bingobingo102080君将一些条目移动,并自己建立了一部分条目。应将移动的条目予以复原并删除不合规的条目。--懒癌哪天行→Lazy, as no today's excuse. 2022年8月12日 (五) 03:54 (UTC)
- 我认为应该将这些条目合并到对应的高铁线路。--🎋🍣 2022年8月11日 (四) 14:43 (UTC)
- 线路分离,如果跨路的不能这样搞吧?这不同于城市轨道交通常见的线路合一。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月12日 (五) 00:31 (UTC)
- 中铁跨线车很常见,我不认为这样子做很妥当……--三万光年 GBAW · 6000+ 2022年8月12日 (五) 01:19 (UTC)
- 说一个具体方案呗,您所说的这种情况错综复杂可操作性不大啊。--绍💓煦DC20 2022年8月12日 (五) 01:30 (UTC)
- 应尽速删除相关既原创研究又违反可供查证方针之中国大陆动车组列车条目。--绍💓煦DC20 2022年8月11日 (四) 17:50 (UTC)
- 你看过里面的内容没有?——Sakamotosan路过围观 | 避免做作,免敬 2022年8月12日 (五) 00:32 (UTC)
- 请问您要怎么改呢?--绍💓煦DC20 2022年8月12日 (五) 01:00 (UTC)
- 编辑志愿性,关我屁事。再说如果部分内符合规范的话,可以考虑保留部分,除非整篇都是没来源支撑或者来源完全不符合要求,才考虑整篇删除的需要。至于命名方式,上面已提及。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月14日 (日) 02:35 (UTC)
- 请问您要怎么改呢?--绍💓煦DC20 2022年8月12日 (五) 01:00 (UTC)
- 你看过里面的内容没有?——Sakamotosan路过围观 | 避免做作,免敬 2022年8月12日 (五) 00:32 (UTC)
- 这些条目似在归纳曾开行于A地到B地的高速动车组列车,本质可能是某种列表。对于调图,调整后线路或许可以不再列入条目。但我很怀疑条目中许多信息难以查证和正确,以及部分涉及原创总结。基本只有“历史”章节列出了一些二手报道,而其他信息大概是基于一手来源所做的收集或原创总结,将这些内容作车次条目编写感觉问题很大。如有必要汇集,还不如写为一个或多个大列表——但如何排布有些问题,比如按始发站还是终点站,都写或者用嵌入感觉会崩,变更又怎么衔接。--YFdyh000(留言) 2022年8月12日 (五) 01:38 (UTC)
- 基本同意。--绍💓煦DC20 2022年8月12日 (五) 01:42 (UTC)
- 只要条目上引用的来源第一层符合要求,就算可能是其背后研究方式可能不符合我们站点的要求,也不是我们站点所考虑的问题,除了来源第一层是转载性质的,需要再检查第二层的。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月14日 (日) 02:39 (UTC)
- 对该用户应该如何处理?--三万光年 GBAW · 6500+ 2022年8月13日 (六) 03:04 (UTC)
- 如果前面的内容产生共识的前提下,在下认为,目前倒也不必到封禁的地步,警告即可。--懒癌哪天行→Lazy, as no today's excuse. 2022年8月13日 (六) 03:10 (UTC)
- 关于命名的话,先提醒注意是否存在原创问题。关于内容,检查下是否来源是否符合要求,还有来源与描述是否对应(避免原创的问题)。如果情况继续的话,就要针对原创研究来考虑加码。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月14日 (日) 02:43 (UTC)
- 问题在于这些条目命名本身就是对原创研究的非常严重的违反。--三万光年 GBAW · 6500+ 2022年8月14日 (日) 14:33 (UTC)
- “严重”?可能吧?不过我认为如果无法确认这些命名是可以用来源考据的,直接以到以现时或初始时的班次编号对写法(就是上面我提及的例子)就可以解决了。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月15日 (一) 01:04 (UTC)
- 我对该类车次是否有必要收录抱有极大怀疑。--三万光年 GBAW · 6500+ 2022年8月15日 (一) 02:20 (UTC)
- 这是后话,请自行核查来源、行文是否和关注度、NOT等规范是否合适来决定,但不太建议使用笼统的观点来判断整体。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月15日 (一) 03:38 (UTC)
- 我对该类车次是否有必要收录抱有极大怀疑。--三万光年 GBAW · 6500+ 2022年8月15日 (一) 02:20 (UTC)
- “严重”?可能吧?不过我认为如果无法确认这些命名是可以用来源考据的,直接以到以现时或初始时的班次编号对写法(就是上面我提及的例子)就可以解决了。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月15日 (一) 01:04 (UTC)
- 问题在于这些条目命名本身就是对原创研究的非常严重的违反。--三万光年 GBAW · 6500+ 2022年8月14日 (日) 14:33 (UTC)
- 删除,并警告用户。如果再犯的话可能需要封禁。Itcfangye(留言) 2022年8月13日 (六) 04:02 (UTC)
- 那要删的可不是一点半点。--三万光年 GBAW · 6500+ 2022年8月13日 (六) 04:23 (UTC)
- 可惜尚无“草稿化”共识。--YFdyh000(留言) 2022年8月13日 (六) 08:22 (UTC)
- 那要删的可不是一点半点。--三万光年 GBAW · 6500+ 2022年8月13日 (六) 04:23 (UTC)
- 我正在阅读什么?一整堆编号。
- 这个模版内的内容都是肇事编辑者更新的。
- T:中国高速动车组列车车次--唔好阻住我爱国(留言) 2022年8月14日 (日) 15:57 (UTC)
- 那你想看到什么?のぞみ1号? ——Sakamotosan路过围观 | 避免做作,免敬 2022年8月15日 (一) 01:08 (UTC)
- 但编号就是车次的名字,原创的名字只是原创。1号美国国道→“美国缅因州至佛罗里达州国道”怎么样 。--YFdyh000(留言) 2022年8月15日 (一) 04:12 (UTC)
- “G1-3次、G5-28次、G102-107次、G109-114次、G116-119次、G121-130次、G132-135次、G137-150次、G152-154次、G156-157次、G159-161次、G163次”全部也是redirect to 京沪高速动车组列车,这样霸占字数真的好吗?--唔好阻住我爱国(留言) 2022年8月15日 (一) 11:15 (UTC)
- 所以我上面说他在总结归纳。而这种总结和命名,可能涉及原创总结,很多结论涉及总结研究多项资料,而非出自二手或一手来源。--YFdyh000(留言) 2022年8月15日 (一) 12:02 (UTC)
- 京沪高速动车组列车可能是归纳后的原创命名,但对应的服务班次可能是现实数据的归纳。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月17日 (三) 00:31 (UTC)
- 所以为什么不以班次命名呢?--懒癌哪天行→Lazy, as no today's excuse. 2022年8月17日 (三) 05:29 (UTC)
- 所以这就是对这些班次的归纳原创命名问题,如果不能确定这个命名的非原创性,可以用班次来代替。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月17日 (三) 05:38 (UTC)
- 京沪高速动车组列车应(►)重定向至京沪高速铁路
- 京沪高速铁路是官方名称!--唔好阻住我爱国(留言) 2022年8月17日 (三) 06:54 (UTC)
- 线路和车次不是一个概念。--Yinyue200(留言) 2022年8月17日 (三) 07:16 (UTC)
- 线路分离,一个服务线路和其使用的道路是两码事(举例类似:第二大道线和纽约地铁N线)。你懂不懂铁路主题的,还是你没看前面的讨论?——Sakamotosan路过围观 | 避免做作,免敬 2022年8月17日 (三) 08:14 (UTC)
- 你当我不懂铁路主题?
- 由于京沪高速动车组列车不是正式名称,所以建议(±)并入京沪高速铁路,于条目内开新部分简单介绍行经相关路段列车的起终点即可,而时刻表是可以删除。
- .
- 不知道为什么,很想找铁路模版专业回退员执行条目整合的问题!--唔好阻住我爱国(留言) 2022年8月17日 (三) 13:52 (UTC)
- 你自己看你上面那句话。如果服务车次与路线刚好合一的可能可以这么处理,但是如果对于跨线服务车次可能不能这样处理(至少起始讨论提到的三个服务班次就是跨线车次而不是单一路车次),或者信息分散(将多个服务车次分别提及在各路上),或者导致信息丢失(过于简略提及班次,可能丢失一些班次变化历史的百科性介绍)。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月18日 (四) 00:40 (UTC)
- 所以这就是对这些班次的归纳原创命名问题,如果不能确定这个命名的非原创性,可以用班次来代替。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月17日 (三) 05:38 (UTC)
- 所以为什么不以班次命名呢?--懒癌哪天行→Lazy, as no today's excuse. 2022年8月17日 (三) 05:29 (UTC)
- “G1-3次、G5-28次、G102-107次、G109-114次、G116-119次、G121-130次、G132-135次、G137-150次、G152-154次、G156-157次、G159-161次、G163次”全部也是redirect to 京沪高速动车组列车,这样霸占字数真的好吗?--唔好阻住我爱国(留言) 2022年8月15日 (一) 11:15 (UTC)
- 但编号就是车次的名字,原创的名字只是原创。1号美国国道→“美国缅因州至佛罗里达州国道”怎么样 。--YFdyh000(留言) 2022年8月15日 (一) 04:12 (UTC)
- 那你想看到什么?のぞみ1号? ——Sakamotosan路过围观 | 避免做作,免敬 2022年8月15日 (一) 01:08 (UTC)
{{Höhe}}相关问题
“苏联政治笑话”条目中,笑话原文占据篇幅过大
社群是否认为将毛泽东列入极权主义领导人分类有争议?
磐石油弹补给舰条目拆分?
葡萄牙人如何开始在澳门定居?
现时在中文维基百科多数条目上,对此的解释均为声称葡萄牙人以晾晒货物为籍口贿赂当地官员以获准居留。包括澳门、澳门历史、澳门历史年表、中国通商史、中葡关系、中山市、汪柏、明世宗等条目。其中一部分条目引用了明清时期地方史料作来源。但有一些研究认为这种说法并不可信,同时其他语言维基百科对此的叙述:en:Luso-Chinese agreement (1554)(中文维基百科缺乏对应条目)也貌似并不符合此说法。
在此情况下,中文维基百科应该如何表达相关历史?--——C933103(留言) 2022年8月20日 (六) 15:16 (UTC)
- 阅。我认为:本议题可总结为一个topic,即“汪柏在与葡人订立口头协议过程中是否受贿”问题。以我目力所见,凡涉及此问题的中文文献,除你所列的论文外,无不说汪柏受贿。因此,汪柏受贿说是绝对的主流观点。那么以维基百科观点来看,剩下的问题就是你所列的论文提出的论点能否定义为“重要少数观点”而写入条目。考虑到黄鸿钊2015年的论文不点名地、精炼地、不失理据地反驳了你所列的论文的观点,我认为此论点无作为“重要少数观点”写入条目的必要。英文维基百科所依据的外文文献可能由于不关心等原因,未涉及汪柏受贿问题,于是英文维基百科引用两篇讨论此问题的论文来说明“存在争议”。我认为,在注释中提及有学者有这样的说法(我并不倾向如此写法),已经是维基百科对这一论点最大的优待了。Fire Ice 2022年8月20日 (六) 19:02 (UTC)
- 应分别列明和归纳观点。如涉及多个条目的阐述,可能比较麻烦。我暂无法断言已出版来源是“重要少数观点”、无写入必要,对于哪个是“主流观点”,需直接或多例文献引证。似乎讨论此问题的文献不算少,可以详细引证和撰写相关研究。--YFdyh000(留言) 2022年8月21日 (日) 11:33 (UTC)
请求修复 Template:Legend/Begin 与 Template:Legend/style.css
沙漠猫中的Lua错误
收视率标示
不少影视条目会在收视率上色,以《美男堂》为例,有好几集收视低到查不到,根本无法确认“最低”收视的数据,部分用户坚持以已知的收视作为最低收视上色,请问此举是否为原创研究?--Sa Young Sun(留言) 2022年8月23日 (二) 05:00 (UTC)
- 说实话,我不知道列收视率表的作用,没有相关总结性陈述(如某标准下排名第几),有多少读者阅览这些数据。--YFdyh000(留言) 2022年8月23日 (二) 09:00 (UTC)
- 收视率是体现观众收看以及剧集评价的一环,是必要的内容,毕竟不是要冲优良条目,确实还有扩充的空间(总结性陈述)。我是不确定有多少人会阅览这些数据,但从新闻或PTT等论坛,都会透过收视率来评断一部戏的一部分价值,类似于电影的票房。
- 但我这次提问的重点是,上色标示最低收视(即便我不支持上色),但在部分集数查无收视的情况下,根本无从得知“真正”的最低收视为何,那么上色是否即是“原创研究”?--Sa Young Sun(留言) 2022年8月23日 (二) 10:46 (UTC)
- 专业性刊物可能参考和总结数据,但面向一般人的百科全书条目,单纯列数据我认为不是很有用。如果是药物、小行星等条目,列些数据我还能接受(但最好是信息框),读者一般有了解的需求,而电视节目列收视率,恐怕只有电视迷和业内人士能解读其中含义,一般人如何辨别这些数据是高是低、相关背景如何。
- 关于标注,首先我不了解为什么要标注最高/最低、如何决定时间范围。自行研究多个一手来源得出哪个数据最低,似乎有原创总结风险,但如果条目内有清楚阐述/备注,也许可接受,我不清楚“查无收视”是什么情况。--YFdyh000(留言) 2022年8月23日 (二) 13:05 (UTC)
- 所以我也认同还有扩充的空间,毕竟评价段落对影视条目是必须的,而观众无法代表专业评价,可是收视率可以表示其观点,但我无心协助扩充这些非我主编的条目。
- 我不支持上色标注最高、最低,但部分用户非常坚持,这就罢了,但“查无收视”的情况,就是调查公司只公布前20名的收视,收视低于20名的节目便无从得知,以《美男堂》为例,TNMS调查有9集的收视低于20名,即一般大众无从得知这9集的收视率,但部分用户将“已知最低”的收视标注为最低,我觉得在有未知收视的情况下,这算是涉及原创研究吧?--Sa Young Sun(留言) 2022年8月24日 (三) 03:47 (UTC)
- 技术上来说,没有收视率的才是“最低”收视吧= =。 --窝法乙烷 儿法梦碎 2022年8月24日 (三) 05:03 (UTC)
- 我就是这么认为@@--Sa Young Sun(留言) 2022年8月25日 (四) 02:49 (UTC)
- 技术上来说,没有收视率的才是“最低”收视吧= =。 --窝法乙烷 儿法梦碎 2022年8月24日 (三) 05:03 (UTC)
在台湾政治人物条目中加注台湾闽南语罗马字是否妥当
近期有越来越多的台湾政治人物条目内加入台语罗马字,多以台罗为主。但本人认为台语多以汉字书写,给政治人物条目内加台语读音只能说是画蛇添足,甚至于给母语非台语的政治人物(如客家人、外省人、马祖人)加注台语罗马字更是有福佬人沙文主义之嫌,在此希望能跟大家讨论。--K.Y.K.Z.K.(留言) 2022年8月19日 (五) 09:44 (UTC)
- 大致同意,正如同香港人物的条目也没有在引言标注其姓名的粤拼。不过,请问有哪些母语非台语的台湾政治人物姓名被加注台语罗马字呢?过往我都没有发现。-游蛇脱壳/克劳棣 2022年8月19日 (五) 10:30 (UTC)
- 据我了解,至少有锺佳滨(籍贯广东汕头,客家血缘外省人第二代)、鲁明哲(籍贯安徽定远,成长于台北眷村)等台湾政治人物的条目出现了这种情况。--A0231050705(留言) 2022年8月19日 (五) 15:43 (UTC)
- 粤拼与台罗不可直接类比。粤拼只是注音符号,台罗则是文字。--Mosowai(留言) 2022年8月28日 (日) 06:34 (UTC)
- 我不确定给部分台湾政治人物加上台湾话姓名是否洽当;英文姓名同理。这些外文名称或可添加于资讯框之中,但是否要加在条目导言就值得商榷。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月19日 (五) 17:57 (UTC)
- 我认为:如果一个台湾政治人物是非原住民或非混血/少数族裔,那么连英文名都不应标注,毕竟台湾的官方语言不是英语,这些人的母语也不是英语。--K.Y.K.Z.K.(留言) 2022年8月19日 (五) 19:33 (UTC)
- 台湾有官方语言?-游蛇脱壳/克劳棣 2022年8月19日 (五) 23:21 (UTC)
- 台湾是有国家语言发展法,那跟这边是中文维基百科有何关系?我们可不是依据国家语言发展法编辑中文维基百科的。若有可靠的第三方来源显示该人物的台罗名称更常在一般状况下被使用,或是有官方文件证明台罗名称是该人物的主要名称(也就是台罗名称是他的主要名称,但因为这边是中文维基,所以用他的中文名称当条目名,并在导言中一开始括号内标明台罗名称,那合情合理),才有需要收录。其他的只是若只是为了宣传(无论是宣传该人物之政治立场或者是宣传台罗文),那就没必要额外添加台罗名称,毕竟维基百科不是宣传工具。--Anghualee(留言) 2022年8月20日 (六) 15:11 (UTC)
- 同意您的意见,不过您好像误会我了,我上一个回复的意思是“台湾目前没有官方语言”,而不是“台湾有官方语言”或“台湾有相当于官方语言的语言”。-游蛇脱壳/克劳棣 2022年8月21日 (日) 07:56 (UTC)
- 台湾是有国家语言发展法,那跟这边是中文维基百科有何关系?我们可不是依据国家语言发展法编辑中文维基百科的。若有可靠的第三方来源显示该人物的台罗名称更常在一般状况下被使用,或是有官方文件证明台罗名称是该人物的主要名称(也就是台罗名称是他的主要名称,但因为这边是中文维基,所以用他的中文名称当条目名,并在导言中一开始括号内标明台罗名称,那合情合理),才有需要收录。其他的只是若只是为了宣传(无论是宣传该人物之政治立场或者是宣传台罗文),那就没必要额外添加台罗名称,毕竟维基百科不是宣传工具。--Anghualee(留言) 2022年8月20日 (六) 15:11 (UTC)
- 台湾有官方语言?-游蛇脱壳/克劳棣 2022年8月19日 (五) 23:21 (UTC)
- 我认为:如果一个台湾政治人物是非原住民或非混血/少数族裔,那么连英文名都不应标注,毕竟台湾的官方语言不是英语,这些人的母语也不是英语。--K.Y.K.Z.K.(留言) 2022年8月19日 (五) 19:33 (UTC)
- 中文维基百科使用书面中文,大多数政治人物条目应该表记汉文人名就够了,个人认为除非特殊情况(比如游锡堃的“方方土”可能标示读音会更好),不需要特别标注标准汉语、台语、客语、马祖闽东语、粤语等汉语族诸语读音。--S099001(留言) 2022年8月26日 (五) 00:44 (UTC)
- 按照相关条目的标记方法,这些罗马字表记并非为了标示读音而存在,而是在把台湾闽南语视作不是中文维基百科所采用的“现代标准汉语”的外语,因此将闽南语名称和英语及日语等一样地使用外语原文模板标记,并且将罗马字视为台湾闽南语的标准书写方法。--——C933103(留言) 2022年8月26日 (五) 02:53 (UTC)
将分类中设立、所设等用词统一为建立
按辞典定义,“建立”一词等于创立、设立,而且同时可用于抽象、具体事物,例如建立朝代、建立基地。目前“建立”也在分类命名中广泛应用达17112笔,Category:各年建立也是这些分类的母分类。不过目前还有部分子分类是用成立(主要是公司、音乐团体、行政区划、电视台)、设立(主要是保护区、中华人民共和国政府机构、还有一些行政区内的设立)、所设(主要是军事基地、军用机场)等同义词命名,希望尽可能统一为“建立”,在此寻求共识。--回廊彼端(留言) 2022年8月14日 (日) 11:33 (UTC)
- 此外还有创建(教育机构跟学区)、所创(主要是体育组织、基督教组织)、所建、创办(杂志、少数机构,衍伸出创办人跟创办者的两种命名法;出版品另有创刊、面世等数种内容),也欢迎各位补充。--回廊彼端(留言) 2022年8月14日 (日) 16:43 (UTC)
- 同类中统一支持,整体统一有担忧,特定分类的描述中含义、感觉有差异。比如建立了公司(班子/业务)但没成立公司(完成注册手续),“设立保护区”与“建立保护区”有差异(前者只需手续,后者似要动工)。--YFdyh000(留言) 2022年8月15日 (一) 04:16 (UTC)
- 将“**建立”设为重定向方便查找?--Kethyga(留言) 2022年8月17日 (三) 04:56 (UTC)
- 无年份的分类可以,有年份的感觉不必要,会建立太多重定向。--YFdyh000(留言) 2022年8月17日 (三) 12:17 (UTC)
- 将“**建立”设为重定向方便查找?--Kethyga(留言) 2022年8月17日 (三) 04:56 (UTC)
- 含有跟包含顺便一下统整一下吧... --Anghualee(留言) 2022年8月16日 (二) 06:28 (UTC)
- 部分支持部分反对:
- 部分分类使用“建立”则其收录标准将会模糊,比如前者举例,虽然英维统一用establishment,但这个字在中文有很多意思,甚至还有区别。若原先所用词汇之含义与“建立”没有差异,则统一使用建立;否则维持现状。
- 反对将面世统一为建立,面世对应词汇为Introduction,为将产品、书籍、交通工具等实物或作品呈现于世,并无废除之可能性,不应与建立混为一谈。
- --Steven |_-。) 2022年8月17日 (三) 04:51 (UTC)
- 不赞同,意思稍有区别,应当个案(逐类别)讨论。--Yinyue200(留言) 2022年8月19日 (五) 18:54 (UTC)
- 可能有不少例外需要处理。—— Eric Liu 創造は生命(留言・留名・学生会) 2022年8月29日 (一) 18:41 (UTC)
s box是否得限制下
一个条目七八个、十几个模板,难道会有人愿意看这个?Fire Ice 2022年8月31日 (三) 01:32 (UTC)
- 建议明确举例。孙中山为例,稍微有点多,与信息框有所重复,但不排除有用,英文条目有差不多的内容。另外有郭德纲等相声演员条目中作“师承”章节、资料陈列的用法。--YFdyh000(留言) 2022年8月31日 (三) 03:47 (UTC)
- u:Joe young yu的一系列人物条目贡献,基本都有s box偏多的问题。郭德纲条目这种用法,不在我讨论范围内,我主要指的是用s box罗列人物职务的问题。Fire Ice 2022年8月31日 (三) 04:00 (UTC)
- 从源码和版面来说,占用稍多,但又不算特别复杂,编写方式不了解,手写恐怕有点繁琐。作用中等,有需要的人能用上(前提是准确无误),没需要的人不想看。这种结构化信息,或许尚无相关共识,不了解英文维基是如何规范。一些想法:允许或默认折叠;某种章节名?但很难订立;是否可能转为模块和维基数据,但编辑难度可能更高。这些信息,有价值,但对条目主题和许多读者作用有限,有点可有可无。--YFdyh000(留言) 2022年8月31日 (三) 07:02 (UTC)
- u:Joe young yu的一系列人物条目贡献,基本都有s box偏多的问题。郭德纲条目这种用法,不在我讨论范围内,我主要指的是用s box罗列人物职务的问题。Fire Ice 2022年8月31日 (三) 04:00 (UTC)
- 参考上临个案,认为有关提案必要排除编辑者自身固定偏好,并应有确凿个案具名列举、以便可能参与者等理解是否具有进一步讨论之空间。--约克客(留言) 2022年8月31日 (三) 07:33 (UTC)
- 整体上s box我觉得还是挺方便的吧,我就经常看。太长的个例可以尝试折叠,或者使用更好的排版。--Yinyue200(留言) 2022年8月31日 (三) 19:59 (UTC)