Mozilla Taiwan 正體中文在地化

這次 JSDC 2013 分享的投影片出來了，這次的主題是比較根基的東西，也算是我寫一陣子 JavaScript 後覺得可以整理出來的一個 Pattern，沒聽現場的，應該看投影片也可以知道我說的是什麼，本來題目是 Magic this，後來改成 this 了，不過已經生好的標題圖片不用太可惜，所以還是放上來了。

編按：本文取自電子前鋒基金會。關於 HTML5 是否應該納入 DRM 相關規範，Mozilla 社群幾個月來也有許多討論，迄今 Mozilla 基金會尚無正式回應。

數位版權管理（DRM）的技術攻防現在有了最新的戰線。

DRM 技術本應保障合法版權，但迄今為止，它仍然沒有成功讓有創意的人獲得合理報酬，反而干預了人們創新、合理使用、公平競爭、商品互通以及我們擁有事物的權利。

這就是為什麼我們對於 W3C HTML5 工作小組前，有個提案想將 DRM 建置入下一世代的網頁標準感到震驚。此提案名稱為 Encrypted Media Extensions（加密媒體擴展，縮寫為 EME）。我們認為採納 EME 將導致災難性的發展，必須立即被予以阻止。

對於網際網路該如何運作，在過去的二十年裡，一直有兩道聲音持續在爭論。其中一派的哲學是，網路需要成為通用的生態系，以開放標準作為根基，並且於各個方面、所有人、任何地點都應該能夠平等的完整實作，不需要取得任何許可或預先協商。這樣的技術傳統，在過去二十年間帶給我們 HTML、HTTP，接著成就了許多劃時代的創新產物，像是維基、搜尋引擎、部落格、網頁郵件、JavaScript 應用程式、多用途的線上地圖，以及成千上百萬列都列不完的網站。

另一派則由企業集團為首，試著要透過他們的私有套件控制網際網路。例如 Adobe Flash、Microsoft 的 Silverlight 等具有代表性的技術，並且由 Apple 、手機公司、以及其他高度限制的新興平台所推崇。這些技術傾向於單一來源，或者必須取得授權才能實作。無論這些技術在何時有多麼流行，他們都會對開放生態造成傷害。諸如仰賴於 Flash 或 Silverlight 的網站通常無法被正確連結、被搜尋引擎索引、被機器翻譯、提供身心障礙者取無沒辦法在所有裝置上運行，並且對使用者的安全以及隱私有一定風險等問題。我們相信，限制使用者的平台和裝置，必將面對創新的停滯，並且阻礙市場競爭。

不幸的是，EME 這個提案就具備上述的諸多問題，並且無疑會產生相容性問題，讓網站得需要第三方廠商的軟體元件、特殊的硬體與特定作業系統才能運作（統稱為內容解碼模組 CDM，content decryption modules），而這些在 EME 裡面諸字未提。

EME 的作者聲稱這些 CDM 的功能、及所作所為都與 EME 沒有關係，且不能拿 EME與 DRM 相提並論，因為並非所有 CDM 都是 DRM 系統。然而，如果一個客戶端無法證明它符合網頁要求的特定環境（沒有可接受的 CDM），就無法正確的顯示該網頁內容。

可笑的是，這不正與 W3C 最初出現的理由背道而馳？W3C 的存在意義就是為了要創造易於理解、可被大眾實作的網頁標準，如此一來才能確保最大程度的相容性，而非幫助這些只能由特定軟體或裝置才能存取的網站或服務的增長。然而 EME 這個提案，正是打算把這些機能性上的變數帶入 HTML5，如此很有可能會使我們回到那個網站之間互不相容的不太美好的網路世界。

因為開放網路社群對於 DRM 與其可能帶來的後果實在沒什麼信心，因此這個由 Google、Microsoft、Netflix 聯合提案的 EME 內就聲稱「沒有 DRM 被加入 HTML5 規範」。這就像是在說「我們不是吸血鬼，但我們要邀請他們進門來。」

這個提案的大部分支持者，也聲稱 EME 本身在架構上並不是 DRM。不過規格書撰寫者 Mark Watson 承認「當然，我們對於這個標準的興趣，來自於很多人稱之為 DRM 的某些使用情境」，且實作上勢必得引進一些標準書內未提到的秘密。要我們支持 EME 與 DRM 毫不相關的這種假說，實在是很困難的一件事。

這類 DRM 的提案之所以會送到 W3C，只有一個簡單原因：為了試圖取悅好萊塢。好萊塢對於網際網路的憤怒，大概就跟網路存在的歷史一樣久，而他們一直以來都希望能透過某些科技架構，來控制視聽人的電腦。我們的感覺是，如果沒有辦法透過 DRM 來限制，好萊塢大概永遠不會允許電影在網路上播放。

不過老實說，這種「好萊塢隨時可以捲舖蓋走人」的威脅實在很不切實際。對於那些想看盜版的人，好萊塢所釋出的每一部電影早就都在那邊了，而且 iTunes、Amazon、Magnatune 與其他網站不需要使用 DRM，就已經售出了大量的音樂。像是 Netflix、Spotify 的串流影音服務之所以會成功，是因為他們比下載盜版更方便，並非是 DRM 起了什麼效果。

好萊塢之所以要求 DRM 的唯一合理原因，是因為他們希望能抗拒主流科技的原生面貌。電影工作室曾經使用 DRM 在他們的產品上恣意加入限制，像是禁止快轉與加入地域性播放限制。透過相容性技術公司複雜且昂貴的「相容性」技術，來阻擋了小型的媒體財團及大型科技公司創新的權力。

過去科技公司一而再再而三地競相開發各種限制的方法，來討好好萊塢的奇想，在這個過程之中，他們也背叛了他們的用戶；開放的網路標準是這種趨勢的一劑解藥。如果我們對好萊塢病入膏肓的反科技文化敞開大門，讓它們感染 W3C 標準，將會是網路社群一個最可怕的錯誤。這會破壞 HTML5 的存在意義：「建立開放的生態系統，補充先前網頁標準中缺少的所有功能，無設備限制，沒有平台不相容的問題，也不會有 Flash 平台所產生的那種不透明狀況」。

HTML5 應該要比 Flash 要好，而將 DRM 排除在外，正是讓它好上加好的法子。

原文 / Defend the Open Web: Keep DRM Out of W3C Standards | Electronic Frontier Foundation
作者 / Peter Eckersley & Seth Schoen
授權 / 創用 CC 姓名標示-3.0-US

φ Toby、sntc06 翻譯 - Irvin 編輯

Google Chrome 開發工具的文件昨天有更新，不確定這整頁是新的還是改寫，不過總之是詳細很多的 Script Debugging 的使用說明，從詳細的介面介紹，到如何用這些功能都有說明，值得推薦一看。

另外還有一篇新的則是關於把開發工具導入開發流程內的文件，所以包括一些新功能像是 snippets 的介紹，也有 in place editing ，如何儲存修改過的檔案等。

前陣子 Bingo 告知才發現，jQuery Deferred 物件的 pipe 在 1.8 被標為 Deprecated 了，以後請改用 then，兩者其實不管回傳值的話，行為還蠻接近的，現在的 pipe 還沒移除掉，不過已經是新版的 then 的 alias 了。看文件的話如果不看下面的敘述，很可能不知道 1.8 前後的差異，雖然回傳的都是 Promise 物件，不過 1.8 之前回傳的是同一個 Promise 物件，1.8 之後回傳的則是新的，和原來 pipe 行為一樣，結果修改過的 Promise 物件。

我們大家一定都做過這種蠢事：想要找 Google 卻輸入了 Goggle、或者想找「Funny Cats」時輸入了「Funny Cars」。之後當我們在網址列輸入網址時，網址建議都會把先前的錯誤內容入列出來，而通常在你的腦袋想清楚要點哪個網站前，你的手都會點中錯誤的那一個。這真的很煩，對吧？

現在正是時候把你的瀏覽器主控權要回來、收拾你的沮喪，把那些手誤留下記錄的錯誤網址通通丟掉——不花你五分鐘就可以全部搞定。

立刻打開你的 Firefox，在選單列上選「歷史」→「顯示所有瀏覽記錄」，你就可以從瀏覽時間（今天、昨天……等等）去尋找你打錯的網址，或者直接在右上角的搜尋列上輸入你要找的名稱。

一旦找到了錯誤的網址，你可以按著 Ctrl 鍵點一下（或者直接用滑鼠右鍵點選）打開選項清單。選擇「刪除與此網站有關的紀錄」這個選項，然後你的歷史瀏覽記錄裡就再也沒有這個網站的記錄了。下一步就是把視窗關閉，忘記所有跟這個網站有關的事，繼續開心的瀏覽網頁。

直到再次手誤輸入錯的網址前，你都不會再被困擾了。不過就算真的又輸入錯誤網址，你也知道該怎麼即刻修正了！

原文 / Remove a Single Website from Your Firefox History | The Den
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ Linear 翻譯 - 小迅、Irvin 編輯

這篇文章原刊登於謀智台客，公司的技術 Blog，歡迎訂閱。

用過 Firefox 等 Mozilla 系列瀏覽器的朋友，或許知道 Mozilla 瀏覽器都內建一份 about:mozilla 頁面。該頁以深紅色為底，節錄一本不存在的《Mozilla 之書》，以基督教聖經的語調講述 Mozilla 的歷史。

在 Netscape/Mozilla 的歷史中，about:mozilla 改版了 6 次。就如聖經一樣，都是用寓意的方式將網路的現狀，以及 Mozilla 挑戰與行動記錄下來。Wikipedia 的條目詳列了先前各個版本的原文與寓意。簡略來說：

• 12:10：1995 年撰寫，提到了當時主流瀏覽器（Nestcape）如何面對新瀏覽器的競爭，以及 Netscape 推出的私有標準。
• 3:31：1998 年 3 月 31 日，Netscape 將 Mozilla 原始碼公開。這個章節寫出了 Netscape 對 Mozilla 開放原始碼後的期許。關於這段故事可以參考紀錄片《Code Rush》。
• 7:15：2003 年出現在 Firefox 1.5 之中的章節。描述 Netscape 被收購，Mozilla 浴火重生，以 Firefox 和 Thunderbird 這些新產品重新撼動市場。
• 8:20：2007 年出現在最後一個版本的 Netscape Navigator，描述 AOL/Netscape 產品與 Mozilla 基金會原始碼/產品的平行關係。
• 11:9：2008 年更新的章節，描述 Internet Explorer 停滯更新之後，Firefox 所帶動的瀏覽器市場文藝復興，直到微軟開始反應 Mozilla 在市場的威脅，重新推出新版 Internet Explorer。

目前的版本為章節 15:1，今年 1 月剛剛更新：

瑪門的雙生子發生了爭吵。他們的交戰使世界進入了一個新的黑暗，而野獸憎恨黑暗。於是它迅速的採取行動，變得更加強大，並不斷地前進和繁衍。野獸為黑暗帶來了火焰與光明。

關於這個章節的討論與寓意可以參考 Bug 上的討論。「瑪門的雙生子」比喻 Apple 與 Google 在手機作業系統上的競爭以及平台的私有化。Mozilla，即「野獸」，在新的時代則推出了 Firefox OS、Firefox for Android 以及高速釋出開發週期以面對新的挑戰。

科技給人力量、使人更加自由，也激勵我們、拓展我們的視野……但好像還差了一點什麼？

現今大部分能從科技發展受益的人，都不是使用英文作為母語。如果語言的藩籬阻礙了科技的使用，那麼這幾句話還能成立嗎？在科技迅速成長、讓我們的生活更加舒適便利的今日，如何讓人們能使用最熟悉的語言去學習，並且有效運用這些科技，就成為了一個很重要的課題。

想要使用電腦的人，真的必須先學會英文嗎？不懂英文這個理由，足夠充分去拒絕一個人接觸科技嗎？在開發中國家裡，主要透過方言進行教學，這個問題特別重要。再加上低識字率的問題，就成為阻礙他們接觸資通訊科技的阻礙。對於偏鄉窮苦人家、和未享有公平受教育機會的女性而言，問題說更為嚴重。他們亟需一個解決這些擾人問題的解答，而答案就是「在地化（Localization）」及「國際化（Internationalization）」，一般簡稱為 l10n 和 i18n。

首先讓我們來試著解釋「在地化」的意思：基本上，在地化就是取某一項產品進行修改，使其在語言及文化上符合目標地區的過程。相對而言，「國際化」就是使某一項產品，能夠輕易的套用不同語系，使在地化更為容易的過程，也就是力求使用同一套程式、讓其通行全世界。現今網際網路扮演了將科技帶到人們面前的角色，有鑑於此，網際網路門戶的在地化就變得非常重要，透過適當的在地化，就能夠讓最多人上網。

Mozilla 在這個趨勢中扮演什麼角色？Mozilla 是一個全球性的非營利組織，致力於強化使用者對於網路的掌控能力，同時也以公眾利益為立基，協助塑造未來的網路。目前 Mozilla 專案囊括了一系列知名的軟體，包含全球最受歡迎的瀏覽器 Mozilla Firefox。不只如此，Mozilla 專案也是自由軟體界中，在國際化及在地化方面做得最棒的例子之一。現今 Mozilla 專案中大部分的產品，都有超過 70 種語言版本，多虧了開發者社群來開發支援國際化的軟體，以及我們孜孜不倦，協助翻譯及調教的各國在地化社群。Mozilla 專案的目的，就是要服務涵蓋廣泛多元族群的廣大社群，也包含了要將 mozilla.org 的產品，在地化成世界上任何一種語言的目標！

好了，現在你已經了解這些概念，你也想要付出一份心力，協助每天使用 Mozilla 產品的四億五千萬名使用者嗎？有很多種方式能夠讓你貢獻一己之長，作為入門的課題，你可以介紹人們來使用屬於他們語系的 Mozilla 軟體，賦予他們改變的能力！此外你也能夠加入 Mozilla 的在地化工作，成為社群的一份子。快來協助我們，成為我們的同伴吧！

原文 / En:NeMo-MozillaLanguage
作者 / Gautham Akiwate
授權 / 創用 CC 姓名標示-相同方式分享-3.0 或更新版本

φ 無銘氏 翻譯 - Irvin、petercpg 編輯

昨天在 OSDC 的演講投影片~

I recently did some research on well-known Javascript module formats. Not sure why I missed this topic back in 2009, however some archeology revealed an conflicting reality:

• The most accepted package format, for Javascript in general, is the CommonJS format.
• However, the format is unfriendly to browser context, and it’s impossible to implement the loader 100% correctly.
• In the browser, people ended up using AMD format instead. Also, AMD try to incorporate CommonJS format by introducing special dependency names; see the 3rd and 4th paragraph of the spec.

For years, a lot of discussion on the difference of the formats surrounds the sync v.s. async nature of the format. jrblake, the author of the AMD spec and require.js, have already explicitly explain his argument on why he disagreed with the trade-offs made in the CommonJS module format.

However, I still ended up drawing the conclusion of my research — as of 2013, CommonJS modules is more welcomed to the developers than AMD modules. But why? In my humble opinion, of all the differences in design between CommonJS module and AMD module, this one stands out and made the difference: CommonJS module spec requires one scope per module. This in turn gives CommonJS modules the following behavior:

• Every module get a private scope, for free — the only things expose to others are the ones you explicitly expose in the exports object.
• In return, module scripts don’t get to access the globe object of the main context — e.g. the window object in browsers. This has significant implication — module scripts can never take global APIs for granted — one would have always explicitly require() for it. On the other hand, one could never mess up with the dependency system by attaching fake fake APIs on the global object — everyone has to be honest to the dependency tree, and the loader.
• Without the global object, native APIs available to the module would also need to be require()‘d. This in turn provided an uniform experience for the developers, which is extremely helpful to new Javascript runtime/platforms, both on inventing one and on learning one. With that, it is not surprising almost every “new kid in town” adopts CommonJS modules, e.g. NodeJS, PhantomJS, and Mozilla Add-on SDK.
• Limiting one file per module is pretty much an outcome of the scope design. It will be really hard to define scope syntax, to house multiple scopes within one file, and it will be even harder to implement.
• Same applies to sync dependency loading. If modules are loaded in their own scope, they could surely block the execution of requestee.
• Lastly, and sadly, one of the drawbacks of the one scope per module design: you can never ever simulate private scope in the browser reasonably. One could surely wrap CommonJS module into a function scope, or simulate sync loading with sync xhr and eval() (Yabble), but one would never stop script within from referencing variables on the outer scope s (except running your own Javascript runtime on top of the native Javascript runtime, I presume).

What does all that means

For someone who write Javascript for the browsers most of the time (we all are I think), I hate to be the proponent of something that doesn’t work in the browser context. What’s good come out of CommonJS module spec is all begin with the decision to ditch the browser. Alternatively, the legacy limitation of the browser is just too heavy for AMD module format to carry — thus, the AMD format never propagates, beyond browser, so does the promise to Javascript modules debate to the developers — you should be able to write your code once and use it everywhere.

What is broken, for modern day needs, is the browser context, not AMD, which tried really hard to address it. What AMD proofed is that we need new language feature, or browser APIs, to cope what we are facing. Hopefully, the new ECMAScript Harmony module is being worked on in Gecko and will be landed soon. How Harmony module could deliver the promise is not the scope of this article; it would be a further pending research topic for me.

An unified Javascript ecosystem awaits

Javascript, 18 years after invention, a fundamental cornerstone is still missing for building a library repository, like what PEAR for PHP, CPAN for Perl, or RubyGems for Ruby. The momentum is there already, and it had been there, for a long time. npm could be considered the most promising one, however, again, the lack of a common module format limits the uses of the modules on the site.

It also limits people writing heavy client-side web applications — people is currently prevented to split their apps into modules agnostically of any frameworks. This is worse than PHP, in which the frameworks have already start working together on common standards, i.e. PSRs.

We are still eagerly waiting another universal Javascript module format, to ignite everything and to start realize all the possibilities. I remain optimistic on this issue given the wide acceptance of the language itself had attracted lots of talents. But, first step toward the solution at full speed is to admit there is one.