程式設計世界出現了一項新的語言實驗： Rost ，這是 Rust 程式語言的德語版本。該專案允許開發者使用德語關鍵詞、函式名和習慣用法編寫 Rust 程式碼。雖然最初是作為一個幽默專案建立的，但它引發了關於程式語言本地化和英語在程式設計中主導地位的嚴肅討論。
本地化程式語言的認知斷層
社群反應中最引人入勝的見解之一是，許多德語母語使用者發現翻譯後的程式碼出奇地難以閱讀。儘管他們精通德語，但許多開發者表示，程式設計概念在他們的思維中與英語術語緊密關聯，以至於德語等效詞彙感覺陌生且違反直覺。
「作為一名德語母語者，閱讀這些程式碼示例出人意料地困難。似乎程式語言中所有常見概念，如訪問修飾符、型別等，在我的大腦中都與它們的英語術語緊密相連。」
這種認知斷層不僅限於德語。許多開發者表示，無論其母語是什麼，他們都會將作業系統和應用程式切換為英語，因為他們發現本地化的技術介面令人困惑而非有幫助。
歷史先例和實際問題
社群討論揭示， Rost 並非首次嘗試程式語言本地化。微軟在20世紀90年代曾為 MS Office 宏命令推出過本地化版本的 BASIC 。這一實驗被廣泛認為是有問題的，特別是在不同語言版本之間共享程式碼時。
Excel 函式名稱的本地化仍然是一個特別有爭議的例子。公式 SUM() 在德語版本中變為 SUMME() ，當電子表格在不同語言設定之間共享時，會造成相容性噩夢。一位評論者描述了收到一份帶有日語公式的電子表格時的沮喪，突顯了本地化如何阻礙而非促進協作。
數字格式約定帶來了額外的挑戰。在德語中，逗號代替小數點，這迫使在函式引數中使用分號代替逗號。這些連鎖變化造成了嚴重的可讀性問題和潛在的錯誤風險。
類似的本地化程式語言專案：
- Rouille - Rust 的法語版本
- Rdza - Rust 的波蘭語版本
- UniRust - 在同一檔案中支援23種不同語言
常見的翻譯挑戰：
- 關鍵詞長度（例如，"benutze" 與 "use"）
- 數字格式（小數點與小數逗號）
- 引數分隔符（逗號與分號）
- 函式命名慣例
- 上下文相關術語
文化和工作場所維度
除了技術考量外，討論還涉及文化和工作場所動態。一些評論者指出，在德國，員工對工作場所語言使用有權利，當德語使用者行使其使用母語交流的權利時，這可能在國際團隊中造成緊張關係。
其他人則反駁了這一特點，引用了像 SAP 和 Qt 這樣的德國大型科技公司即使在德國也使用英語作為官方工作語言的例子。這反映了一種務實的認識，即在全球技術領域，共同語言有助於協作。
該專案還促使人們思考文化遺產和語言保護。雖然一些人認為英語主導的程式設計是不可避免且實用的，但其他人則表達了對文化同質化和技術領域語言多樣性喪失的擔憂。
多語言程式設計的未來
機器學習和現代計算能力是否最終能解決歷來困擾程式語言本地化的挑戰？一些評論者建議，翻譯層可以讓開發者用自己喜歡的語言編寫程式碼，同時保持與通用內部格式的相容性。
像 UniRust 這樣支援在同一檔案中使用23種不同語言的專案暗示了這種可能性。然而，其他人仍持懷疑態度，指出語言的細微、依賴上下文的性質使得完美翻譯變得困難。
隨著程式設計在全球範圍內變得更加普及，標準化和本地化之間的張力可能會持續存在。雖然英語目前主導著程式設計，但像 Rost 這樣的實驗即使最初只是玩笑，也讓關於計算領域語言多樣性的對話保持活躍。
與此同時，德國開發者可以決定他們是喜歡編寫 wenn 還是 if 語句，因為 Rost 與英語版 Rust 完全相容，允許他們根據自己的喜好混合使用語言。很好！
參考：rost