如何搭建一個多語言 Discord 伺服器

大多數多語言 Discord 伺服器都以錯誤的順序做出同樣的兩個決定：先選一個翻譯機器人，然後才發現自己的頻道結構和它不匹配。反過來做其實更划算。

1. 一個共用頻道，還是每種語言一個？

一個帶內嵌翻譯的共用頻道，在伺服器活躍語言不超過兩三種時都能正常運作。超過這個數量後，每則訊息後面都會跟著好幾則給別人看的翻譯，無論讀的是哪種語言，這個頻道對所有人來說都變成了噪音。

每種語言一個頻道，中間用訊息互相轉發，能讓每個房間都保持自己語言的可讀性 - 代價是把原本在一個地方進行的對話拆開了。大多數伺服器都是從共用頻道起步，之後再把流量大的語言單獨分出去，而不是一開始就分開再合併。

2. 預設公開，還是按需查看？

把每則翻譯都公開發布的機器人最容易設定，也最容易變得難以負荷。一旦頻道活躍起來，大多數成員其實並不需要那些貼在他們本來就看得懂的訊息下面的大部分翻譯。

另一種方式是按需：成員主動請求翻譯 - 一個按鈕、一則指令 - 只有他自己能看到結果。兩種方式都不是普遍正確的。公告或支援頻道通常希望翻譯預設對所有人可見。節奏很快的閒聊頻道通常不希望這樣。

這是按頻道做的決定，不是針對整個伺服器的。需要廣泛可見性的頻道和需要保持安靜的頻道，很少是同一批頻道。

3. 伺服器變大後真正會出問題的地方

可以預見地有兩件事，而且在評估任何機器人時，這兩個問題都值得分開檢查：

• 頻道噪音 - 上面已經說過。要靠選擇發送方式來解決，而不是靠少翻譯。
• 情境丟失。 逐則訊息翻譯的機器人會丟失讓活躍對話變得可以理解的「它」之類的指代關係。這是翻譯品質的問題，不是頻道結構的問題 - 無論怎麼重新安排頻道，都無法修復一個看不到對話最近幾則訊息的機器人。

確定結構之前的簡短檢查清單

• 是不是每個頻道都需要相同的發送方式，還是因頻道而異？
• 頻道節奏變快之後，機器人的情境處理能力會不會變差，還是不管流量多大都能讀取最近的歷史？
• 如果一開始用一個共用頻道，之後需要把某種語言拆分出去，機器人能不能不用整體重新設定就做到？

Pigona 用四種可以按頻道組合的發送方式回答可見性問題 - 公開回覆、按需公開的旗幟反應翻譯、按需私密的按鈕面板（翻譯按鈕），或者每種語言單獨的中繼頻道 - 並用包括免費方案在內所有方案都提供的智慧上下文引擎回答情境問題。看看每種發送方式是如何運作的。

在你自己的伺服器上試試這種結構

免費方案使用的智慧上下文引擎和其他方案完全一樣 - 足夠在決定結構之前，測試哪種發送方式真正適合某個頻道。