By KayL on

對以下的專案做下初步的審核工作了：
Token
IMCE
Views
CCK

餘下還有一些建議字串存在，很難決策，大家看看，給給建議。特別是 CCK 模組！

發現一個問題，我們一般不翻譯模組名稱，但以下模組在很早期時連模組名也翻譯了，我們該如何 ??

選單模組表單。
Menu 模組表單。

Poll 模組標題。
投票模組標題。

其次關於 "Referenced" 這個字，不知大家有什麼看法。
http://localize.drupal.org/translate/details/zh-hant/69878

也希望大家對以下三個字串做一做決擇，太常看到類似建議字串，我們只能選其一：
image

圖像
圖片
圖檔

Thanks !

(為了進度著數，討論期約為 30 ~ 45 天，視乎情況決定，如沒人參與，唯有按個人想法行動)

大家可以透過這頁面查看目前狀況，點擊統計數字會自己設定過濾內容：
http://www.notabluescreen.com/localize/zh-hant.php

Groups audience: 
Chinese, Traditional team / 正體中文翻譯團隊

Comments

mrmu commented

個人覺得如果可以的話，先前翻譯的模組名稱可以改回英文嗎XD
Referenced user ID 我大概會翻 "參考的使用者ID" or "參考的使用者帳號" 吧~
image 我比較喜歡 "圖片"。

今早又翻了一些CCK，加油!!~:D

KayL commented

補充一下，三個字串使用量約是：

圖片 180
圖像 60
圖檔 110

mrmu 很勤快 ^_^

hom commented

我的想法
image 圖片
image file 圖檔

reference 我就想不出怎麼翻比較好了
直接翻是參考，但是感覺在中文裡都不是很通順的感覺
看起來可能也不是很直覺
我可能會翻成 相關的使用者，關連的使用者... 之類的

tokimeki commented

image 我是覺得圖像跟圖片都可以考慮
像：形貌、模樣。
片：扁平的東西。
我是比較喜歡翻成圖像

reference 可以翻成參照

jimyhuang commented

Reference node/Reference user
可以翻成：關聯文章、關聯使用者
比較符合本意～

joetsuihk commented

我覺得:

Reference node/Reference user =/= 關聯文章、關聯使用者

關聯是 related

reference =/= 參照

reference 的英文使用原意應該是 programming 的概念 "pass by reference" (即 c 的 pointer)

我自己覺得 "引用" 是比較好的譯法....

tokimeki commented

模組名稱是否要改回英文名稱，我個人沒有太大意見，因為在其他翻譯當中，很多時候你還是會針對該模組名稱做翻譯，比如說：Block。
不翻的好處是當你啟用一個新的模組時，在系統管理頁面中比較容易找到該模組的設定頁面的連結。

KayL commented

也對。或者我們針對某些模組做例如性的許可

不過做模組翻譯最糟糕是譯名問題，可以千奇百怪

如果只是單一模組名字或特別想讓人了解中文是什麼，可以中英都出

BLOCK
BLOCK (區塊)

mrmu commented

發現 xslidian 有許多未完成翻譯的句子都是大陸用語，有心想要修正口語問題的朋友可以來試試：
http://localize.drupal.org/translate/languages/zh-hant/translate?project...

xslidian commented

我提交的主要是 Pathauto 和 Google Analytics 兩個模塊的字串.
提交前只替換了少量個人所了解的正體詞彙, 而且翻譯經驗不足, 希望有空的朋友能幫忙完善一下.
po 檔在 http://2.xslidian.sinaapp.com/po20100507.7z

KayL commented

說到這回事，很常看見：

Create a new XXX 翻譯為 建立一個新的 XXX

其實是否可以簡短為：

新增 XXX

如果很著重一個，可以：
新增一個 XXX

感覺中文應是很精練的文字才對 (個人覺得第一個就很足夠)
當然現在已翻譯了的也沒很大的必要去修正

jimyhuang commented

個人覺得，這件事很重要 ;)
對UI上面，全站統一的動詞，會滿有幫助的。

KayL commented

嗯，減少差異很重要，特別是在同一頁面出現的時候。之前也有類似想法，將差不多結構的字串統一化

http://drupaltaiwan.org/forum/20091006/3727

特別是我們常見的的一些結構：

新增了 XX
增加了 XX
建立了 XX
已新增 XX
已增加 XX
已建立 XX

這類其實可以統一化
=======================

已新增了 XXX
XXX 已新增了

放在前，還是後，其實也值得討論

都是不易解決的問題，或者下一個月，大家整理一下，拿出來討論，這些問題能在 Drupal 7 發佈前解決就太好。

如果我們能建立一個 30+ 人的團隊就好，即使大家沒有討論上的意見發表，也能在二選一的決策問題時進行投票。(感覺很多人在看，卻沒有發言)

tokimeki commented

這個問題應該是因為英文有三個動詞（new, add, create）在描述同一件事，再加上時態去描述做完該事的狀態

先說 Create a new XXX ，我覺得翻成 新增 XXX 會比其他兩個翻法來的好，理由是新增兩個字表達的意涵比另外兩個翻法（增加、建立）來的多
它同時具有新（狀態）、增（動作）兩個意涵

而該動作完成後的訊息，如果沒有其他的前後文，我建議翻成 新增：XXX （這裡的 XXX 通常是文章的標題跟連結）
這樣的翻法會比較制式跟生硬，但對於操作者來說會比較容易閱讀

hom commented

有人可以建議一下 placeholder 要怎麼翻嗎
直譯佔位字

另外搜尋了之前已經翻譯的部份，找到下面兩種
文字變數
預留位置 (有搭配前後文)

目前想出來的有
替代文字
替代字元
代號
代碼

有人有想到更適合的嗎？

KayL commented

Google 一下 "佔位字"，幾乎沒有人這樣使用

一般我們是不是叫 HTML 的 ALT 中的字串為 替代文字 ?? 如果是，不太好

代號 / 代碼，我會想為 CODE，好像是最差的譯法，完全意會不了是什麼東西

MS 大多使用:
繁：預留位置
簡：占位符

"替代字符" 會不會比 "替代字元" 好
還想到：替代變量

(如果我們創作一個不常用的翻譯，一定要記入翻譯詞彙並加上簡單解釋)

mrmu commented

個人覺得延用簡體翻譯「佔位字符」或「替代字符」都還蠻適合的。
:)

arthuryu commented

Placeholder => 置換符號

供參...^^=。

hom commented

置換符號
感覺把功能翻的比較直覺了 不錯～

KayL commented

不錯。

另外：

machine-readable name
- 供機器讀取的名稱
- 可機讀名稱
- 可供機器理解的名稱
- 人類讀取名稱

大家想想看哪一個或有沒有更好。

tokimeki commented

我覺得把可字拿掉，翻成機讀名稱就好
human-raedable name v.s. machine-readable name
人讀名稱 對 機讀名稱 兩邊都把它當成名詞來看

arthuryu commented

human-readable name => 人類識別名稱 or 顯示名稱
machine-readable name => 程式識別名稱

供參...

KayL commented

不贊成 "顯示名稱"

提供多一個：
human-readable name => 易讀名稱 / 易識別名稱

hom commented

比較口語一點

human-readable name
使用者容易辨識的名稱

machine-readable name
程式可以分辨的名稱
程式可以識別的名稱
系統可以分辨的名稱
系統可以識別的名稱

KayL commented

感覺太長了，可以簡化為

human-readable name
使用者易辨別名稱 / 使用者易識別名稱 (我還建議直接去掉"使用者")

machine-readable name
程式可辨的名稱
系統可識別名稱

tokimeki commented

Placeholder => 置換符號
+1
我覺得這個翻法很好～

zanhsieh commented

不同意。placeholder 也可以用在其他方面，如：

1. 某個 logo 圖未設計完成 / 或者領導層未決定放哪個，故該處放個 placeholder。
2. 小明寫的那個代碼核心演算法小華還未想出，，故該處放個 placeholder。
3. 地政司黃絲帶圍住的那塊地域是個 placeholder，日後要建新大樓用的。

不是只有代碼才這麼用。「預留位」是比較好的譯法，中性，適用於多種場合。

hom commented

我想你提到的例子並不是這邊所要統一翻譯的對象
想要統一是因為 placeholder 在 Drupal 是代表用來替換特定文字的符號
代表一種特殊的功能

Available placeholders: !site_name, !site_slogan.
這句是 Drupal 用到 placeholder 最常見的句子
可以使用的置換符號：....
可以使用的預留位：...
很明顯的第一種翻法可以讓使用者比較直覺的了解功能，而且 placeholders 代表 Drupal 裡一種特殊的功能
是不能用其他單字取代的

Placeholder when ads are disabled?
這種比較少出現的用法，接近你上面的例子
當廣告停用時保留位置？
當廣告停用預留位？
這種用法 Placeholder 就不是指 Drupal 內特殊的用法，使用其他字眼替換也可以表達同樣的意思
而這裡用預留位來翻譯反而不通順

雖然預留位這個翻譯放在哪都不能說錯
但是卻不適用，僅能勉強算是通用吧
像是 block 在 Drupal 裡是專門用來指 區塊
而 block 當然也會有別的用法，像是阻擋，但是就不是用來代表 Drupal 內專用的"區塊"了

zanhsieh commented

您打算特化，完全符合某個模組某些時候特殊用途的上下文，做法是可以的。不過，當有人把某模組用在非原本設計能想到的地方 (e.g. Views, Token, Predicate, Taxonomy，好的模組都是被用在原本設計者群想不到的地方)，又工作得很好的話，譯文就會彆扭了。

社群自行投票表決要上不上要下不下的詞要特化 (Specialization) 還是一般化 (Generalization) 吧。每隔一陣子還得按該模組的開發方向、受歡迎程度再投一次譯文選哪個。個人意見，做不得準。

tokimeki commented

這個問題的本質不在譯文是否要特化或一般化。
不論任何一種語文，都有一字（詞）多義的問題，你沒辦法一個蘿蔔一個坑去處理這個問題，所以我比較贊成 hom 的作法～

hom commented

rich text editor
大家有看過什麼比較好的翻譯嗎？

xslidian commented

"富文本編輯器"這個直譯比較常見

KayL commented

比較常見到的：
- 豐富文字編輯器
- Rich Text 編輯器
- RTF 編輯器 (MS 翻譯)

還有是：WYSIWYG (一般這個詞只有管理員或技術人員才接觸，應該很多人懂得 WYSIWYG )
各位覺得保留英文就算了，還是要翻譯 ??

WYSIWYG
- 所見即所得編輯器
- 可視化編輯器

Rich Text Editor =/= WYSIWYG 前者可以是不可視化 (是嗎 ??)

taco20147 commented

WYSIWYG=所見即所得編輯器 吧！

andrew971218 commented

image=圖像
will be better

KayL commented

FORUM 該是 "討論區" 還是 "論壇"

hom commented

討論區 +1

apaopao commented

有沒有辦法設投票專區（poll module），讓譯者發起投票 ，其他譯者可加入投票或新增譯法，一定期限後自動截止收入字彙表。這樣應該比較有利統計及建立對照表。

KayL commented

個人有想過。大家有好方案 ?? 最重要是有人去實現。(現在除了此主題外，都幾乎沒有人參與的..><" )

如果只是想純粹地投票的話，其實打開一個投票模組或 Google Form 都能滿足。不過後者太自由，不知會不會有人太空閒，自己多投幾次。

現時人流極少，對於統計還能控制，就是不能引進一些愛投票，但不喜歡發言的朋友。還怕有投票後，大家傾向投票，不進行討論，有時候進行討論才能感受到那一個字詞是好一點。

還有一個最大問題，"建議" 投票也在官方的 issue page 中，字詞表也是計劃中的事，可能我們剛做起來，官方又提供，這會重複了... (不過以我來看，官方有很長的日子才能在此實現，原因是沒有人去實現，其次........)

tokimeki commented

我覺得兩者不衝突，如果我們真的需要這個功能，就先做。
未來如果官方有提供，就合併回去就好～

KayL commented

嗯，其實說是做一個簡單的投票網站，也是十五分鐘的時間，大家想想是不是只需要這樣單純的功能就足夠。
現在，可以什麼不用先規劃，就下次想要談的字串，簡單用 Google Form / 其他投票工具做一做，試一試反應。

對於是否很全面的進行,我覺得要看幾個因素:
1. 有投票後，是否還有人參與討論
2. 投票者是否同是討論者

原因一，有些字串是要討論後才發現那個才真正是好的，而投票者往往直覺進行，甚至說投票以後就不會進行後繼跟進
原因二，同是一樣的人，現在的參與人數來說，好像意義不大，對統計不成問題

還有的是，量化的數據並不完全真實，投票者可以是完全沒思考過就直接投的，但討論的話，我能針對你的錯誤而言

其實我有想過一些一站式的中文化流程：

1. 程式自動整理格式，就不用看這內容了：http://localize.drupal.org/node/182
2. 程式自動捉出常見錯誤

而在 L.D.O UI 可以透過 JS 讀取詞彙表，在原文中插入提示，這就不用去查詞彙表這麼浪費時間了，比如說：
This is a node(節點) ...xxx

tokimeki commented

我覺得可以用這樣的方式：
1. 讓大家來投票，但可以改變自己投票的內容。
2. 投票跟討論分開 (討論 = 投票的內容類型的回應，投票只投設定好的題目，不對回應做評論性投票)。

比如說現在有 A/B/C 三個選項，讓大家來投，過了幾天有人來討論，談論為什麼覺得 A/B/C 這樣的翻譯比較好，又或許有人提出另外一個選項D，而這個D選項大家又覺得更好。
這時候就可以改投其他的選項～

apaopao commented

其實有些譯法並無明顯的優劣差別，但是不固定譯法就比較麻煩。(例如Forum=論壇或討論區)。
如果全都發在一串討論，實在很難看出結果如何。最好是分別開主題，設定固定時間截止，同意者投票，不同意者可提新選項，並回應討論。沒討論者表示問題不大，那就期限到收入字彙術語表。

直接引原文查表代入術語建議取代的功能很棒啊，期待中~~

KayL commented

我們換一個方式來玩。先進行討論，後投票

在討論過程中，選出值得拿來投票的翻譯。如果討論中，沒有異議的話，就不用投票。

怎麼看 ??

(參與者少，加上資源有限，個人希望盡量簡單化)

tokimeki commented

這樣子也可以，不過在投票之前，希望能先在 DrupalTaiwan 那邊做集中討論（因為那邊看的人比較多，討論也比較踴躍）。
這個禮拜 DrupalCamp 開會時我會順便跟站長群溝通，看是不是能夠開一個翻譯譯文的討論區子版。

KayL commented

好的 :)

對我來說，那裏都可以，最重要是反應"佳"。在 DrupalTaiwan 的話管理會易一點，權限大一點。

你們有沒有發現這個主題比 DruaplTaiwan 中文化區多年以來任何一個的討論量多一點點。

我想到這裏有人參與的原因：
1. 預設開啟了回應發送 EMAIL 通知這個功能
2. 來這裏取或翻譯檔案時，不經意地看見了討論

我們要引入第一點哦。

不過歷史告訴我們，中文化區效果不好，永遠只有你、我、其他站長參與... 所以引進那邊前，是否要做一做測試....

不如我們直接將在DT 開一個 "如何在 DrupalTaiwan 攪翻譯" 類似的主題，看看反應。如果還是你、我、數位站長有回應，就真的要考慮考慮。

而且，我想很快，要討論的字詞會很少了，是否要投入這麼多的資源，也要想想。

反而重點是:
- 如何引更多的人來提交翻譯
- 增加更多的人來來審核

希望有其他人發表一下看法，否則真的永遠只有你、我、他三人。

joetsuihk commented

"增加更多的人來來審核"

現在如何才有審核權?

KayL commented

應該是你想就可以，我也是這樣就加入了 (我沒有決定權，應該說不敢私下增加你)

怎麼都好，盡量新加入的人要常常在 Drupaltaiwan 及這裏參與討論。joetsuihk 絕對乎合，你向團長問問: # Manager: charlesc

現在我們可以有審核權限，但不是 ADMIN 的。

多些人參與管理後，希望所有人都取消 translation self-moderator 這個權限。

KayL commented

順便說說，

我稍後簡單草議一份類似這樣的文章：
http://localize.drupal.org/node/182

讓大家新舊審核員都有個方向，減少重復工作，如果你想草議的話，請回復 (這我可以省回點時間，哈哈)

joetsuihk commented

其實我只是問問, 因為我沒有中文化的熱情... 但樂於看到統一了的用字/用詞

中文化規範指引我覺得先定一份, 再隨時間慢慢修改 會比 長時間討論才得出一份 好
v1.1 只要加些真實例子已經很足夠

常見字表也重要, 先集中力量簡化翻譯入門階梯比較重要

還有, 翻譯的朋友們, 一路以來辛苦了

最後, 可以考慮一個月開一個新討論串更新大家進度

Pages