请查看这个翻译相关的 PR。 https://github.com/libredb/libredb-studio/pull/1052

我單純說自己的偏好，沒有說一定正確：其實我不喜歡多語言 readme

我覺得 readme 應該以英文，或是主要使用者會用的語言為主 (比如你預期你的專案是中文圈的人會用，那就用中文) ，理由其實就是寫 code 的人不一定會翻譯，如果要維護多份其實沒有能力審查 ，叫 AI 翻也行啦，只是你也只能相信 AI 翻的正確了

我覺得 readme 應該是給來看 code 的人看的，不是給來使用的人看的，你完全可以在 readme 上加上多語言的連結，把這些使用者全部導到網頁版的文件去，然後做多語言版的文件，你可能會想這有什麼不同，但我覺得不一樣，網頁簡單的你可以另外開一個 repo 放網頁版的文件，然後讓使用者來貢獻翻譯，或是用像 Crowdin 那樣的社群翻譯的工具，用工具翻譯有好處，你的原文改了 Crowdin 上就會被標記成過時的內容，必要時可以逐頁 fallback 回英文版

我個人只會看完整版確保不會漏東西

簡轉繁有繁化姬可以連帶將常用用語轉成台灣的用法

我會把「齊全但過時」排在「精簡但正確」後面。文件錯比文件少更傷：讀者不知道哪一段已經不準，整份的可信度就垮了。所以英文當 single source of truth、其他語言維持精簡並明確導回英文，是合理的預設。

如果想收下那份完整簡中翻譯，又不想養出六份全職翻譯，可以用低成本的方式盯住新鮮度：每份翻譯在檔頭記下它翻譯時對應的英文版 commit hash，CI 比對英文 README 在該 hash 之後是否有變動，有就自動開 issue 或在頁首標「本翻譯對應英文版＜日期＞，原文已有更新」。翻譯不用即時跟上，但落後是可見的、可以認領的，而不是悄悄爛掉。DanSnow 提到的 Crowdin 本質上也是把「哪段過時」變成系統狀態；純 markdown 流程用 commit hash 可以做到同一件事。

繁中的部分：簡轉繁加一份用語對照表（内存→記憶體、程序→程式、默认→預設、信息→資訊）大致夠用，工具鏈成熟，可以先從這裡開始；如果台灣使用者夠多、有人願意長期認領，再考慮獨立的繁中版，語感還是有差。

原則上是這樣，一律只將英文版先處理好，也只有英文版才是人工修正的。

其它語言的走向，得先決定好方向。「直譯」或是「轉譯」

直譯來說，會比較容易也比較單純。也就是不管文法通順，直接翻譯就對了。
但相對的，就有可能會發生文法或語意不通順或誤解的問題。

轉譯來說，則是需要由懂該語言及英文的人才來處理。
先讀懂英文的本意，再將其依意思重新解釋翻譯。
但這就得對應相關的人才。雖然現在也可以靠AI來處理。
不過現今的AI還只能做到直譯後重新解釋，並不一定很完整。

再加上技術性的文案中，有可能會有些專有名詞。有些名詞並不太適合轉譯。最好還是維持原英文。