维基百科:互助客栈/条目探讨/存档/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)