Telegram Instant View

Telegram Instant View,

Telegram 前幾天發佈了 4.0,有幾個比較大的功能,包括了Video MessagePayment for Bots還有就是Instant View準備要開放給所有網頁使用了,Instant View 目的和 Facebook 的 Instant Article 以及 Google 的 AMP 一樣,都是為了提升使用者體驗,讓使用者能夠快的看到文章的內容,不過之前沒有開放,所以一直不知道背後的運作原理是怎樣,直到這次 4.0 發佈才得以一窺其原理,和 Instant Article 與 AMP 不一樣,不再是提供另一個新的版本,而是透過一種新的 template 語言來協助 Telegram service 把自己的網頁內容轉譯成 Instant Article 的內容(Instant View page object),不完全算是程式語言,裡面比較像是一些定義,加上用XPath來做文件內容的選取,蠻意外會用 XPath 的,還好我對 XPath 有點經驗,就花了一點時間研究了一下,也把自己 blog 的 tempalte 基本版做出來了:

?exists:  //article/div[@id="comments"]

author:  "othree"
channel: "@othree"

body:     //article
title:    $body//h3[1]

cover: $body/section[@itemprop="articleBody"]/p[1]/a[@itemprop="image"]/img

published_date: $body/header/time[@itemprop="datePublished dateModified"]/@datetime

@remove: //article/header
@remove: //article/footer
@remove: //article/div[@id="comments"]
@remove: //noscript
@remove: //a[has-class("dsq-brlink")]

語法還算蠻好理解的,官方也提供了幾個有完整註解的範例,仔細一看似乎之前其實也只有 medium 是非官方有支援的網站,也因為這個實做方式,對不同的網站就要有不同的 template 來處理,所以官方辦了個競賽,搶先替清單上的網站做出可用的 template 就會有獎金,目前個人網站雖然已經可以在官方的 editor 做 template、驗證並發測試連結,不過還要等 domain 被加進白名單後才會真的啟用,目前這個關卡還沒開放就是。

其實我是比較喜歡這種實做方式的,不用為了增加支援一個新的網路服務就多做一個版本,不會影響原本的網頁原始碼,不會讓<head>越來越肥大,當然缺點就是網站改版,HTML 結構有變化的話就要跟著修改 template,不過我是認為這個實做方法對於網路生態是比較好一些的。


MovableType and CommonMark

Typora

我這邊用的 blog 系統是MovableType不是新聞了,然後也因為用 MovableType 我一直都只能用最初版的 markdown 引擎,沒錯,就是 Daring Fireball 作者 John Gruber 的那一版,這個版本其實已經可以滿足我大部分的需求了,不過當我想要用Typora寫文章的時候,就遇到問題了,Typora 在輸出成 Markdown 文件時,code block 只支援三個 ``` 包起來的Fenced Code Block,而不支援Indented Code Block,剛好初版的 Markdown 格式只有 Indented Code Block,兩者其實要比的話,我是比較喜歡 Indented Code Block 的,比較符合 Markdown 的 sense,不過用 Fenced Code Block 有個優點是可以指定程式碼的語言,也因此才能夠有 syntax highlight 的效果。

總之,因為這個原因,用 Typora 寫技術文章對我來說就很不方便,一直以來都有想解決這個問題,前兩天還去 Typora 發 issue 說希望他們可以支援 Indented Code Block,結果發完沒多久,躺在床上快要睡覺的時候突然想到,CommonMark 這麼多語言有實做,搞不好有 Perl 的啊,結果快速搜尋了一下,還真的有一個perl-commonmark,橋接 Perl 和cmark,也有發佈到 CPAN 上,當下心裡就盤算著,隔天起來要來把它接到 MovableType 去看看。

結果隔天實做起來是沒花我太多時間,雖然對 Perl 不熟,但是可以直接拿初版 Markdown.pl 來修改,原本的 Markdown.pl 這個檔案裡面實際上自己是一個 Markdown 的 Perl Package,同時也可以作為 MovableType 的 plugin script,我只需要把 plugin script 的部分留下,然後把最後做轉換的 function 換掉就好了,當然系統要裝好 cmark 和 Perl 的 CommonMark,cmark 應該很多環境都有了,我在 archlinux 上是直接用 pacman 裝:

pacman -S cmark

然後 CommonMark 是用 CPAN 裝,本來要用 cpanminus 的不知道為何用它會抓不到 package:

sudo CPAN CommonMark

我的 nginx 跑 CGI 時用的 perl 不是系統預設位置的,所以 CPAN 執行檔的路徑我是特別指定給他的,這樣 MovableType 執行的時候才找的到 CommonMark Module,實際上沒花多少功夫,我就把 MovableType 和 CommonMark 串起來了,當下心情真的是非常難以言喻,一來是這個問題其實存在已經許久了,二是我竟然把第一個支援 Markdown 的部落格系統接上 2017 年最新的 CommonMark 實做,雖然現在應該是也幫不到什麼人了。不過沒高興多久,就發現在 UTF-8 字元似乎有些狀況,有中文的文章會爛掉,或是 Dashboard 那頁的文字會變亂碼,後來為了這個問題又弄了好幾個小時,推測問題應該是因為 cmark 那邊回來的字串已經失去編碼的 metadata,所以在做 summary 切文字的時候,就會出現切錯地方的狀況,花了很多時間交叉比對和測試,最後的結果只是用 Perl 的 Encoding 把 cmark 傳回來的字串重新 encode 過而已,其實很簡單。除此之外,我其實還有試著想接看看cmark-gfm,因為它還多支援了 Table,不過幾次測試都不太順利,就沒繼續嘗試下去了。

目前的成果放在 GitHub 上,取名叫MT-CommonMark,附上簡單的安裝說明,暫時是沒打算發去 movabletype.org 那邊。

做好之後 MT-CommonMark 之後,我就開始在部落格上測試程式碼的 syntax highlight了,研究一陣子之後選擇的是prismjs,選擇它的原因很多,不過有兩個是比較主要的:

  • 作者有Lea Verou
  • 支援的 class name 格式剛好和 cmark 輸出的一樣

結果兩者也很順利的搭配起來,中間就沒有再遇到什麼問題了。


GitHub Flavored Markdown 標準規範

Github Markdown Cheat Sheet

前陣子看到 DK提到GitHub 的 Markdown:GitHub Flavored Markdown發表正式的 spec了,當時有大概看了一下內容,不過昨天才有空寫出來(然後今天也看到碼天狗有提到這件事),基本上這份spec是基於CommonMark的,只是多了一些語法,包括:

  • 刪除線
  • 表格
  • 待辦清單
  • 自動連結(包括網址和 email)
  • Raw HTML 黑名單:
    • <title>
    • <textarea>
    • <style>
    • <xmp>
    • <iframe>
    • <noembed>
    • <noframes>
    • <script>
    • <plaintext>

新增的部分都有很顯眼的標註,其中 Raw HTML 黑名單的 HTML 標籤的<都會被轉成 entity,基本上看起來是安全性考量,不過不太確定為何有些很老的標籤出現,感覺上和安全性比較沒關係。另外我還注意到emojireference link沒包含在這份 spec 內,emoji 或許是因為實做上的問題,轉成 unicode 字元相容性不好,要用 img 會有不少相依性問題,而 reference link 大概是因這是比較針對 GitHub 網站的特性。

GitHub 轉換 Markdown 引擎的過程也有在文中說明,這次 Markdown 引擎是從Sundown(更早是 Ruby 實做的redcarpet的樣子)改成cmark,當然為了這些新語法,他們 fork 了自己的版本出來,然後在真的套上 GitHub 本站前,有先做過測試,結果發現有 1% 的文件(所有的 Markdown 文件,包括 user comment、issue...etc)會受到影響,而且判斷方法不是單純 diff 輸出結果,而是 diff 正規化過的 HTML 文件樹,不過即使只有 1% 的文件,那也是很大量,後來他們又更仔細分析,發現會受影響的幾乎都是 issue、user comment 之類的內容,是存放在 GitHub 資料庫內的,而不是 repository 內的文件,所以他們可以直接修改,如果是 repository 內的文件,因為要看 sha1 hash,所以是改不了的,後來他們魔改 Sundown,讓它吃舊文件然後吐出符合新 spec 的 Markdown 文件,接著跑了幾天把全部需要修改的舊文件(1%)都轉完,所以現在除了少數文件外,剩下的文件都是符合 GFM spec 的文件了。


GitHub 提供專案授權簡介與概要

Do What The F*ck You Want To Public License,

大概上週看到有人在 Twitter 講到 GitHub 現在會在專案上顯示該專案所使用授權條款的摘要,長的像是上面那樣,官方也有發表公告,其實這個修改是結合之前的授權偵測Choose a License

Choose a License 也是一個 GitHub 的附加服務,用來協助使用者挑選適合的授權條款,現在在 GitHub 建立新的專案時,可以順便初始化專案,包括建立 README、產生.gitignore和挑選要使用的授權條款:

Initialize Project

授權條款旁邊的 i 點下去其實就會送到 Choose a License 網站去了(不過兩邊沒有連動接起來就是),Choose a License 網站則針對每種條款都一份重點摘要,分為 Permissions、Conditions 和 Limitations 三個區塊,分別條列出該條款可以做什麼(例如商業使用)、有什麼條件(例如需要也使用相同條款授權)和條款的限制(例如免責),而現在 GitHub 上顯示的條款摘要其實就是這邊的資訊搬過來的:

Choose a License

Choose a License 網站其實有很多授權條款的整理,而不是只有常見的幾種,可以看appendix頁面有完整清單,可惜裡面沒有Vim License,另外特別想說的是 GitHub 自己(應該沒錯)提供的Unlincense,相似於創作領域的CC0,就類似丟到 Public Domain 的意思,不過保留了免責條款,講到免責聲明,就還要順便提一下WTFPL,它其實也是超自由的 License,差別就是連免責聲明都沒,其實是更加接近丟到 Public Domain 吧?

最後想說的是 GitHub 用來判斷專案使用的授權,用的是licensee這個 Ruby Gem,看起來完全就是為了做這些事情寫的,我看好像也沒其他類似功能的專案,作者 Ben Balter 其實也是 GitHub 員工。


Guetzli: A New Open Source JPEG Encoder

Guetzli

今天一早起來就看到 Google發表的新的 JPEG 壓縮程式,叫 Guetzli(一種瑞士餅乾),這是 Google 繼ZopfliBrotli之後,算是第三個比較容易被大家廣為使用的新的節省網路流量的工具,這次主要針對 JPEG 圖片格式,和之前 Mozilla 的mozjpeg的作法一樣,保持目前 JPEG decoder 的相容性,然後看能加強 JPEG 圖檔到什麼程度,我稍微測試了一下,結果還不錯,目前還沒有 homebrew formula,如果要自己 build 的可以參考這篇,基本上就是用 bazel 來編譯,然後可能會需要先裝 libpng 和 gflags,這兩個可以用 homebrew 安裝:

brew install libpng gflags

然後裝bazel

brew install bazel

然後到專案目錄下執行編譯指令:

bazel build -c opt //:guetzli

結果就會把執行檔放到bazel-bin/guetzli這位置,就可以拿來用了,不過其實官方 GitHub repo 上的release那邊就有編譯好的版本,抓下來用 Terminal 執行chmod +x也可以用(我是自己丟到/usr/local/bin/裡面),指令很簡單,可以加上--quality,預設是 95,不過最小只能 84,設更小的值會跟你說,真的想要的話自己去改原始碼...

速度就如大家所說的,和其它工具比起來真的慢很多,感覺是有一些 recursive 找最佳解的過程,輸出的結果我覺得最讓人印象深刻的是對於純色色塊的處理,也比 mozjpeg 好上不少,輸出檔案的大小不一定會是最小的,不過品質好很多,差異是達到我可以放棄這點容量差距,而寧願要這畫質改進,然後就是 Quality 100 可能會體積暴漲,我隨便測試了幾張圖片,看起來設到 90 品質就蠻不錯的,看來目前通行的圖片最佳化工具又要有一輪更新了。


網路發佈資料之最佳實踐

Data on the Web Best Practices

前幾天 W3C 發佈了這份文件Data on the Web Best Practices(DWBP),內容是關於在網路上發佈資料時的最佳實踐(公開或非公開的都適用),讓我想到了之前的 g0v summit 羅佩琪分享提到的一個重點,開放是有成本的,當時演講的影片:

稍微看過這份文件後,覺得之前確實蠻缺乏這份整理好的文件,每點看了就都覺得,確實是應該要這樣的,不過沒有這種整理好的 checklist 其實真的要做的時候還蠻容易漏東漏西的,然後就是,每一點都是成本啊!!

整份文件還蠻有翻譯的價值的,比較不像是 HTML Spec 會常常更新,不過我自然沒這麼多時間可以翻譯,所以就先把重點標題翻起來放,以後有人要開始就先有個基礎了,DWBP 整份文件有 35 點 Best Practice,每一點都有標題、簡述、原因、預期結果、可能實做方法、如何測試、證據、好處、範例等內容,其中好處的部分是分成八種:

  • Comprehension,人類容易理解理解
  • Processability,可程式自動處理
  • Discoverability,可讓程式自動發現
  • Reuse,容易重複使用
  • Trust,可靠
  • Linkability,可連結
  • Access,容易存取
  • Interoperability,容易互動(發佈者和使用者之間)

我只翻譯了其中的標題和簡述,順便附上每一點的好處(上面的八種好處),以下就是這 35 點 Best Practice:

閱讀「網路發佈資料之最佳實踐」全文

Safari 10 for Developer

Safari 10 跟著 macOS 一起出來了,這次更新了不少東西(對於網頁開發者來說),Apple 也依舊放了一份文件在他們的 Developer Library 裡面,以下列出我覺得比較有趣的:

CSP 2.0

CSP 2.0 和之前的版本相比,最主要是多了非常多可以控制的權限,也有幾個名稱有改掉,不過基本上格式是相容的。

Shadow DOM

Shadow DOM 1.0 標準,這也讓 Web Component 的理想又往前賣進一步了。

ES 6

號稱支援度 100%,看起來是依據ECMAScript compatable table的,不過在 module 的面前,還沒有真的 100% 的啊,另外主流瀏覽器其實支援度都蠻高了,之前 Edge 還放話說領先的,沒想到現在就已經被 Safari 10 和 Chrome 超過了,而 Chrome 看來也之差 tail call 而已,接下來應該又要開始效能比拼了吧。

Inline and Auto Video Playback in iOS

這也是等很久的功能,之前就有先開放靜音影片能直接在 iOS Safari 上自動播放,主要的考量是,gif 和 mp4 相比,還是 gif 比較吃資源啊。

ES Internationalization

ECMA-402 支援,這也是希望快點普及的東西啊,不然數字、日期什麼的搞本地化實在很麻煩。

WOFF 2.0 Support

令人意外的有點慢,不過還算很有誠意的把很新的CSS Font Loading Module Level 3的 API 做好了。

#RRGGBBAA

新的 CSS color 格式,也是前陣子才 propose 出來而已,這樣以後就可以讓 CSS 裡的顏色格式統一點了。

Right-to-Left Language Support

主要是 RTL 頁面 scrollbar 的位置終於會換邊了。

Media Query for Wide Color Gamut Support

廣色域的 CSS media query,主要是因為最新的 iMac 和 iPhone 7 都有支援 P3 色域了。

WebDriver Support

主流瀏覽器最後一個支援的...

Apple Pay for the Web

這真的蠻兇狠的,不過 Google 也有在 Android 做類似的就是了。

大概就這些了,其實也列出超過一半的項目了,Safari 這種更新頻率其實比起其它幾家來說吃虧不少,不過還是一直有跟上最新進度,其實也蠻厲害的,更何況現在 Google 都把人拉到 Blink 去,有回到 Webkit 的貢獻似乎比例上不高。


7 Bit Encoding and Email

最近工作上比較常接觸到 email 的東西,然後比較認真的看了 HTML email 信件的內容,以前我以為都要用 base64 編碼來處理,可是用 base64 來處理 HTML email 我一直覺得很不合理,一來大小會變 1.33 倍,二來整個 HTML 原始碼傳送時會變的幾乎無法辨識,收信軟體還要先解碼一次才可以 parse HTML,感覺完全不需要多此一舉,總之就是覺得為什麼要做這麼愚蠢的事情,明明看起來MIME就沒這樣限制,所以我應該可以這樣寫:

Content-Type: text/html; charset=utf-8

然後內文直接放 HTML 原始碼,可是不知道為什麼沒人這樣做,事實上也不 work;最近多看了一些郵件原始碼才發現其實還有個 Quoted-Printable encoding 也很常用,看起來比 Base64 的結果還要接近原始碼許多了,所以就研究了一下它到底是什麼格式。

Quoted-Printable encoding 的基本原理就是用=作為 escape 字元,然後可以把要轉換的字元轉成=字碼的形式,例如 Big5 中文的就要轉成=A7=DA,規範上要轉換的是除了可見(printable)ASCII字元以外的字元都要轉,而 ASCII 是個 7bit 編碼,字碼只有從 0 到 127 而已,而 email 要用 Quoted-Printable encoding 的主要原因其實就是為了讓文件內的每個字元編碼都維持在 7bit 編碼範圍內,現在大家常用的編碼像是 UTF-8 和以前常用的 Big5 等都是 8bit 編碼,兩者差別就在於每個傳輸的 byte 中有沒有使用到第 8 個 bit,轉成二進位的時候,7bit 系統編碼不會用到最左(higher-order)邊的那個 bit。

為什麼需要用 7bit 的文字編碼呢?主因是計算機和電信網路早期很多系統是只支援 7bit 編碼的,SMTP 的規範就直接要求 TCP 傳輸時,每個 byte 最左邊的 higher-order bit 要填 0:

The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.

當然這規範很落後時代,所以在MIME(Multipurpose Internet Mail Extensions)規範其實也有Content-Transfer-Encoding可以指定傳輸用的是什麼編碼:

Content-Transfer-Encoding: 8bit

不過為了相容舊系統,還是很少真的這樣使用的信件在傳遞,因為要是傳到了 7bit 系統,小則亂碼、大則程式當機。不過這就帶出另外一個問題了,難道 7bit 系統只能傳輸 ASCII 字集嗎?因為我還蠻常看到日文的純文字郵件,就去找了一些來看看,結果發現到有的是用ISO-2022-JP,而且是使用 7bit 的傳輸:

Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

信件內容的文字也都很正確,沒有亂碼:

iso-2022-jp

於是就看一下ISO-2022的介紹,發現原來是個很早就有的 7bit 編碼方法,後來根據這方法有訂出了 CN、JP、KR 等語言的編碼,不過比較通行的看來只有 ISO-2022-JP,然後我也找到 HTML email 用 ISO-2022-JP 的:

ISO-2022-JP

看起來就像是我理想中的 HTML email 原始碼啊,所以問題的癥結其實是,大家為了相容於舊系統,所以都用 7bit 傳輸,要 7bit safe 的 encoding 選擇有限,除了比較通行的 ISO-2022-JP 可以給日文用、字元太少只能給英文用的 ASCII 之外,其它語言就只能用 Base64 encoding 和 Quoted-Printable encoding 了,所以事實上其它 7bit 編碼的內容,也是可以直接透過 SMTP 協定來傳輸的,只是要看收信端的軟體能不能支援解碼,像是已經不太有人用的UTF-7就是 7bit 的 unicode 編碼。

最後,就是假設我們已經不用擔心老舊系統的時候,其實只要這樣寫在 MIME header 裡就可以直接傳 UTF-8 的 HTML source,不用再經過任何編碼處理了:

Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

不過距離這一步不知道還有多遠就是了。


Web Push

前兩天要研究一下 Chrome 接 GCM 的實做,發現到 Google 又出一個新的服務叫 Firebase,然後新的 cloud messaging 服務就叫Firebase Cloud Messaging(FCM),隨便看了一下 Google 官方的文件,結果發現有提到另外一個正在制訂中的Web Push Protocol,照文件的說法,FCM 也只是個過渡時期的方案,最終目標還是用這個 Web Push Protocol,於是我就研究了一下他的設計,發現設計的還蠻漂亮的。

整個 Web Push Protocol 的基本架構如下圖:

Web Push Protocol

User Agent(UA) 通常是行動端的應用程式、Application 則是自家服務的後台;整個流程首先是 UA 透過 HTTP/1.1 POST 去跟 Push Service 訂閱(第一條橫線 Subscribe),然後會拿到一個 subscription resource,可能長成:

https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG

另外還會拿到一個發訊息用的 push resource:

https://push.example.net/push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV

可以注意到兩個 resource 後面的 token 是不一樣的,兩者之間的 mapping 就是 Push Service 來負責;然後 UA 拿到這兩個網址後,發訊息用的 push resource 要交給自家服務的後台,也就是圖上第三條橫線 Distribute Push Resource,另外一個 subscription resource 則是要自己使用,UA 用 HTTP/2 打 GET 到 subscription resource,然後 push service 會把連線保持住不關掉,這就是圖上的第二條橫線 Monitor;自家服務後台的要送訊息的時候,就打 POST 去 push resource,也就是第四條橫線,從 Application 到 Push Service 間的 Push Message,push service 收到這個訊息時,就利用 HTTP/2 的 Server Push 機制主動傳送訊息,最後這個動作就是第五條橫線的 Push Message 了。

就這樣很漂亮的用 HTTP/1.1 + HTTP/2 把一個基本的 Cloud Message Service 的協定建構起來,而除了這最基本的訊息傳遞外,這份文件還有定義像是訊息重要度、訊息回條、群組訊息等等的方法,設計都還蠻漂亮的,安全性的部分則是限制走 HTTPS over TLS,還有 operation 相關的說明,像是實際上要跑起這個服務,需要大量的 TCP connection 等等(因為都走 HTTP 了),有興趣的可以加減看一下。

補充:Firefox 目前實做的似乎就是這個協定更早版本的草案


My First Patch to Firefox

zh download dialog

OSX 自從升級到 10.10 之後,繁體中文版 Firefox 就冒出了一個 bug,一堆使用到作業系統原生的視窗,像是下載圖片,開啟檔案等等的,都會變成簡體中文介面,這個問題在 Bugzilla 上的編號是1089363,畫面看起來就像上面的圖一樣,這個問題的狀況,推測是 OSX 本來在這種系統對話框,會使用使用者現在設定的系統 locale,但是 10.10 改成應用程式正在運作的 locale,然後 Firefox 本來會用 localeAB_CD中的AB段而已,所以zh_TWzh_CN就都會變成zh,然後 OSX 的zh又會變成簡體中文,結果就變成這樣了。

其實這個 bug 的解法, Steven Michaud 很早就提出了,就是把本來 locale 的 resource 目錄的名稱改成zh_TW,大概 diff 如下:

AB_CD = $(MOZ_UI_LOCALE)

-AB := $(firstword $(subst -, ,$(AB_CD)))
+ifeq (zh-TW,$(AB_CD))
+LPROJ_ROOT := $(subst -,_,$(AB_CD))
+else
+LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
+endif
+LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj

其實不會很難,不過因為 Firefox 的程式碼變動很快,連 build script 也常常變動,那個 patch 檔出來的時候已經不能用了,然後又沒人處理就這樣一直拖下去,前陣子 Moztw 那邊又被提出來一次,剛好我為了弄 WebIDL 相關應用的時候有 build 過 Firefox,想說應該可以處理看看,就接下來嘗試了,build 本身蠻簡單的,就照著網路上的文件就好,比較難的是要 build 成特定語系的,找很久才在 Moztw 討論區找到答案,要在.mozconfig裡面加上:

ac_add_options --with-l10n-base=/d/lang
ac_add_options --enable-ui-locale=zh-TW

其中第一行設定的路徑要指定到你指定的位置,而且要絕對路徑,然後在該目錄 clone 翻譯的 repository 下來,可以在l10n-central那邊找自己的語系,以zh-TW來說:

cd /d/lang
git clone http://hg.mozilla.org/l10n-central/zh-TW/

然後這樣就可以 build 中文版了,build 完執行就看到精美的黃底紅字 XML 解析錯誤視窗。

Firefox Missing String

還好我有點經驗,知道 Firefox 的介面是 XUL 寫的,然後字串是用 XML entity 方式存在,所以很快就想到是翻譯問題,於是上去找了 l10n dashboard 看看繁體中文的狀況,看的是 fx_central 這棵樹下的字串:

Firefox l10n stat

可以看到目前有缺哪些字串,因為字串還沒穩定所以也還不會有翻譯,所以就需要手動進去把這些 entity 的定義補上,內容隨便填,然後重新 build 一次,結果就修好了!

nightly zh_TW download dialog

然後就開始想辦法生 patch 檔案了,中間也有用過hg mq,最後都固定改好,commit 後用hg export . > fix.patch,總之改好我就丟上 bugzilla 了,結果第一個 patch 只改到一個檔案,實際上應該有五個檔案要改,而且才隔一天,Makefile 就被別人改過了,只好重新找位置修改,重新生 patch,到最後一個 review 過,build 也過的 patch 中間還發生了不少事情,包括 Makefile 被別人又改動一次,用ABorLPROJ的命名問題,字串的變化造成假翻譯又要增加,還有 build 工具 mach 被人改壞,和推上去之後有 build 失敗的狀況等等,非常的一波三折。

其中 build 失敗是 b2g 的 build 失敗,原因是我有地方改錯,不過要測試也是要重新設定,參考的是Building the Firefox OS Simulator這份文件,把.mozconfig改成:

. "$topsrcdir/b2g/config/mozconfigs/common"

mk_add_options MOZ_OBJDIR=../build
mk_add_options MOZ_MAKE_FLAGS="-j9 -s"

ac_add_options --enable-application=b2g
ac_add_options --disable-libjpeg-turbo

重新 build 看能不能過。

改完產生的 patch 檔上傳到 bugzilla 時,要勾選 Content Type 是 patch,然後 review flag 設定成?,選一個 reviewer,通常會有 mentor 來跟你說選誰好,我的情形是timdream在幫忙,接著就等 reviewer review,他 review 過的話, review flag 就會變成+,然後就會收到一封「Congratulations on having your first patch approved」的信件,說了一些後續可以做的事情,接著要做的就是讓 patch 真的進去 repository,可以在票的 keyword 加上checkin-needed,就會有機器人自己來把你的 patch check in 進 mozilla-inbound 這個 repository,然後丟上機器人自動編譯和測試,例如這個我 B2G build 失敗的例子,都過了就會進 mozilla-central,之後才照順序進 mozilla-aurora、mozilla-beta、mozilla-release,現在進去 mozilla-central 的大概要等 Firefox 42 才會上線了,應該是和 OSX 10.11 同時吧。


此類別所有文章