看了一圈自己的還有其他使用英文版閱讀器的同學的分享，基本沒有出現這個問題，因爲在英文版裏“共享”這按鈕叫做“share”、“共享備註”這個按鈕叫 做“share with note”；看來問題是出在對“share with note”這個按鈕的翻譯了，這個按鈕想要表達的意思其實是“帶備註的共享”而不是簡單的“共享備註”。按照字面意思的理解，“共享備註”應該是對共享的 備註，那麼先點擊“共享”按鈕，之後再對這個共享做一次備註，這樣的邏輯應該是沒有問題；而如果翻譯成“帶備註的共享”的話，意思就表達的很清楚了是在共 享的同時加註備註，是比共享更遞進一個層次的共享。
稍後，我在我使用的英文版google reader裏實驗了先點擊“share”再點擊“share with note”，發現在分享的feed中也是出現了2次。如此看來，google在對這2個按鈕的處理是出現了邏輯的錯誤。“share”和“share with note”是2個並列的但是存在包含關係的功能按鈕。with note實際上是對share的一個層進動作，你可以直接使用share，也可以直接使用share with note，但是當你同時使用share和share with note的時候系統應該做一個判斷：僅僅產出share with note的內容，而不是同時產出2個。
揣測了一下產生這個邏輯錯誤的原因：google閱讀器最早的時候是隻有share（共享），之後添加了share with note（給分享內容添加備註），再之後出現了Add comment（對好友共享的內容添加評論）。是否是在最底層的時候沒有對整個產品做好規劃，底層的邏輯不清楚，導致後來發展出現了斷層？在新增給分享添 加備註功能的時候沒有考慮對已有的功能的影響以及與之前功能之間的邏輯關係。
或者說是，google考慮到會有用戶從share到share with note做轉化呢？閱讀完這個文章之後決定分享之，稍後回過神來覺得自己有必要再說幾句，於是再在分享的這個文章上加一個備註。但是，這樣的用戶會佔多大的比例呢？事實上這樣的邏輯是否行得通呢？
經過說服教育，壞人同學給出一個解決方案：系統對這2個行爲作出判斷，當用戶同時點擊了這2個按鈕的時候只push帶備註的共享結果，而忽略這個僅僅共享
的feed掉。那麼，這樣的結果是用戶分享的內容將會出現一個延遲，這個延遲被系統用作判斷了。但是，我有一個疑問：因爲分享是以feed的形式展示的，
也就意味着這個結果是不可撤銷的，如果點擊這個2個按鈕的間隔比較長的時候如何處理？Feed結果是無法像刷新網頁一樣刷新一次去掉之前那個結果的。
我的解決方案：
1）對中文的這個翻譯做調整，“共享備註”這個翻譯顯然是有問題的，修改成“帶備註的共享”用戶會更容易領會，產生錯誤的機率肯定會有所下降；
2）把share和share with note進行合併，統一叫做“share”，在用戶點擊之後會提示是否添加note？同時設置“note”爲非必填項，不填寫的話按照僅僅share發佈，填寫之後按照share with note發佈。
我的解決方案：
1）對中文的這個翻譯做調整，“共享備註”這個翻譯顯然是有問題的，修改成“帶備註的共享”用戶會更容易領會，產生錯誤的機率肯定會有所下降；
2）把share和share with note進行合併，統一叫做“share”，在用戶點擊之後會提示是否添加note？同時設置“note”爲非必填項，不填寫的話按照僅僅share發佈，填寫之後按照share with note發佈。
對比一下英文版和中文版的google reader會發現翻譯成中文後google的產品變味了，這個問題不僅僅是在閱讀器這一個產品中出現了，在google的系列產品中都會存在這個問題，不知道對於這個李開復老師是怎麼認爲的呢？
PS一下：不能使用gtalk直接發送文件的同學可以試試換用英文版的gtalk，會有意外的驚喜哦！~
多扯一句，google閱讀器何時能解決多個好友對同一篇文章的分享的重複顯示問題就更好了！