您在這裡
使用者登入
最新文章
回應
3 年 5 個月 之前
6 年 5 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
6 年 6 個月 之前
Re: 他山之石:团结中文翻译力量
做中文化的人心臟要強
LDO 本身也存在一些大問題,除非你很狠心,只要不好的字串都刪除,否則建議字量不斷上升,之後你也不能監測新加了什麼
本來很簡單的事會變得超複雜
我簡單說一個例子就好了:
如果今天有人提交一個 PO 檔案,ADMIN 很勤力花數小時把它們都審核了
明天,有人又提交同一個 PO 檔案,ADMIN 是需要重新花相同的時間,重新做一次同樣的工作
最需要換的是 Localization server Maintainer (l10n_server),換一個真正有做翻譯工作的
Re: 他山之石:团结中文翻译力量
說句難聽的話,MO / PO 就像是史前怪獸,在網路還不發達前就存在的東西,如果不能自動分類處理,會造成管理者重大的負擔~
Re: 他山之石:团结中文翻译力量
未審字串真的是多到嚇死人............一△一|||
Re: 他山之石:团结中文翻译力量
其實對於中文化,一直有一個疑問:
我這樣假設好了,有十家以中文為主的 DRUPAL 公司,按理他們都需要中文的界面系統,但 DRUPAL 7 的中文化程度是不完整的,為什麼沒有人願意完成這工作??
#1. 是不是根本不需要?
#2. 自己私下做了, 沒有開方精神?
Re: 他山之石:团结中文翻译力量
我同意中文化工作像 Kay 在一樓講的那樣,是非常麻煩且龐雜的工作。
不過我想區分一下 Drupal core 和 contributed project 兩者翻譯工作的不同。
Drupal core 的內容較為單純、數量較穩定,翻譯起來的品質會比較好、速度也較快。每次主版本釋出的時候辦個 translation sprint 就可大致搞定。
但 contributed project 的情況就不是如此。除了數量多,最麻煩的是許多常用、熱門模組本身的功能就非常抽象、一般,又能夠被組合起來完成多種不同功能,其結果就是產生多元與紛雜的應用脈絡。
要怎麼針對這種本質上多元的應用脈絡而做出統一的翻譯呢?這本質上就不太可能。硬做也只能將就著用。
實例比方說 Views 被翻成「檢視」、Flag 被翻成了「檢舉」,這種單一功能的翻法對管理者和網站開發者來說根本是一種負擔而非便利,因為最後還是得重新翻譯或另做選單才能交給客戶使用。
對於新手來講,這只會讓已經很陡峭的學習取現變得更加難以攀越。對老手來說,只匯入 core 的翻譯、其他保留英文介面,在使用上會更為方便、減少混淆。
更別提這對於翻譯審核者來說是多麼困難的工作了。審核者不是只要檢查翻譯的「字面意義」有沒有翻對而已,本身還得對模組/版型的功能要知之甚詳,才能選擇出恰當/堪用的翻譯。問題是,按照 drupal project 產出、更新和改版的速度,審核者要不交差了事,要不就是累死。況且審核的結果大家還不一定滿意。
我認為這就是造成中文化翻譯工作難以進行、少人去做的原因之一。(當然大家懶、Drupal 本身的多語機制複雜難解也是原因)
這個問題有沒有解法呢?直接用機器翻?建立一個伺服器蒐集全球使用字串、按照統計結果來給出最佳翻譯?組織一個翻譯團隊,完成巴別塔計劃?
對這問題有興趣的人,可以去 James 發起的 Drupalcamp Taipei BOF 「Drupal中文化計劃」提供你的建議。