moedict

RS 22:10:38

今天晚上 @gpx.jordan 和大家討論台灣翻譯資源的經營，以及微軟語言入口網站的潛在替代方案////
https://g0v.hackmd.io/sQ6DFqweS_OWY6A6GpiFLQ

❤️ 1

阿維 22:10:42

@gpx.jordan has joined the channel

阿維 23:21:08

感謝您的整理！
因此目前的目標，會放在盡快完成詞彙庫的建置，透過共同的詞彙的建檔，來塑造成可供循環的使用，會是當務之急。

如果有興趣的朋友還請提出構想，我們就盡可能規劃所有細節吧。

🙌 1

阿維 12:35:58

2天前Eric Sun（孫賜萍）老師有約了他兩位朋友，要跟我討論我所提出的想法，我也邀請了Dofi Lo、irvin、姜柏任3位朋友參與討論。

我認為如果要讓這個專案成功的進行應該要有短中長期的規劃，透過階段性任務的完成，逐一的爭取各階段所需要的支援，盡可能發展更多的可能性。

短期目標：
建置可供取代「微軟語言入口網站」的詞彙查詢資料庫，並且藉由匯入「自由軟體/商業軟體」各領域，現有完成的翻譯專案之語言檔詞彙，經過相互審核的機制，順便做最終校對的作業，經過審核來正式上架，盡可能累積可供查詢的資料量，提供使用者查詢。

詞彙查詢資料庫的程式架構：
因為人工建檔耗時費力，各程式的語言檔格式也不盡相同，因此還是希望能夠使用「Transifex」和「Crowdin」這兩個商業翻譯平台，對於語言檔的資料建置跟編輯功能，至少先針對主流語言檔格式的檔案進行匯入跟控管，這樣最起碼能夠增加參與者的參與意願。

匯入介面的程式架構：
匯入語言檔：
支援的副檔名：
.ini
.php
.po
或其他常見的語言檔副檔名

程式運作原理：
必須要有先上傳英文原始檔，並且在系統判讀原始檔的語言變數功能，在資料庫建立相關的欄位與原文資料，接著再讓使用者上傳正體中文語言檔，並且經過判斷語言變數填寫對應的翻譯結果來完成詞彙庫的建檔。

建檔者資訊：
譯者姓名/翻譯團隊名稱：（必要欄位）
網址：（可選填）
電子郵件地址：（必要欄位）
軟體名稱：（必要欄位）
軟體類型：（必須選擇）
來源隱私保障：（必須選擇）

程式運作原理：
透過資料的建檔，讓譯者姓名/翻譯團隊能在提供詞彙庫資源的同時，可以自由選擇是否要公開軟體名稱。

如果是商業軟體有所謂的智慧財產不希望被完全掌握，那麼他可以選擇不要公開軟體名稱以避免被其他人反解原文，自行拼湊出完整的語言檔。

對於翻譯專案的詞彙清單，譯者姓名/翻譯團隊也有權利是否要開放哪些詞彙供使用者公開查詢，因此可以透過刪除，或者是勾選哪些語言變數的翻譯結果要來公開跟儲存，並且提供編輯的權限。

詞彙查詢資料庫前台查詢介面：

基本查詢架構可以參考「微軟語言入口網站」的做法：

搜尋詞彙
輸入字詞
來源語言
目標語言
所有產品
搜尋

但因為我們只需要匯入英文原文的語言檔作為原文的查詢來源，所以我們不需要語言來源的選取功能，相對的為了避免伺服器的系統資源負擔，我們可以考慮取消[所有產品（所有程式）]的查詢條件，為此開發[完全符合]跟[部分符合]的查詢條件，來透過這樣的搜尋條件，減輕系統資源的負擔。



詞彙搜尋結果：

我們也需要參考「微軟語言入口網站」的做法：

總之，有兩個重點：
「Microsoft 詞彙集」我們可以改成「翻譯詞彙集」
「英文」跟「譯文」這樣的表現方式當然沒問題，但是在「定義」部分，如果譯者/翻譯團隊願意在任何一個語言變數字串的「定義」欄位填寫資料，那麼在查詢時，就可以搜尋到有關該詞彙的翻譯建議或者是看法。

「Microsoft 本地化產品中的翻譯」我們可以改成「詞彙正體中文翻譯建議」
呈現結果也相同，但是軟體名稱是否要公開就按照譯者/翻譯團隊當初的選擇來做處理，如果選擇公開，就可以在這個地方知道這個翻譯結果來自哪個軟體翻譯專案，如果不選擇公開，就會變成空白。

雖然學習知識不應該要受到任何限制，但是為了保障系統資源的穩定，無論是資料的建檔，或者是查詢都應該要註冊帳號，這樣才能夠避免系統過度的消耗，在這當中也應該要考慮是否要限制每分鐘，或者是特定條件的查詢次數，因為微軟的問題，就是因為太多人使用造成系統的嚴重不穩定才導致今天的結果。

如果有任何意見，也歡迎提出，畢竟我只是一個拋出議題的提案者，還請各位的參與！

❤️ 1 1 👍 1

chewei 03:24:59

補充共筆頁面
https://g0v.hackmd.io/sQ6DFqweS_OWY6A6GpiFLQ

阿維 10:08:29

感謝補充。