LibreOffice 正體中文文件

德國柏林，2015年4月17日 LibreOffice 社群正在準備下一個主要版本，預計在七月底發佈，將會有一個著重於新功能、和軟體臭蟲及功能退化的修復活動。這次的活動將會持續三天，從2015年5月22日至5月24日，並將會檢查 LibreOffice 5.0 的第一個測試版。 在這幾天裡面，導師會在 UTC 早上8點至晚上10點，經由 QA 團隊的 IRC 頻道及郵件列表協助經驗較少的志願者分類臭蟲。 不能在這段期間加入的人們，也歡迎在您有時間時一起來幫忙。六月時會有另一個臭蟲狩獵季活動，以測試 LibreOffice 5.0 的第一個發行候選版。 LibreOffice 5.0 Beta 1 將會在這個連結： http://dev-builds.libreoffice.org/pre-releases/ ，一直提供到六月初。 要取得更多資訊，請見： https://wiki.documentfoundation.org/BugHunting_Session_5.0.0.0 。 決定更改 LibreOffice 下一個主要版本的命名／編號方式是因為下列這些理由： LibreOffice 的下一個主要版本將會提供原生的 Windows 64 位元版本，以及（至少在 5.0 系列家族中）在行動裝置及雲端上。 LibreOffice 的下一個主要版本將會加入另一批顯著的視覺及可用性的改進，這將會完成始於 4.4 版的活動。 在編號上的改變會更容易顯示與前代版本的功能差別，並說服越來越多的使用者切換到 LibreOffice。 最後，2015年是文件基金會與 LIbreOffice 公佈的五週年。 新聞來源： First bug hunting session for LibreOffice 5.0

德國柏林，2015年4月9日 文件解放是文件基金會的其中一個專案，在2014年4月初宣佈，以整合不同的處理專有及舊式檔案格式的函式庫到 LIbreOffice 中。其想法是在單一個軟體倉庫中提供函式庫讓其他軟體專案願意部署，以簡化整合方式。該專案目前由兩個 LibreOffice 的長時間貢獻者，Fridrich Strba 及 David Tardon 所領導。 在2014年，該專案的成員釋出了一個新的框架函式庫，稱為 librevenge，其包含了所有的文件介面及輔助程式類型，以簡化其依賴鏈。此外，他們現在也開始了新的函式庫以匯入 Adobe PageMaker 文件，libpagemaker，於2014年的 Google 夏日程式碼大賽由 Anurag Kanungo 所編寫完成。 現有的函式庫也被擴充以支援更多的檔案格式，像是 libwps 就讓 Laurent Alonso 加入了 Microsoft Works 試算表與資料庫的支援。他現在正在努力的加入 Lotus 1-2-3 的支援，這曾經是個人電腦使用最頻繁的舊式檔案格式。他也已經在 libwmaw 中加入了超過 20 種舊式的 Mac 檔案格式的支援。 開發者已經建立了兩個匯出函式庫 ─ ePub 的 libepubgen、AbiWord 的 librvngabw ─ 並且目前也正努力改進 Adobe Freehand 的匯入過濾器 ─ libfreehand，以及 Apple Pages 的 libetonyek。 文件解放函式庫可用於 Corel 公司的 WordPrefect（包括圖形）與 Corel Draw、Microsoft Works、AbiWord、Microsoft Publisher 及 Microsoft Visio、Apple Keynote、Adobe Freehand、Aldus PageMaker，加上許多 Mac 的舊式檔案格式及許多電子書格式。 在文件解放專案旗下的每一個函式庫都是作為一個獨立的專案存在，有自己的維護者、發佈計畫及授權條款，其遵循著自由軟體基金會及文件基金會所倡導的自由軟體精神。 要了解更多資訊，請見： http://www.documentliberation.org/ 新聞來源： The Document...

目前 LibreOffice 指引手冊的翻譯放在 GitHub 上面，以 git 版本控制系統管理。因此想要協助翻譯，第一件事就是到 GitHub 上面申請個帳號囉！然後利用 git 的版本控制流程來達成眾人翻譯。 既然是眾人翻譯，必定存在工作協調上的問題，否則無事先協調，極度容易導致重複勞力的情況，也就是今天你心血來潮打算翻第二章，沒有明講就默默動手了。剛好今天來了一位小王，他突然間有個靈感就是告訴他應該幫忙翻譯第二章，於是你們兩個人都展開翻譯第二章的奇幻旅程。假設小王今天時間比較多，於是他翻完了，提交到自己的倉儲中，接著對原本來源提請 Pull Request (拉入請求)，也就是把自己的修改之處推回來源中；於是你就看到小王發的請求，然後對沒有事先協調工作懊悔不已。 所以我們需要一個溝通管道，目前我們採用 Google Groups 上的 libotw-general 群組來協調貢獻者的工作。溝通的概念很簡單，就是先發文說「嗨，大家好。我想要幫忙某某章的翻譯，先認領囉～ 我會把會翻的地方翻完然後盡快 Pull Request 的！:)」之類的。 認領的工作不見得要非常努力本全部都處理完到達非常精美的地步才能上傳。實務上，自由暨開源專案對於版本發行的精神是，「盡快發行、經常發行」(Release early, release often)。這個好處就是，你只要忙到告一段落就發表，如果這時剛好有誰想要接手都能成行，不會造成資源鎖死他人動不得，而且你實際上也沒什麼時間處理的問題。所以，只要沒時間弄，就盡快上傳自己的成果然後宣告給大家知道，說個「嗨，大家好又是我。XD 我弄了一小部份結果接到新工作後又沒間弄了，所以就先作到這邊囉！麻煩處理一下 PR (註：Pull Request 簡寫)。:P」之類告知一下即可。 這大致上就是目前自由暨開源專案的常見工作協調方式。以下簡介翻譯流程。 0. GitHub、Google Groups、和 IRC 1. GitHub 簡易概念 2. 安裝 OmegaT 3. OmegaT 操作方法 4. Pull Request GitHub、Google Groups、和 IRC 首先就是先註冊個 GitHub 帳號，然後申請加入 Google 網上論壇的 libotw-general 群組 。 G...