2009-10-02 84 views
3

在你開始閱讀,這裏是一個related question,但恐怕缺乏細節......翻譯過程

我的情況很簡單,我在網站上,在不同的語言翻譯工作。我們根據客戶的需求定製了各種網站,他們選擇最適合其目標受衆的語言。

但是,我們在翻譯過程中遇到了問題。問題不在於版本控制(畢竟我們是程序員)或數據庫佈局,我的確在談論管理翻譯,成本和事故。

我認爲我們已經確定了目前爲止的3個步驟。

1.準備要發送的文件
通常,你希望這是自動的。這是對這個循環任務

2.翻譯浪費人力資源的痛苦
也不是那麼容易的實際轉換,有各種(和公開)的問題有:缺乏上下文的例子,因爲自然語言可能是不明確和使用同義詞沒有幫助(特別是因爲我們必須給英語作爲基本語言,我們是法國隊,所以我們可以不使用成語)

3.集成/反饋
典型的問題是將一個單詞(用於按鈕)翻譯成整個句子,讓我放棄我們要求譯員不要把長度增加25%以上,但有時甚至可能會破壞所有地獄,有時甚至會在空間有限的情況下限制他們。

我想知道你是如何處理國際化這一重要步驟的。我們對此有幾個頭腦風暴,但沒有任何結論出來。

我會在下面的回答中給您介紹我們當前的流程,以便問題和答案可以獨立進行投票/評論。

問候。

回答

1

這是我們目前的過程。

1.文檔

送2個文件:
+ Excel電子表格,包括一個 '身份證',對於英語翻譯1列,然後1爲每種語言列1列。必要時使用'NOT TRANSLATED'字符串,並重用我們已有的字符串。腳本負責索引字符串並創建此文檔(生成我們導入的.csv)。
+一個PowerPoint文件,包含使用包含每個字符串的'id'的'假'翻譯文件製作的應用程序的各種屏幕截圖,它用於爲翻譯人員提供上下文,因此他們對可用空間進行了粗略估計。

這裏的問題在於PowerPoint文檔中,每次有變化時都需要人工干預來更新屏幕截圖。此外,由於條件或互斥元素,幾個屏幕實際上可能會有所不同(所以我們必須生成一些屏幕變體)。

2.翻譯

除了需要時間的事實,我們沒有太多的知名度,因爲客戶端是負責的措辭(我們只提供一個默認的,他們必須使其適應自己自己的詞彙/品牌),從而翻譯。

顯然使用了PowerPoint文檔,但可能沒有我們所希望的那麼多。翻譯團隊似乎儘可能快地工作,並且提及一份文檔(以及查找時間)不僅打破了流程,而且增加了大量開銷。

3.集成/反饋

更多的,往往不是客戶端是不太滿意的翻譯。有些人可能會打破布局,其他措辭不好,並明顯暴露出缺乏對背景/情況/領域的理解(並非我們可以在那裏做很多事情,我不會說芬蘭語......)

我們曾經想過我們的流程,並兩點已經提出:

  • 更新截屏所需的人工干預是昂貴
  • 這將是有益的,如果翻譯者有更直接的反饋

儘管如此,我們有h廣告幾個想法:

  • 在PowerPoint中殺死我們,但譯員所需要的背景下(當然,我們也希望他們更多的使用它...)我們曾經想過在Excel電子表格中嵌入一個「語境」列給出這種背景下,但它似乎是一個可憐的替代品
  • 已有提議用網站的'生活'演示替換PowerPoint文檔。這個想法是發送網站的靜態副本,併爲需要它的屏幕提供一些變化。然而,如何構建這個副本併爲其供電是另一個問題,我們不希望人爲干預來更新屏幕...
  • 如果我們可以完全自動化第三步,我們可以爲翻譯員/客戶端提供一個沙盒以便他們可以在更緊密的循環中處理翻譯。

正如你所看到的,這確實是一個懸而未決的問題,是的,我們真的有很多想法。爲了解決這個問題,當然還有一個預算(金錢/時間)的問題,在這個問題中,這個任務並沒有成爲我們管理層的優先事項,因爲畢竟它現在不能工作得如此糟糕......

I期待您的評論。

2

我對此有一些經驗,因爲我公司的產品支持20多種語言。 有2個方面:

  • 在預裝軟件
  • 內部口令數據庫管理

處理翻譯上的預裝軟件處理的翻譯,我們用一個短語的ID代碼時,使用一個短語。在運行時,s/w可以根據語言ID和短語ID來查找實際的短語字符串,並加載它。當查詢失敗時(例如,在嘗試加載中文短語時缺少中文短語db文件),總有一種默認語言(例如英文)可用。 如果翻譯後的短語比預留的空間需要更多的空間,我們有一個實現這種效果的自定義控件:將字體顏色變爲藍色,並用省略號結束文本,當客戶單擊文本時,提示窗口顯示全文彈出。

對於內部的短語數據庫管理,我們開發了一個網站門戶,開發人員可以在那裏查看翻譯是否可用。如果是的話,他抓住短語id並繼續他的項目。如果沒有,他申請一個新的短語ID並返回到他的項目與該ID沒有被實際翻譯阻止。在應用程序中,開發人員可以添加諸如圖片,doc文件,簡單文本等上下文。該網站會向譯員發送翻譯請求,並通過電子郵件向管理員發送此類請求的通知。一切都是自動的。

該網站還定期生成翻譯數據庫文件,或根據要求包含在發貨的S/W。

+0

確實非常好的想法。你對「太長」的句子有什麼樣的通知(或者在把它放入數據庫之前進行預先檢查)。我喜歡關於翻譯的中央存儲庫的想法,目前我們仍然難以知道自上次翻譯以來增加了哪些內容(我們確實有差異,但管理會更好)。 – 2009-10-12 14:16:08

+0

我不需要太長的通知。這個短語可以在任何地方使用,所以當字體等上下文被確定時,字符串的長度纔有意義。在運行時,我們使用GetTextExtentPoint32()等API來比較文本長度和包含控件。 關於差異,我認爲跟蹤比差異更好。通過跟蹤我的意思是爲每個短語附加一個唯一的ID,並將所有更改歷史記錄保存到此ID。這就像一個帶有許多可空字段的數據庫記錄,每個語言只能用於一種語言,只在需要時才轉換爲該語言。 – 2009-10-13 05:52:17