Pavel's diary

I have uploaded .warnings files generated in my build of SRC680_m222. They show that there is serious issue in the workflow of many languages connected with deleted directories.

During the development of 2.3, there were several removals of directories and respective translations. But still 16 GSi files contain strings from chart2/source/controller/menu/localize.sdf, sch/source/core/localize.sdf, sch/source/ui/app/localize.sdf and sch/source/ui/dlg/localize.sdf and 19 GSI files reference translations in svtools/source/Accessibility/localize.sdf. But these files do not exist in the current sources!

Please verify your tools and fix your GSI files.

My build system is used by people who can't build their languages on some systems. It is time consuming to provide builds for many languages on more systems, thus I have to set some rules. They are very simple - I only build for active languages.

When there is an issue with the language, I expect some response. When the GSI file contains bugs, I expect them to be fixed soon without me doing anything - the output of the build system provides enough informations for everyone to fix their GSI files (more on this below). I also expect regular updates to the GSI files. It doesn't make sense to build your language when you update your GSI file just once before the release. I can use the resources for other languages. It also doesn't make sense to build languages that are not based on newer POT files.

This document is a small HOWTO that should help you to make integration smoother. I'll only integrate languages with active teams and I'll remove languages of in-active teams. I do not want to build the language that has old, unmaintained GSI files, because the CPU time, disk space and bandwidth can be used for other active languages instead.

So what you should do to have your language added?

• mail me the ISO code of your language and technical contact for your language
• Please make sure that the data about your language in our table are correct and complete.
• Please send me the URL of your GSI file that is named GSI_cs.sdf.bz2 (bzip2 or gzip compressed GSI file where cs is the ISO code of your language). If you'd like to know the reason for this, see the script updating all GSI files I run just before every build.
• regularly check the outputs of the build system - both installsets and also bug output files ;-)

I expect that the submitter of GSI file handles issues in their GSI file. Mistakes happen, but what should not happen are mistakes that are not fixed ;-) I do upload several files you can use to check/fix your GSI files. They are stored in the directory http://ftp.linux.cz/pub/localization/OpenOffice.org/devel/680/SRC680_m222/Build-1/build/ (this applies to SRC680_m222 which is the latest, right now).

One type of such files are .err files. This is the output from gsicheck utility which you should always use before uploading your GSI files. If the .err file for your language exists, you have a problem! You should fix it.

Another type is .warnings file. This file contains error output from the tool that is merging the translations back to the sources. It reports problems when e.g. the file it should merge into doesn't exist in the sources. This means that you have used incorrect/old POT files to create your GSI file! You should fix it.

I'll update this blog entry with comments from active languages. The next blog entry will summarize the status of GSI files in my SRC680_m222 builds.

The milestone SRC680_m222 was nice experience. It builds smoothly on all my current platforms. Good work!

The release of OpenOffice.org 2.3 is closer, but we still have ~230 issues with the target 2.3. Please have a look at your issue list.

There was (hopefully) the last meeting about OOXML proposal at Czech Standards Institute today.

Seven people joined the meeting - two from Microsoft, one from IBM, one from CompTIA, one from ČNI, Jirka Kosek as an editor of Czech proposal and me. This meeting was the most constructive from the series of meetings about this proposal. There was not only interesting and constructive technical discussion about the proposal itself, but also some fun (Jirka and me like Emacs, and one of Microsoft employees likes vi ;-).

The agenda was simple: walk over rejected and accepted comments and agree on final comments. I have to say "Thank you" to all people there, because we were able to constructively agree (or change) on all comments and we only rejected one "would be nice, but..." comment from Jirka. Other comments were accepted and we even find some other discrepancies in the proposal (one of the favourite was mine comment about ST_LangCode which was understood wrongly by Jirka and rewritten into yet another valid comment about the same element whose description's first sentence contains two mistakes - I noticed the first and Jirka the second. I was not able to spot the Jirka's bug, because I know that MS LCID for en-US is 1033 decimal, thus I read "Here is the list of hexadecimal values: 1033, ..." as "Here is the list of numbers: 1033, ..." But anyway, two digit hex number can't store 1033 anyway, basic maths... 8).

The good atmosphere was destroyed by Petr Wallenfels (not his fault though) from ČNI who has shown us several (approx. 30) letters from Microsoft partners and customers. They have all almost the same contents "We would like ČNI to accept this proposal, because ...". There was no negative letter. Fortunately this is not how ČNI works. The complete process was transparent and only technical comments were allowed. Looks like all writers were victims of some business politics around OOXML. This was the only sad point in the meeting. It was poor from the person/company who organized this.

Yes, OOXML standard is bad. It is seriously broken in several aspects that these people are not able to judge by themselves, thus it has no sense to take care about such comments. They missed the chance to make it better. And they like it - they all wrote it in their letters...

Lunch at KFC with Jirka and Michael J. from Microsoft. Interesting discussions.

Here it is: This time, its author is Jirka Kosek who is preparing the OOXML statement on behalf of Czech Standards Institute.

Update: Jirka uploaded his pics here.

I'm the proud owner of this copy now. The first one was fake (only white sheets of paper), but this one is real! Printed on recycled paper, A5, double sided.

The milestone SRC680_m221 was smoother (sure, because all problems were masterfixed before the milestone was made ready :-).

I have included unomacli64 child workspace, so after ten milestones, I finally have usable x86_64 build.

Aqua native development cws aquavcl02 was resynced to this milestone because it includes native filepicker.

I still have to work out sample online update feeds for translators to be able to see and test online update check window.

Before SRC680_m220 was made ready, we spent lot of time on it doing usual tests. But the real world stuff is a bit different.

I have resynced aquavcl02 cws with SRC680_m220 and thus I started all builds with this cws. And with all languages. This was the first problem. New HelpLinker crashes on Khmer swriter for some unknown reason (#i79500#).

Then I started building on x86_64 to realize another build breaker (with patch already known, thanks to PhillipL).

Difficult...

The draft of the reply to OOXML proposal from Czech Standards Institute was published. It is written in mixed Czech and English. The statement is "no with 65 issues to be solved".

The process to generate this draft was very transparent. Thanks goes to ČNI and Jirka Kosek.

Slovak mountains are another place, where I like to spend my holidays. This time, we (my wife, son and me, and my parents-in-law) rented a cottage in the village Zázrivá and used it as a base for our trips.

My son especially enjoyed the statue of Jánošík in Těrchová and walking around wet garden after rain 8) I enjoyed taking photos from the top of V.F. Kriváň mountain and from the bottom of Šútovo's waterfall!



Wonderfull week without e-mail (almost, you know me ;-).