我們不需要翻譯更正:我們的翻譯人員更清楚應該如何翻譯

這篇文章試圖聯繫出版商。 以便他們更負責任地聆聽和對待他們的翻譯。

在我的開發過程中,我買了很多不同的書。 來自不同出版商的書籍。 既小又大。 首先,大型出版社有機會投資技術文獻的翻譯。 這些書非常不同:我們都經歷過或正在經歷尋找自我的旅程。 所有這些書都有一個共同點:它們的翻譯方式讓人無法閱讀。 當然,隨著時間的推移,您會習慣術語的翻譯(默默地翻譯為每天使用的術語)和破碎的演示風格,從中可以清楚地看出,本文來自英語。 然而,出版商對流行出版物的定價沒有習慣。

我們不需要翻譯更正:我們的翻譯人員更清楚應該如何翻譯
邀請出版商發表評論。

我們來試著理解一下什麼是書? 我們以一本 600 頁的書為例,這在 IT 出版品市場上是平均水準。 根據大型出版社使用的契訶夫印刷廠的價格標籤,印製一本相當於 175 盧布。 以印刷為例,2份相當於000萬盧布。 此外,如果你買一本流行書,它的價格約為350盧布。 那些。 該出版物將收到 (000 - 1) * 500 - 1% = 500 盧布。

但出版有很多費用。 以下是我可憐的計算嘗試,但彼得出版社在評論中進行了更詳細的解釋。 從評論+連結複製到評論:

我可悲的努力

  • 支付倉庫費用;
  • 用於從印刷場到倉庫的運輸;
  • 經銷商服務(據我所知,每本書大約150盧布......但這只是幻想)
  • 翻譯和編輯服務;
  • 某個小比例──整個出版團隊的薪水(書很多,所以比例很小);

回答 IMnEpaTOP。 還有更多 許多其他有趣的事情,我建議閱讀

  1. 您忘記了向版權所有者/作者付款(預付款+版稅)。
  2. 您計算的稅金不正確(低估)。 有增值稅,有實際稅收。
  3. 您沒有考慮“週轉率”,它決定了保證金要求。 正如您自己所注意到的,這本書一個月後還沒有出版。 流通量一個月不賣。 而且從一開始的成本就相當龐大(預付款+管理,先於檢索、接受出版、取得權利)。 費用伴隨著這本書,直到最後一本售出。 如果出版物不能產生比其他投資方法更多的收入,那麼出版社為何存在?
  4. 如果你有一個團隊,那麼就有一個辦公室,他們在某些電腦上工作,等等......他們的維護需要花錢。
  5. 員工薪資只佔很小比例的假設只有在書籍確實很多的情況下才有意義。 但如果它們有很多,它們不可避免地會受到很少的關注(這是你不喜歡的)。 而如果工作中的書籍很少,那麼這些費用所佔的比例就不能小。 一般來說,該費用項目會動態地佔用讀者願意為其支付額外費用的金額。
  6. 商業風險。 並非所有書籍都按計劃銷售,這意味著,充其量,並非所有書籍都能獲利。 而且,並不是所有的書都賣完了。 當然,所有這些風險都透過所有出版書籍價格的上漲來計算和補償。 因此,流行書籍為不成功的書籍付出了代價。
  7. 您計算中最糟糕的一點是經銷商佣金。 不固定150r。 它根本不是固定的。 出版商大量運送書籍。 網路以任何被認為合理的價格上架。 根據您的計算,發布商的價格標籤增加了約 10%。 這與事實相去甚遠(相差好幾倍;出版價漲幅可達60%,都是批發商佔為己有)。

因此,會有疲憊,但不會精彩。 例如,500,000 份副本中的帳戶最終將獲得略高於 2,000 盧布的金額。 從大企業的角度來看,金額並沒有那麼嚴重。 因此,出版商開始省錢。 例如,在上面的清單中,我沒有指出由母語人士對本書所涉及的技術進行校對。 為什麼? 因為出版社給出了這樣的模式:“技術專家免費校對一本書,糾正它,糾正它,作為回報,他們在沒有人閱讀的地方以小字印刷了自己的名字。” 對某些人來說這是一種自我重要感,對另一些人來說則是降低成本。 聽起來不錯,如果不是因為一個「但是」。

出版商不需要我們的編輯。

不是每個人都知道,但我知道 小工作,我時常寫的。 它位於 github 上並根據免費許可證分發。 透過這項工作,我聯繫了兩家出版物(我不會透露名字,但他們的書在你們的書架上)。 早期我第一次嘗試上訴,當時寫了30%。然後,經過很長的通信(大約80封信)後,我們爭辯道:

  • 我想要自己的封面,這是我從 Lebedev 工作室的設計師那裡訂購的。 他們不是;
  • 他們希望我從 github 上刪除這本書的所有副本。 這是不可能的,所以我就辯稱不可能;
  • 我想保留單獨出版英文版的權利。 他們實施了一項禁令,理由是如果一家英語出版社與他們接洽,他們不想放棄從中賺錢的機會。 但從未聯繫過他們.
    我要求更改合同,但他們這樣做的方式是,從表面上看,我的所有內容似乎都可以單獨以英文出版——在不同的出版社。 但事實上,沒有。 談話就這樣結束了。

我聯繫了另一家出版物。 他們要求閱讀文本,我發送了。 他們提出了條件:

  • 這本出版物將花費我 200,000 萬盧布。
  • 500份起
  • 低密度紙(新聞紙,當字母可見時);
  • 出售時 - 45% 給我,55% 給他們。

同時,他們的翻譯也對作品進行了檢查。 那些。 這是什麼意思?

出版社沒有程式設計師。 相反,有人做技術翻譯。 該出版社的管理階層中沒有程式設計師。 這是什麼意思? 管理階層不知道文本在說什麼。 他們本質上只關心銷售。 有一名工作人員負責翻譯技術文獻。 他可能把狗吃掉了,不是嗎? 這意味著他們信任他並認為他是該領域的專家。 這個人收到某作者的一本書作為輸入,並將其與自己的經驗進行比較。 由於他在輸入時會收到一系列書籍+有些正在製作中,因此他不會太深入地研究文本。 他們寫給我的內容:

報價:「這根本不是析構函數,因為 C# 中的終結器和 C++ 中的析構函數的宣告相似,所以最初看起來可能如此。 與析構函數不同,終結器保證被調用,而析構函數可能不會被調用。”
譯者: 「C++ 中的析構函數可能不會被呼叫」這句話完全是無稽之談(更不用說使用動詞的反身形式,這裡是不合適的)。
第二部分中對異常的討論更有趣,但並非原創 - Richter 的書“CLR via C#”可能包含所有這些。 <Publisher> 翻譯的有關該主題的書中完美地涵蓋了所承諾的多線程。
作者所使用的術語也無助於本書的可信度。
但這裡還有另一個例子:從字面上看,在一頁上有一個術語(堆疊展開)的三種翻譯:提升、展開和展開。 對此如何評價?
一般來說,要以書的形式出版,你要嘛需要重寫資料,要嘛仔細編輯。

我不會假裝自己有良好的風格,沒有文法、拼字錯誤。 但是……譯者有分析技術描述中的錯誤嗎? 並且如此自信地提出重寫所有內容,並且不認為自己不知道某些事情。 答案是:

如果不從物件中釋放內存,則不會呼叫析構函數,因為將會出現內存洩漏。

與我的書中不同的是,到處都對異常進行了膚淺的描述。

作者所使用的術語也無助於本書的可信度。

這是程式設計師的術語。 您的專家是 .NET 開發人員嗎?

但這裡還有另一個例子:從字面上看,在一頁上有一個術語(堆疊展開)的三種翻譯:提升、展開和展開。 對此如何評價?

這三個詞都被積極使用。

同時,我嘗試將英文翻譯成俄文。 文字是典型的地獄。 無論是在風格上還是在術語翻譯上。 那些。 它是用俄語寫的,但不是用俄語寫的。 用英語寫的。 聽起來有點熟? 我捲起袖子開始編輯。 有時 - 在段落中。 答案是這樣的:你為什麼要這樣做? 我們更清楚如何才是正確的。 我們的翻譯非常好,有了他就不用再看風格和翻譯了。 只有一些術語、程式碼清單。 沒必要在翻譯上浪費時間。

如何

為我翻譯成英文 巴托夫。 他和他的團隊採取了完全不同的方法。 因此,我有一些東西可以比較。 他和第二位翻譯最初向我提出了許多問題。 關於繼承,虛擬表。 方法,關於GC。 他們問了很多問題,我確信他們兩個都會通過 .NET 程式設計師的面試。 然後,隨著時間的推移,問題變得越來越少。 而目前幾乎沒有。 為什麼? 因為他們想出了正確的術語。 最近他傳了這個給我:

我們不需要翻譯更正:我們的翻譯人員更清楚應該如何翻譯

說我很驚訝其實沒什麼好說的。 那些。 原來翻譯也能好? 🙂 但在一個條件下:當程式設計師的編輯與翻譯並行時,而不是在最後,出版社會為所花費的時間感到遺憾。

編輯和校對程式設計師必須與翻譯並行工作

給自己的結論

出版商不需要高品質的俄語翻譯。 這對他們來說是昂貴的。 程式設計師一邊校對,一邊做全面編輯,直到與出版商達成一致(每一段都有爭議),會過去很多時間。 甚至可能是一年。 在此期間,該技術可能會變得過時且不必要。 趁著話題很熱,這本書現在應該被丟到書架上。

另一方面,網路上充滿了文章。 免費文章。 出版社正在失去客戶。 尤其是翻譯很糟糕。 但是,親愛的出版商。 我們為什麼買書?

就我個人而言,我看書是因為書的作者與文章的作者不同,他有全球性的思考。 那些。 我對這項技術有了更深入、更貼心的描述。 我個人發現閱讀一本書比透過電子閱讀器或螢幕閱讀更容易。 沒有螢幕亮度,可以翻頁。 因為我厭倦了螢幕,我想要一些有觸覺的東西。 一本書。

因此,親愛的出版商。 印刷業的猛獁象。 譯者之間存在翻譯順序。 如果源語言的母語人士先進行翻譯,則由目標語言的母語人士進行編輯。 這對你來說並不奇怪。 這是合乎邏輯的,對你來說似乎很正常。 所以,對IT書籍來說,載體就是程式設計師。 我們需要被傾聽。 這樣後來我們讀了你的書,你在部落格和免費資訊的時代就有了收入。

只有註冊用戶才能參與調查。 登入, 請。

本書的技術翻譯:

  • 直到今天我仍然保留翻譯。

  • 我已經一年沒有讀翻譯書了。

  • 我已經兩年沒有讀過翻譯書了。

  • 我已經四年沒有讀過翻譯書籍了。

  • 我已經五年多沒有讀過翻譯書了

175 位用戶投票。 46 名用戶棄權。

關於編輯

  • 編輯程式設計師必須被傾聽和信任。 檢查但信任

  • 譯者做得很好,程式設計師不是作家,最好不要聽他們的

  • 你的版本(在評論中)

133 位用戶投票。 52 名用戶棄權。

來源: www.habr.com

添加評論