維基百科:互助客棧/條目探討/存檔/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)