並不是捍衛漢語拼音

要先說明的是，就這個問題而言，我並不是因為捍衛漢語拼音的原因而去反對 New Taipei 這名稱的。我能接受 Xinbei City，也接受威妥瑪的 Hsinpei City。不能否認我對通用拼音的 Sinbei 比較反感些，不過這是另一個問題。

為什麼說 New Taipei City 不是個好名稱，我想可以用幾個理由說明：

容易誤會

就拿新北市政府是 New Taipei City Hall 來說好了，看起來不是很像新的台北市府嗎？ 當然，國際上有太多 New York 之類的例子在前面，但 New York 可不在 York 附近，隔了快半個地球遠。

確實這種誤會情形會隨著時間（大家漸漸習慣）、調整表達方式（改寫 City Hall of New Taipei）漸漸解除。但就語言行為的角度來說，天天在用的母語比較容易快速找到解決之道，但台灣畢竟母語不是英文，無論政府、民間，製作外語標示總是非常隨便，尤其我們的公共機關已經三天兩頭做出離譜的英文標示被抓出來笑了（像台鐵的烘手機＝Bake Cellphone），為什麼還要製造新的混亂源呢？

台北市內湖有一家新台北有線電視，我想英文大概就是 New Taipei Cable TV 之類的吧（網站查不到），像這類現在已經使用 New Taipei 而不在新北市轄內的公司行號，又會是另一個混淆點…

造成地名意譯的前例

拿台北來說，為什麼不是 Northern Taiwan City？ 行天宮站為什麼不是 Sky Walk Temple？ 國際上地名譯寫一般原則都是將地名整體視為專有名詞，使用音譯的方式處理，以求各個國家之間都能互相溝通。所以 New York 在中文翻「紐約」，在日本翻「ニューヨーク」。如果中文翻「新約克」，日本翻「新しいヨーク」，這樣豈不造成溝通麻煩？

台灣現行法令下只有後方的屬性詞使用意譯。例如台中市用「Taichung City」，淡水河是「Danshui River」，並沒有任何「市」前面地名本身部分採用意譯的例子。

音譯的新，台灣有先例

拿台灣的先例來說，像新竹用 Hsinchu 已久，不是 New Bamboo、新店現在是用 Xindian，不是 New Store、新北投是 Xinbeitou，不是 New Beitou。反而沒有一個用 New 的前例。

香港新九龍翻成 New Kowloon 啊？

是的，新九龍是 New Kowloon。但香港是以前是英國領地喔。香港當年英文、中文都列官方語言，而且香港的地名幾乎是先確定英文才另外翻譯中文的，而且還有一堆翻譯錯誤… （像指女王的Queen’s Road翻成皇后大道之類的）

台灣天天喊著自己是獨立國家，但若在腦裡只想著 New Taipei 的時候，其實你潛意識裡已經被美國殖民了。

台灣官方語言只有中文，英文不是我們的官方語言。官方語言不是英語，卻針對英語定義一個其他語言不試用的特例譯名，就是一件很奇怪的事情。

地名譯寫是漢字「羅馬化」的工作，不是「英文化」

英文不是唯一的外文。拿台北市來說，英文翻 Taipei City，在法文裡他會是 Ville de Taipei，在日文是タイペイ市。好啦，當新北市翻成 New Taipei City 後，法文要怎麼辦？ Ville de New Taipei 嗎？ 這是英法混雜很怪異，既然都當作不是地名一部分而意譯了，所以該是 Ville de Nouvelle Taipei ？ 所以日文是新タイペイ市？ 天哪，這樣下去會多亂啊？ 西班牙文 Nueva Taipei、菲律賓文 Bagong Taipei、瑞典文 Nya Taipei…… 誰看得懂這啥鬼？

這真的亂透了！！！

別被英文自我限制 才叫國際觀

所以有些候選人拿國際觀說嘴，支持 New Taipei City 名稱，這更突顯沒有國際觀。 我想大多數人根本沒考慮過使用 New Taipei 名稱後，非英語國家該怎麼處理這名詞的問題，反正自我感覺良好嘛，New Taipei 耶，贏台北市了，好爽喔，科科。法文？ 干我屁事。 國際觀，呵呵。

地名是不可分割的單位

總之，地名應該是個不可分割的單位，這應該是最基本的翻譯素養。既然市名就是「新北」了，這兩個字就不會再拆了。漢語拼音他是 Xinbei，威妥瑪他是 Hsinpei，如此而已矣。

補充：給對X有意見的人

這又是個自我被英語殖民的偏見了。英文X不念 /ʃ/ 不表示X就不念 /ʃ/，在西班牙語、葡萄牙語裡，X就是唸 /ʃ/。漢語拼音選擇以 X 表示 /ʃ/ 音其實是很高明的，與威妥瑪相比，它能比 Hs 少一個字，使拼音比較簡潔；通用拼音硬是討厭 X 改成 S，反而造就 /ʃ/ 與 /s/ 音位模糊的問題 ─── 對於多數對 /ʃ/、/s/ 音差異敏感的外國人來說，這不是好現象。

我就是這樣對通用拼音反感：設計上沒有威妥瑪準確、也沒有漢語拼音整齊。其實就是硬是把漢語拼音裡看不爽的 X、Q 拿掉自我感覺良好罷了，通用拼音的支持者，只有在宣揚通用拼音時說通用拼音可以用來拼台客語，但那些台文派還不是也不用通用拼音，繼續使用教會羅馬字？ 說真的用 b 來表示清音的通用拼音，我實在不覺得它適合來拿拼台語。但既然到頭來通用拼音還是只用在國語上，那他優越性在哪裡？ 討厭漢語拼音的話，回來用威妥瑪還好的多，說真的。

每年兩次，動漫迷最大的盛會 ─ Comic Market，通稱Comike。會擔任Comike工作人員的，幾乎也都是動漫迷。在盛夏的酷熱與嚴冬的寒冷中，要妥善引導數十萬人規模的參觀者，工作人員也得使出渾身解數呢…

1. 館内では、お･か･ゆを守ってください！おさない！かけない！夢をあきらめない！
   館內請遵守 O Ka Yu (稀飯) 原則： 不要推擠 (Osanai)！ 不要奔跑 (Kakenai)！ 不要放棄夢想 (Yume o akimenai)！
2. 恥ずかしいもの入れる前に手荷物検索しまーす！ご協力お願いしまーす！
   趁還沒放進丟臉的東西前先讓我檢查手提行李喔！請大家配合～！
3. 辛い事があっても立ち止まらないでください！
   就算發生難過的事情，也不要停下腳步不前進！
4. 倒れないようにお願いします！こんなとこで倒れても、二次元には到達できません！
   請不要倒下！ 在這種地方到下，也不會到達二度空間的！
5. 間を空けておのりください。詰めなきゃというのは過去の話です。むしろどんどん空けてください。
   請保持距離。 盡量靠緊已經是過去的故事了，儘管保持愈開愈好！
6. 体力に余裕のある人は階段を使ってあげてください！階段が寂しがっています！役に立たせてあげてください！
   還有體力的人請多照顧樓梯！ 樓梯現在很寂寞的！ 請讓它能派上用場吧！
7. えー、こちらは参加者殺しの橋と呼ばれています
   欸～ 這裡號稱是專殺參加者的橋
8. 今走ってる人は列に並んだ時に急にゲリになりますよ～！
   現在在跑的人等下排隊時會拉喔～！
9. 列の写真はトラブルになるので撮らないで下さい！毎年６回は見てるんだから心のフォルダの更新だけにしてください！
   在隊伍裡拍照容易造成爭執請不要拍照！ 每年都會看到6次，請更新您心裡的資料夾就好！
10. 暑さ対策、水分補給はしっかりしてください。性欲だけでは立っていられません
    請做好禦熱措施並補充水分，光靠性慾是站不住的
11. 時間が経つに連れ携帯と友達は当てになりません
    隨時間過去，手機跟朋友會靠不住的
12. あと同人誌3冊分詰めてください！
    請再向前靠近三本同人誌的距離！
13. ジャッジメントですの！
14. 今あなたが立っている位置が、あなたの居場所です。一歩も歩く必要はありません！
    您現在所站的位置就是你的容身之處。一步都不需要再前進了！
15. エスカレーターは文明の利器です　動かずともあなたを下まで運んでくれます。焦る必要はありません、戦いはこれからですここでは体力を温存してください。逸る気持ちを抑えられない人はネルフごっこに興じてください！
    電扶梯是文明的利器。您不需要動就可以把您載到下面了，不用著急，戰鬥才要展開而已，現在先保存體力吧。若你無法壓抑激動的情緒，就玩NERV家家酒吧！

不過剛剛忽然引起我注意的是，台灣 Google Maps 的英文版本似乎重新翻譯過了。

或許很多人不知道，Google Maps 其實不是全世界看同一版本。

像日文版的 Google Maps，已經用日文顯示出所有國名，甚至美國的街道名、東南亞的城市名，都已經日文化了。

很可惜的，台灣版的 Google Maps 似乎還沒開始做全世界的繁體字化這一塊就是了。
中國版的 Google Maps 看到的台灣看似都是繁體字，但跟台灣版對照就會發現，中央政府機關被和諧掉了。

似乎日文版 Google Maps 目前日文化部分只有英文為主，台灣、中國、韓國部分都還沒有日文翻譯。
本以為台灣地圖是否只有繁體中文版本，結果發現，除了繁中版外，英文版的 Google Maps 顯示的台灣地圖是有英文翻譯的。

我記得幾個月前發現這點的時候，英文版的臺灣地圖使用的還是勤威的通用拼音翻譯版本。不過今天發現，整個翻譯似乎全部更新了，不只改用漢語拼音，還加上了聲調！

但仔細一看，這版本很明顯是程式自動翻譯搞出來的，所有路名都是音譯。所以沒辦法照顧到一些特殊路名：

羅斯福路 LuoSiFu Rd
凱達格蘭大道 KaiDaGeLan Blvd

雖然我個人是傾向這樣譯的。就像中山譯成 Zhongshan 而不是 Nakayama 一樣。
* 台灣路名、校名大量使用的中山，來自於孫文在日本使用的假名中山樵，本音應該是 Nakayama。

而令人啼笑皆非的，是破音字。

三重市裡所有帶有「重」的路名，都被音譯成 Zhong (眾)。

重(眾)新路
重(眾)慶北路
成都(兜)路
長(漲)春國小
中興(幸)橋

翻譯程式似乎滿聰明的，路名裡的數字會自動拆開處理。
高雄的 七賢一路 轉換成 QiXian 1st Rd
台中知名的 市政北七路 則是 ShiZhen North 7th Rd.

但基隆的 義一路 卻又是 YiYi Rd.
這部分有點找不到規律。

不過看到 疏洪十六路 ShuHongShi 6th Rd. 我還是笑了。

譯自
http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html
http://mixi.jp/view_community.pl?id=1772737

(版本4 2008/12/16更新)

譯註
SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
程式設計師多半自己不面對客戶。
在台灣隨公司不同，比較接近SA或PM。
總之就保留原樣寫SE囉。

—————

1
每天有24小時。
所謂的「今天之內」，是指到明天早上為止。

2
程式不會照自己所想的跑。只會照所寫的跑。

3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。

4
我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare

5
程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！

6
畫面好藍啊。

7
先說「沒辦法」的人贏。

8
有意見的話你寫

9
要殺一個程式設計師不需要刀，改三次規格就好

10
首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）

11
開發沒有終點。只有釋出(release)。

12
無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。

13
客戶總是覺得水跟追加需求是不用錢的。

14
付錢愈計較的客人愈囉唆。

15
在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。

16
一個人掛了大家都掛了。

17
bug過了一晚可能就變成規格了。

18
好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。

19
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。

20
對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。

21
顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。

22
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。

23
品質的劣化程度依規格改變的次數與規模而定。

24
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。

25
有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。

26
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的魯莽行動。

27
程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。

28
對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。

29
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。

30
SE需要持久力，程式設計師需要爆發力。

31
準時離開公司，工作會變多。

32
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。

33
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。

34
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。

35
程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。

36
所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…

37
地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。

38
遠處的火災一定燒到這裡。

39
禱告，然後跑吧。

40
程式不是用腦記的，要用身體記住。

41
明天能放假的話死了也罷。

42
外面有下雨耶，昨天開始下的嗎？

43
若不能心灰，身體會掛。
若不讓自己殘忍，自己會被殺。

44
客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）

45
（日文文字遊戲，講這兩個職務之間的矛盾）
SE總是不講理地說「別強人所難」，
業務總是強人所難地說「別說辦不到」。

46
規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。

47
再嘮嘮叨叨下去也是要付錢的。

48
多想個10秒鐘，你可以不說「嗯，這個做得到」。

49
人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從Mizuho的失敗中記取教訓。
（譯註：Mizuho是日本知名銀行，當初合併系統上線時發生整合錯誤系統掛掉）

50
老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。

51
所謂交案期限，是指開發現場從公司換到客戶那裡的日子。

52
程式、SE、經理不是職種。是職責。

53
業務是最難搞的客戶。

54
能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley

55
漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…

56
上線後的除錯才叫做bug。

57
追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

58
除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。

59
不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。

60
要解決地獄的辦法，就是客戶把錢交出來。

61
不懂電腦的操作者是發現bug的天才。而且無法重現。

62
每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。

63
搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）

64
啊，那是微軟的規格。

65
程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）

66
程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。

67
正因為健康，才能做不健康的事。

68
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
(譯註：聽說這是純愛手札裡的名言改的)

69
那是你說的規格。

70
開發室沒有窗戶，那是因為以前…

71
即使爛了，規格還是規格。
(譯註：模仿自日文俗語「腐っても鯛」=瑕不掩玉)

72
SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）

73
為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。

74
不會動的bug就只是普通的bug。（會動的bug則能視為規格）

75
今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。

76
客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。

77
唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。

78
共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。

79
如果可以改行的話，想找個準時下班不叫「逃跑」的工作。

80
對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫出這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。

81
設計者應該是不該要求製作者製作出超過設計以上內容的吧…

82
無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。

83
SE對程式設計師說的「常識」每三小時變一次。

84
自己看規格書。不能跑的是規格。

85
「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。

86
工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。

87
能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。

88
累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）

89
試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。

90
REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。

91
有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。

92
小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路

93
「不要讓老闆當業務比較好」

94
說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。

————————

ex 1
就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。

ex 2
規格與規格書是不同的東西。

ex 3
比期限更重要的是靈感與睡眠。

ex 4
比知識與經驗重要的是手冊與時間。

ex 5
能動就好了，能動的話…

ex 6
過了三天就是別人寫的程式碼。

ex 7 (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！

ex 8 (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！

ex 9
漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了

ex 10
bug與規格是一體兩面

ex 11
電腦裡沒有bug，bug常在人心。

ex 12
無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)

ex 13
估價需要1%的經驗與99%的直覺

ex 14
沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。

ex 15
・『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
・『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
・『PM』＝每天修改自己定下的行程表的人
・『業界老鳥』＝臉色蒼白缺乏表情的人
・『外包』＝幫不會寫程式的正職員工寫程式的人
・『coding』＝複製貼上的工作
・『單體測試』＝指開始寫程式
・『除錯』＝把程式碼註解掉的工作
・『新同事』＝在火燒屁股的專案火上加油的人
・『出貨日』＝把只完成一半的系統上線的日子
・『末班電車』＝業界平均的下班時間
・『颱風假』＝一年一度可以準時下班的業界假日

ex 16
當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）

ex 17
最終手段
「重開機」
意外的常常都很有效

ex 18
最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」

ex 19
「程式碼的可信度，不會比寫的人還可信。」