feed -> 供稿
不太確定這翻譯好壞
(重點討論由這開始看: https://localize.drupal.org/node/5878#comment-39348)
Breakpoints
常用於 Responsive 設計時的 Breakpoints,不確定常用翻譯是什麼
----------------------------------------------
討論總結
----------------------------------------------
專有名詞 (包括模組名):
格式: 翻譯 (Original name)
例子: "視圖 (Views) 是一個模組,透過視圖你能做到... "
** 注意: 首一字母要大寫
Responsive Design / Image
適應式設計 / 適應式圖片
Breakpoint
分界點
-----------------------------------------------
Groups audience:

Comments
可以討論之後確立下來
Feed翻譯作餵稿、或供稿沒錯,兩個選一個都可。
Breakpoints最常見的中文稱呼為臨界點,但是對岸的用法,我們這邊好像有人稱轉換點,但也不普遍的樣子
Responsive設計目前多數都直接引用原文不翻譯
偶有人稱自適應、響應式、適應化.....就是中文沒人翻譯的情況
但個人認為中文化的過程當中,專業用語翻得越是完整,越有利於技術的流通與普級
所以最後能夠翻譯出的就翻譯出,
如drupal的view這麼簡單一個字都不翻譯很奇怪,對岸翻譯作視圖,我們或許可以考慮「視覺」模組等等的,...
以上是個人意見,翻譯這東西可能集合眾人所見最後做一總合就可。
文字是約定俗成的,世界上沒有完美的翻譯,大家用久習慣了它就是對的。
但若是一直不給中文的翻譯,那麼他就永遠是以英文面向世人。
模組名翻譯可以再談一談 印象中,模組列表 (或某地方)
模組名翻譯可以再談一談
印象中,模組列表 (或某地方) 的模組名是不可翻譯的 (核心限制)
所以即使要譯,個人建議是以下形式:
- Views (視圖)
- 視圖 (Views)
就像一般新聞出版:
" Views (視圖) 是一個模組,透過 Views 你能做到... "
" 視圖 (Views) 是一個模組,透過視圖你能做到... "
簡體最新結果傾向不譯: https://localize.drupal.org/node/5843
初次加入不知有這事...
原來有這一事。
的確模組名稱翻譯作中文時問題很多,
最常見的是在找資料時畢竟英文多而完整,
中文資料少而稀,
所以保留不翻有很多好處。
另外,不知有沒有什麼資源讓我這初加入者可以閱讀一下翻譯之準則的?
或是類似一些標準用字?(例如一個列表列出所有專業用語的中譯?)目前我都只能用自己長期使用及搜尋歸納的方式下筆。
雖有滿腔熱情,但很怕犯了什麼忌有傷和氣。若有這些資源看了之後也比較安心。
關於格式: https://localize.drupal
關於格式:
https://localize.drupal.org/node/182
翻譯詞彙參考:
http://www.microsoft.com/Language/zh-tw/default.aspx
Drupal 專有名詞可參閱現有 Drupal Core 翻譯
不會傷和氣啦,放輕鬆 :)
** 開這 POST 主要原因是翻譯永不前進,我想加快審核。記錄下不確定的情況,往後再看能怎麼改進
** https://localize.drupal.org/node/3409
這兩個資源太棒了!
感謝!
接下來十天有些事會停一陣子。等回來時再來衝刺!
個人覺得還是這類的名詞還是做個翻譯會比較好, 但是要在後面
個人覺得還是這類的名詞還是做個翻譯會比較好,
但是要在後面加上「(英文)」,
方便習慣英文的使用者了解。
會覺得使用「視圖 (Views)」,而不使用「Views (視圖)」的原因,
是我覺得主要的重點還是在翻譯過後的名詞,
「(Views)」比較偏向輔助性質,
提供比較喜歡使用英文名詞,
或是比較難翻譯的單字可以更為了解其原意。
而還是要翻譯的原因是,
方便初入的新手比較好了解此功能的目的,
而且可能不是所有人都看的懂英文........
Feed 在繁體相關的資料比較常看到用摘要來翻譯,ex
Feed 在繁體相關的資料比較常看到用摘要來翻譯,ex RSS Feed -> RSS 摘要,
相關的稱呼或應用有: 摘要資料、訂閱摘要 等等
Breakpoint, Responsive 的確比較還沒有統一的稱法,個人的想法是:
Responsive:
我一直不知道哪個最合適,台灣常見自適應式,但還滿拗口的,不如就適應式即可。
Breakpoint:
查到了在台灣一個整理學術名詞的網站, http://terms.naer.edu.tw/
因此我認為可稱為分界點,臨界點比較常用於 critical point 這種狀態改變強烈的地方。
Feed譯作摘要並不適合
Feed 的方式很多,有全文餵稿,有長摘要餵稿,有摘要餵稿,也有只有餵標題的。[這裡中文暫用餵稿稱呼,或可稱供稿]
不能因為部落格盛行下在餵稿時多使用摘要而將他譯作「摘要」,這樣對於Feed是很大的混淆與誤解,且把其他方式的餵稿方式給否認了。
十幾年前沒有部落格時,我們在大型上稿系統上最常用的 Feed 也是這些全都有的(雖然那時沒有RSS),特別是像機構間的合作,通常並不會只 Feed 摘要,從全文、摘要、長摘要、標題,甚至讀者看不到的一些資料全都會feed 。更何況 Drupal 的 RSS 設定中如何 Feed 也不是只有 「摘要」這個選項。
如D7的RSS設定英文是這樣的:
Configure the site description, the number of items per feed and whether feeds should be titles/teasers/full-text.
若把Feed譯作摘要那麼這段就很奇怪了:
設定網站說明、每個摘要的項目數,摘要可以是標題、摘要,或是全文。<==這是什麼翻譯?
譯作餵稿或供稿至少文義是較合邏輯的:
設定網站說明、每個餵稿的項目數,可以以標題、摘要,或是全文做為餵稿。<==或許「餵稿」或「供稿」(或其他什麼別的稱呼)大家還不熟悉需要再適應,但至少不會混淆。
以上是個人對於Feed翻譯的意見。當然如何取捨還得集各方見解。
另,個人認為,Drupal是一個很大的計畫,一些翻譯用語固然以順應大眾之用語為首選,但是另一方面大型計畫亦有引領文化與端正俚俗的責任,若大眾用語不適洽,甚至對於一個用語的理解錯誤,當然改為更為適洽者為宜。
breakpoint在讀了更多資料之後認為微軟的中斷點應該算是不錯的翻譯。
Responsive 譯作適應性我也認為不錯。
供稿或餵稿這在台灣是真的沒有看過,不知道是否能夠習慣,簡體
供稿或餵稿這在台灣是真的沒有看過,不知道是否能夠習慣,簡體市場看到絕大多數是供稿沒錯。
其實我覺得 Teaser 對我來說比較像是 節錄文字,而摘要則是摘錄各項資訊於一身的結果,無論隱藏或顯示。
因此 Feed 反而更適合摘要。而 Teaser 其實比較像是預告,偷偷透露一點,吸引你看全文。
不過跟 Teaser 會有衝突是的確要考慮的,畢竟已經習慣把他跟摘要畫上等號了
但翻譯也不見得需要像代數一樣置換進去。
如果以你的例子來說,看看這樣如何
設定網站說明、每筆摘要的項目數,
摘要可以是標題 (Title)、節錄文字 (Teasers),或是全文 (Full-text)。
專業而正確應該是第一考慮
我認為對岸的翻譯是不錯的,但這不見得是他們開始用的用語,我們也不見得要因此棄之門外。
大致來說,「供稿」較雅,「餵稿」較傳神,也較貼切。 所以長久以來我兩者都會用,端視對於前後文的感覺而定。
content feed、web feed這樣的概念就是帶有「餵」,「飼料」這樣的意謂,就是有點把內容當做飼料由A系統餵給B系統。 這概念在十幾年前網路剛起時就有,只是當時可能用的是XML標準,甚至標準也不用,只要合作雙方的技術人員說好內容交換時的資料庫對應欄位或是輸出格式就可(看合作及交換資料深淺),所以Feed 與 RSS 是兩碼子事,RSS只是大概在2003年左右才興起的一種feed 標準技術之一(這時間應該不中亦不遠矣)。當然的,RSS也大大簡化了 feed 這件事,也讓它成為大小內容網站普遍使用的一種內容交換與遞送技術。
十幾年前我們在談內容合作或交換時(例如從A國子公司的CMS系統把每天更新的文章遞送到B國子公司CMS,B國的也遞送給A國,或是把內容遞送給外面合作夥伴如雅虎、MSN網站),都會用content feed 來表達這個技術,而 feed 的資料形態與類型非常多,像是標題連結,甚至短標題,長摘要、文章類型、文章頻道、是否有編輯設定....等等甚至讀者看不到的資料,後設資料 (metadata) 。
摘要絕對只是其中一個小小的部份,也完全無法表達出 feed 這個機制到底在做什麼。
我們內部在談content feed 或是與合作夥伴在談 feed 時,若用中文講則是習慣用「餵」,餵資料過去,餵資料給你,餵文章,我們要餵些什麼給你...。從來沒想過用摘要這一辭,現在回想,更無法想像這字若譯作 「摘要」,那麼內部溝通還有外界談判中文要怎麼去表達?
「摘要」不但會和drupal裡的teaser還有一般的 summary 、abstract 概念混淆,又無法表達內容交換機制的過程與概念;而中文的「摘要」一辭,更難以讓人自然對應到英語的 feed 。反觀,「餵稿」,雖然粗俗點,但很能表達出它的觀念以及機制,而且中文也很容易對應到英文的feed、fed。「供稿」雖較雅,但在表達上受限很多,且難以直覺聯想到英文的 feed。
我不知為何台灣這邊會將feed機制譯作摘要,而且成為主流用語。我只知道我長期在內容產業接觸這個字十幾年,也在實際的商業環境與談判中用了很久,若要用「摘要」這翻譯我會情願講feed就好,不翻譯出來反而較好,不可能會去接受這個翻譯,因為直覺它是錯誤而無法表達 feed 的意思。或許這也是為何 feed 在網路的流行文化中會被以「摘要」來稱呼,而在專業領域中就沒人想翻譯出而大家都說不知怎麼翻譯這個字的原因。
科技用語要達到信達雅100分的境界經常是可遇不可求的,退而求其次,一個譯詞應當先求準確,再求通俗而易理解。語言本就是一種習慣,只要翻譯正確而易理解,久而久之大家習慣就好。
關於feed 概念也可參考維基百科:
https://en.wikipedia.org/wiki/Web_feed
以上是個人接觸這字的一些實務經驗談。僅供參考。
無論如何,我還是會尊重大家的討論與主事者決定。
若有言語上的冒犯也請大家見諒,畢竟我和大家一樣都只是一個求好心切,因此斗膽直率的表達個人的一些見聞。
節錄文字 (Teasers) 在 FEED 頁面
節錄文字 (Teasers)
在 FEED 頁面 "節錄文字" 比摘要好。摘要隱含了概括內容的意思。
「餵稿」我也沒聽過。
FEED 單獨時 "供稿" 較好一點
RSS FEED - RSS 摘要 <~ 這樣我也覺得不錯
沒聽過不代表不好或不對
許多專業的文件,都是使用「餵」的字眼,只是一直未能幫 Feed 定下一個標準翻譯。
例:
該篇學術論文採用「供餵」
http://nchuir.lib.nchu.edu.tw/retrieve/122031/3-3-1-4-1.pdf
而微軟的許多技術說明頁面則用「餵送」兩字:
http://support.microsoft.com/kb/956959/zh-tw
http://support.microsoft.com/kb/941604/zh-tw
http://support.microsoft.com/kb/2804550/zh-tw
這些翻譯應該也是少有人聽過,但不能說他不對或不好。但反之,若有人去採用,那麼就會有很多人聽過,甚至變成標準。
微軟的「餵送」算是不錯而比「摘要」而更精確的用語。如果「餵稿」大家不習慣,或可沿用微軟的。另外,從以上譯名都可看到,「餵」的觀念與意涵在 feed 這個字上的重要性。
科技翻譯原本就有許多「創作」本質在裡面,從事這個工作的人,應該勇於為一個沒有人聽過,或大眾還不了解的科技英文創作出一個人人都能理解而正確的用語。
個人意見。見笑了。
Feed
Feed 同為名詞與動詞
微軟用餵送作為動詞我覺得不錯
同時文章內也不斷提及「摘要清單」、「RSS 摘要」不是嗎?
微軟的翻譯標準的確把 Feed定為「摘要」
這問題很有趣。
微軟的翻譯標準的確將 RSS Feed定為 RSS摘要。
但「摘要」真的是一個不精確的翻譯,且容易混淆,所以在中文化時經常會遇到行文走不下去的情況,這和先前我提出的Drupal翻譯上遇到的問題是一樣的。
而以「摘要」、「節錄文字」來區分feed 和 teaser,其實只是以文字遊戲的方式解決這混淆,一般使用者對於兩個中文辭彙的理解是同樣的意思,至於翻譯團隊背後自行提出的解釋,都只是在內部在自求口實,並無法在傳達語義時達到實質的區別目的:有誰看到這兩個辭能夠很自然的想到「摘要」背後還包含了內容交換、看不到的訊息交換等等機制呢?
所以我們在Drupal裡若採用「摘要」,就會像大家討論的一樣,一下要用摘要,一下要用其他譯名來輔助。
一個好的譯名,應該是能夠一體通用的來使用,理想狀態下是能夠在任何場合直接套用。「摘要」完全不符這個標準。「供稿」情況好一些些,但餵稿、餵送的翻譯,都能夠符合或接近這個標準,不需在不同場合還得用不同用語。
同意在不同使用狀態有所區分,Kay.L 上述意見我也認同
在不同使用狀態可有所區分,我認同 Kay.L 的上述意見
Responsive我超讚成寫「適應式」就好了(姆指 Br
Responsive我超讚成寫「適應式」就好了(姆指
Breakpoint現在上面大多是翻做「中斷點」,其意思還算好了解。
不過要統一的話我覺得 @amourow 的「分界點」應該會更為適合,因為此功能主要的目的是區分不同寬度的區間,帶有分水嶺的感覺,除了當下的「點」之外,還有「以上區域」、「以下區域」的概念,所以「分界點」應該會比「中斷點」更好。
大家有沒有考慮過翻譯 Breakpoint 為
大家有沒有考慮過翻譯 Breakpoint 為 適應式中斷點 ?
在D8裡應該是專指RWD這件事吧,加上適應式滿好的。 但中
在D8裡應該是專指RWD這件事吧,加上適應式滿好的。
但中斷點有停止的意味,個人還是偏好以分界稱呼他
breakpoint我投分界點一票
開始翻譯時我採用微軟的中斷點,
但後來見到大家提出的,
我支持分界點,覺得這個翻譯很棒,精確容易理解,符合信達雅的標準。
若定案我可回頭去修改所有的翻譯。
看大家意思,基本上可以定為: 分界點
看大家意思,基本上可以定為:
分界點 (Breakpoint)
大家是否同意以下兩點: 專有名詞 (包括模組名): 格式:
大家是否同意以下兩點:
專有名詞 (包括模組名):
格式: 翻譯 (Original name)
例子: "視圖 (Views) 是一個模組,透過視圖你能做到... "
** 注意: 首一字母要大寫
Responsive Design / Image
適應式設計 / 適應式圖片
贊成票!
這是翻譯的標準方式。我投贊成一票。