Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement

任何人都可以編輯這個頁面!

這是Lakejason0的使用者頁面,但鼓勵其他用户編輯這個頁面及其子頁面。
如果你的編輯被過濾器阻止,請將你的變更建議發佈至討論頁

Iron Pickaxe
該頁面的編輯正在進行中。 討論

請幫助我們擴充或改進這篇文章。

此頁面用來記錄我對於MCWZH的一點點論證。

另請參見:如何管理中文Minecraft Wiki

前提性的結論[]

  • 玩家群體總體是鬆散的,凝聚力弱的群體。
  • 玩家群體所需要的優先重視,不那麼需要的自然不那麼重視。
  • 玩家群體的擴大通常意味着難以達成共識。

主要的幾個結論[]

  • 中文Minecraft Wiki是維基。
  • 中文Minecraft Wiki是記載Minecraft相關內容的wiki。
  • 中文Minecraft Wiki是英文Minecraft Wiki的子語言項目,但不只是一個子語言項目而已。
  • 中文Minecraft Wiki是Minecraft中文字地化的重心。
  • 中文Minecraft Wiki的管理模式是「小圈子式」的。

具體論證[]

維基性[]

中文Minecraft Wiki是基於MediaWiki軟件運作的,因此,其主要優勢和主要限制都在於MediaWiki軟件本身。

可視化編輯[]

可視化編輯一直都是一個(除了處理表格以外,甚至對於表格都很雞肋)華而不實的東西,其原因主要在於其對於模板的支援實在是慘不忍睹。而偏偏,MediaWiki軟件的一大優勢就是模板,因此,如果使用可視化編輯無法發揮模板的作用,那麼可視化編輯在可預見的未來就一直會是一個新手愛用但是會造成管理困難的東西,其間接後果就是勸退新人。這不利於中文Minecraft Wiki吸納新鮮血液。

農場[]

中文Minecraft Wiki依賴Gamepedia這個Wiki農場運作,因此很多事務也受到Gamepedia本身的牽制。比如註冊登入問題等。

Minecraft相關性[]

中文Minecraft Wiki收錄Minecraft相關內容,包括但不限於Java版基岩版、歷史內容、Minecraft DungeonsMinecraft Earth等。

Java版[]

Java版是Minecraft Wiki一直以來就在記錄的東西,內容較為完整詳實,但是存在新舊內容混雜,舊內容無法及時得到更新的問題。

基岩版[]

基岩版是後來才有的,因此Wiki原有的很多的只適用於Java版的內容,由於各種原因無法得到標註。這導致中文Minecraft Wiki的基岩版內容在事實上存在很多的錯誤,也是基岩版玩家的一個痛點。

Spin-offs[]

Minecraft Earth和Minecraft Dungeons由於SEO的關係,依然建在了原來的Minecraft Wiki裡。這些內容大多並不詳細,需要很多人幫忙完善。

子語言項目性[]

中文Minecraft Wiki是英文Minecraft Wiki的子語言項目,其工作的一大內容就是將英文Minecraft Wiki的內容翻譯過來。

中文Minecraft Wiki真的只是英文Minecraft Wiki的子語言項目?[]

由於子語言項目性,中文Minecraft Wiki長期以來的運作模式都是EN怎麼做我們照做。但是,英文站點的質量日益下滑,處理事情的流程和時間也變得越來越長,這導致很多內容在英文站點也是沒有的。中文Minecraft Wiki的維護者大多也只會同步一些主空間條目,沒有時間與精力去做原創內容的驗證,因此在很長一段時間內,中文Minecraft Wiki一直不允許主條目的大段原創內容。除了擔心內容重複、質量不高等原因外,另一點就是怕原創內容被下一個編輯者從EN同步時就刪掉了。由於以上原因,現在中文Minecraft Wiki也慢慢放開了這個限制,但是不同步問題依然需要編輯者有反向同步的能力才能順利完成。

原創教學[]

寫了一篇教學/製作數據包/實例:蜜蜂助手

目前來説,原創教學除了質量良莠不齊的問題以外,就是曝光度不高,被修改的可能性也不高。因此,本來應該由大部分人改進的原創教學最後可能就荒廢了。

本地化重心性[]

中文Minecraft Wiki的管理人員同時也有Minecraft Java版的Crowdin項目的管理權,因此Minecraft內容的譯名,產出或傳播都主要依靠中文Minecraft Wiki和其合作的組織(例如MCBBS)。

中文為什麼這麼「麻煩」[]

我前後參與了原版Minecraft、RAA和Sodium的翻譯。現在我來談談為什麼中文這麼「麻煩」。

首先,中文對於外來語的接納便利性較低。舉個例子,菌光體的英文Shroomlight,對於法語等歐洲語言來説,他們擁有共同的被稱作「詞根」的東西,並且詞根之間是可以以相似的方式拼接的,所以可能的譯名很快速就出來了:Lampignon和Champilampe,分別由燈「lamp」和蘑菇「champignon」組成。而中文不存在詞根對應,也不存在詞根拼接融合,所以這種構詞法所產生的詞必須考慮其所指代東西的更多的性質,等等。同樣,音譯的忍耐程度也比日語低許多。

其次,中文的易讀性標準也略有不同。與一些語言習慣於靈活變化同一種詞在語段中出現的形式不同(比如德語中兩個表達中國的方式),中文對於一致性和本地化的要求更高,就和上面説的一樣,翻譯的時候即使考慮的量等同甚至略高於英語翻譯到其他歐洲語言的程度,也會導致詞不達意。問題就在於,為了達到本地化需求的低線,常常會導致「bikeshed」問題,而原因就是考慮的量過多了。而過多是否必要呢,這還無法regularize。雖然仔細討論通常結果不會太差,可讀性也會有所提升,但是付出的精力真的多於英語翻譯到其他歐洲語言。

以及,中文的機器翻譯依然不成熟。機器翻譯達不到那個本地化需求的低線,因為目前較為靠譜的機器翻譯都是基於機器學習的,即大方向抓住,但也只抓大方向。那自然,一些小詞的一致性也就沒法保證了,也就達不到上述的那個低線了。除了選詞差異,更大的問題其實就出在語法差異上了,也就是分析語(孤立語)和屈折語的區別了,比如動詞。中文裏動詞是沒有標誌的,英文裏動詞和名詞的標誌也不明顯,對譯的時候機器翻譯也自然沒法勝任判斷詞性的工作,比如「Tropical fish flops」。

至於熟語,嗯……自然,也沒法保證。使Here be dragons都可以變成「ドラゴンになれ!」的英-日機翻,我覺得足以説明問題了。

因此,中文的本地化工作,必須得有不缺一點點心眼的人。顯然,不可能每個方面都做到完美,所以對於Minecraft,只能説是必須得有一個熟悉Minecraft的方方面面,經驗也足夠的人了。

譯名標準化[]

……據我所知,Minecraft是唯一能夠讓玩家自己參與譯名決定的較熱門遊戲。透過本地化平台Crowdin,每個普通玩家都可以提交自己最滿意的譯名,此乃民主。但弊端也很明顯:面對龐大且複雜的玩家群體,能夠找到十全十美的譯名基本上是不可能的事情。譯名的誕生(例如地獄合金、Creeper等)免不了曠日持久的爭論。每個人都渴望得到Proofreader這個職位,但沒人能保證Proofreader不專斷,因為他們掌握着譯名的生殺大權,對待普通玩家的態度取決於自己。另一方面,由於譯名經常不能令人滿意,爭執、口水戰甚至是決裂是容易發生的事情,因此我們能做的只能是遵循少數服從多數原則,挑選出儘量令玩家滿意的譯名。設立譯名討論群,目的是為了將高質量玩家聚集在一起,在遵守群規的前提下和諧而有序地討論譯名。我們應該做的是團結起來,設法化解Mojang給我們帶來的挑戰,而不是為了一個譯名爭得你死我活,兩敗俱傷。

——引自User:Lxazl5770/Translation,最後更新於2020年6月6日,經過一定修改

中文Minecraft Wiki在還沒有Java版本地化的時候便啟動了譯名標準化項目。現在,這個項目現在便直接與Crowdin掛鈎,直接透過遊戲本體推送出去。

但是,譯名標準化項目的決定流程也逐漸地由於Craft Lawrence等人的小圈子式決定出現了一些問題,而做出了使決策變得更開放、民主和拖沓的改變。類似於地獄合金述詞等譯名的決定就足以體現拖沓這一性質。

就拿述詞來説?[]

這個詞一開始並沒有出現在語言檔案裡[來源請求],於是翻譯這個詞主要是為了Wiki的譯名標準化。

這個詞語作為例子,主要體現的是Wiki在面對技術性專有名詞時的拖沓。

首先爭論的點是……關注度。「述詞」這個詞,初期共識主要是「不知所云」,於是大家主要在找一些其他的詞彙去替換,比如「判據」,「斷言」等等。

慢慢地,在這個層面的辯論行不通了,大家便又把重點放到了「準確性」和「對應性」上。「述詞」的好處就是,他和「Predicate」一一對應,在一些GB/T檔案[來源請求]中也將「述詞」定成了Predicate的翻譯。「斷言」(對應assert)則相對的被認為是概念轉移,可能會導致歧義,諸如此類。

後來chyx等一些人又提出「Predicate」這個概念可能和離散數學的述詞有相似性。提出後,一部分人堅持選擇「述詞」。

後來……Crowdin上其實有了字串,於是就真的得定了。最後就定成了述詞。

但是,此時SPGoding等人的教學已經用了斷言/其它譯名了。

他們給出的理由也很簡單,從邏輯角度上,整個Predicate檔案是個table,而每個Predicate檔案裡的predicate才更像述詞。

目前,Predicate的譯名已定為「述詞」。

看到這裏你可能會疑問,為什麼別人用了其它譯名就不行?

我説不清楚,但是「譯名標準化」,我想這五個字應該能夠説明為什麼會爭吵成這個樣子,吧。

譯名群工作標準化的幾個設想[]

個人認為譯名討論由於各種原因暫無法regularize,故先擱置一段時間。

這一週想了一下,譯名群的工作流程大概是這樣的:

  给出Context->提出译名->讨论译名->得出译名

但實際情況是:

  给出Context
  提出译名          ->       得不出译名
  讨论译名

而以上三個流程,相互促進,相互作用,也就是:

沒有討論就沒Context,沒提出就沒討論,沒Context就沒得提出。

舉個例子吧,Netherite是咋樣的呢?

首先,我們有一個最基礎的Context,就是詞根。詞根是語言本身的屬性。

然後到了遊戲事實,也就是材質啊功能啊這些。

然後到了思維發散,也就是類似於在「Minecraft小説世界觀」下的討論,比如某位mnjs提出的岩棉,比如地獄玄鐵。

然後,Context幾乎發掘完了,就只能討論了。

結果是,既然沒有Context提出了,那就只有做選擇題了,結果沒得選。

大家:然後要不我們再提點譯名?然後還是沒得選。

然後大家:「那就只有做選擇題了」,但是沒得選。

然後,大家:pow定了地獄玄鐵?

大家:那我覺得不行,我覺得blablablabla……

但是還是沒得選啊,於是pow給了個投票。

大家:那……就地獄合金吧.jpg

例子給到這裏。

基本上就是,幾個階段並行,不好拆開,但不拆開又很混亂。

設想1[]

透過檔案把流程規定好。

這個方案好像很合理,但是不符合實際。實際情況就是上面這樣,遇到一個很有爭議的就會很麻煩。

小圈子性[]

中文Minecraft Wiki的編輯者多集中活躍在管理群內,而管理群需要Gamepedia賬號(在登入系統合併後不再是障礙)才可進入,且入口並不明顯。這是出於便於管理和躲避閒人的目的,但是在一定程度上限制了吸收新鮮血液的能力。

中文Minecraft Wiki相較英文站來説,活躍編輯者不多,這導致很多工作無法及時完成,但同時,很多事情的決定變得短平快,相較於英文站點迅速許多。

相對地,由於小圈子性,Minecraft的其他許多小圈子並不能融入,也間接導致了大家「討厭Wiki的缺點」但是卻鮮有非活躍編輯者想來主動解決的現狀。

就拿某個IP用户來説,摘要和討論頁到處説你們怎麼不努力改機器翻譯,但實際上,看到就改就慢慢沒有了。還好,他還知道改,更多的人可只會抱怨。

Advertisement