Archives for november 2012

feature/killsdf branch merged

What was SDF and why did we kill it? LibreOffice source code contains translatable content in various file formats. It was desirable to present translatable content to translators in a single file format, so they did not have learn how to edit different file formats. Therefore back in the OpenOffice.org era SDF file format was invented. It was a simple tab separated text file. Localization tools extacted translatable content into SDF file format, and localized SDF files were merged back to source code during the build.

One cannot imagine simpler file format, than a tab separated text. When I translated OpenOffice.org into Hungarian, I built a tool set around it, and translated it happily. But not every translator was a programmer, or capable of using scripts. Translators demanded PO file format, which is a quasi-standard file format for localization in the open source world. Translate Toolkit and Pootle became part of the localization process, en-US SDF file was converted to POT (PO Template) files, and translated PO files were converted back to SDF manually.

When LibreOffice project started, I wanted to amend the process for two reasons.

  1. Huge SDF files blew the git repository. Git does not work well with large, frequently updated text files.
  2. Manual conversion from PO to SDF was a tedious job.

Therefore I implemented to store PO files in git, and convert them to SDF automatically during the build. In LibreOffice 3.4 we used po2oo from Translate Toolkit for the back-conversion. In LibreOffice 3.5 po2oo was replaced by po2lo written by Miklos Vajna, which was 30x as fast as po2oo.

But why convert translations from one format to another, why not use PO files directly? This is what was developed in feature/killsdf branch in the past few months. Most of the programming work was done by a young developer, Tamas Zolnai, who was a trainee at Novell Hungary in the summer, and now he is a fellow of FSF.hu Foundation (FSF.hu sponsors his work on LibreOffice). Now localization tools extract translatable content from the source code directly to PO files, and they read PO files directly during the build. SDF files are not generated any more. At the same time localization tools were refactored. Perl scripts have gone. All tools are in C++ now. Further cleanup and optimizations are on the way on master branch. I fixed the last remaining issues after the merge in Munich Hackfest 2012.

Jó hír, megkezdődött az Apache OpenOffice kódok integrálása a LibreOffice-ba

Végre megkezdődött.

Az itt leírtak szerint az AOO 3.4-ben megvalósított SVG import, és a vonalkupakok kerülnek először sorra a LibO 3.7-be.

LibreOffice Portable 3.6.3.

LibreOffice Megérkezett a LibreOffice 3.6.3 hordozható (portable) változata.

A korábbiakhoz hasonlóan az új változat hibajavításokat jelent (a hagyományos változat hibajavításai érvényesek itt is), új funkciót nem ad a programhoz.

A LibreOffice Portable 3.6.3 letölthető a szokásos helyen, ezúttal is kétféle változatban (a magyar nyelvet mindkét változat tartalmazza).

LibreOffice 3.6.3

LibreOffice Megjelent a LibreOffice 3.6.3, a harmadik hibajavító verzió a LibreOffice 3.6-os sorozatból. A javítások listája szokás szerint két részletben érhető el: RC1 (81 hiba) és RC2 (12 hiba). Minden egyes hibajavító kiadás növeli a program általános minőségét és stabilitását, egyre szélesebb körben javasolható bevezetésre.

A berlini LibreOffice konferencián elhangzott, hogy a fejlesztők a bejelentett LibreOffice-hibák 58%-át zárták le. Ebbe nem számít bele az új funkciók kérése, és a lezárás nem feltétlen jelent javítást; vannak többszörösen bejelentett vagy nem reprodukálható hibák is köztük. Ennek ellenére ez elég jó arány szabad szoftveres viszonylatban, a megnyitott hibajegyek száma nemrég lépte túl a 10 ezret. A minőségbiztosításon dolgozó közösségi tagok egyre hatékonyabbak abban, hogy az igazán lényeges hibákra irányítsák rá a fejlesztők figyelmét. A 100 napja elkezdett Hard Hacks projekt sikeresnek mondható, hetente kb. 5 nehéznek gondolt hiba kerül az Engineering Steering Comittee elé, és ezek jelentős részére megoldás születik 2 hét alatt.