Pavel's diary

My MyIssues now contains only 62 entries! Finally below 70. -----

My builds of SRC680_m63 for GNU/Linux and Solaris/SPARC are finished now and uploaded to ftp.linux.cz.

Known issues and l10n issues:

• #i37887#: Help shows no content. My next build (build-2, SRC680_m63) will contain change that should workaround it, but there still is issue with helpcontent pages (will be finally fixed in m64).
• #i37360#: Extended tips are in English even for Czech language pack.
• #i37122#: bad encoding of (c) character.
• #i35263# simplify readlicense_oo/prj/d.lst. There is a list of all languages duplicated from solenv/inc/postset.mk.
• #i35265# and #i32386# are about using second naming scheme for language dependent files. One naming scheme based on ISO code is enough.
• #i36315#: gsicheck errors on all GSI files generated from SRC680_m59.
• #i37105#: Generate scp2/inc/macros.inc during the build. macros.inc is another file where you need to add several lines for a new language. It is not necessary, IMO. It can be generated, at least.

-----

Will you join?



It is probably directed at marketing people. More info published by slashdot.org and Heise.de. -----

This diary entry will be the basis of the documentation for POT/PO files handling and OpenOffice.org translation using them. Please send comments to dev@l10n.

OpenOffice.org comes with POT files (see FTP server which is mirroring my directory at ftp.linux.cz). Download the latest file (right now, it is OpenOffice.org-SRC680_m63-POT.tar.gz) and unpack it somewhere. It contains POT files (*.pot) and the file en-US.sdf. You need en-US.sdf to generate GSI/SDF file you can then use while building your localized version of OpenOffice.org.

POT files contain entries like

#: sdslots.src#SID_INSERTFILE.sfxslotinfo.text
msgid "File"
msgstr ""

This particular POT entry comes from file pot/sd/sdi.pot. What does it mean? The module sd contains directory sdi which contains translatable texts.

Texts to be translated are stored inside localize.sdf files in the source code. They are extracted using mechanism that is still to be described (it already is implemented in my build system, but I haven't yet described it). But anyway: it is not that important for translators, because they only need POT files.

Back to sample POT entry: the line starting with #: allows people to look for the string inside OpenOffice.org source code. This particular string comes from sd/sdi/sdslots.src, and has identifier SID_INSERTFILE. The string itself is "File" (see msgid). The translation it empty, because it is POT file (PO Template). PO files look very similar, but they have msgstr line filled in with the translation.

How to generate PO files for translators from these POT files? I wrote a script called POT2PO which can be used for two tasks:

• generating new PO files when you are starting with the translation
• updating existing PO files to newer version of POT files

Just read its commentary section and run it. You'll end up with new/updated po directory with new PO files. Now you translate them, generate GSI/SDF file and build with it. And that's all.

If you have any questions, please ask on dev@l10n. Thanks for your feedback! -----

Milestone SRC680_m63 is now ready. Child Workspaces integrated: eforms2, tbe13, borderingfilterteam28, adc9, vq05, aw020, dba19, babelfish04, rebase, pbfixes01, cd01, vcl30, docking4, fwkp2fix02, pj11, openldap, oasisbf3, impress15, schoasis02, nativefixer1, oooicons, dba18, migration1, pj12, scriptingf8, cfglooseends, calc25, fwkbugfix03, texteng03, ivo06, ause013, aw021, swqbugfixes09, pythonupgrade, dr29, xsltfilter04, iha04, rt04, tl03, iha05 and os41.

I have uploaded POT files for this milestone. -----

I'm leaving for Brno and Luhačovice (not so nice weekend; do not ask) tomorrow in the morning and will be back home probably on Sunday. Thus I have to do many things tonight.

First from the "old" branch: I have started builds for upcoming 1.1.4 on GNU/Linux, Solaris/SPARC, Windows and Mac OS X. I had to stop build on Windows, but GNU/Linux and Solaris/SPARC are already finished and uploaded, Mac OS X is still building (cold ccache ;-)).

I have also finished clean builds (from scratch) of not-yet-ready SRC680_m63 on GNU/Linux and Solaris/SPARC systems. I do not plan to upload them now though.

I have generated POT files for SRC680_m63 (not-yet-ready), but I'll describe them in different diary entry. I have also updated the statistics page for Czech translation project - you can see how many strings are there to be translated and the overall status of our work towards completely localized 2.0. -----

The milestone SRC680_m63 is still not yet ready. But because I have seen in EIS, that there are many child workspaces integrated, I decided to help Hamburg RE ;-) So here is the log from my build and running the current SRC680_m63 (which, I'm repeating myself, is not yet ready for public consumption ;-).

Build issues first. Many of them. But while I was at it many of them were fixed. But there is at least the following must be fixed before releasing: sw/source/ui/app/apphdl.cxx is using Stamp_SetActivateEvent which is not defined now (it was defined in the past though; just comment/delete its call for now). svtools/source/config/itemholder[12].cxx include header files from svtools/... but such headers are not yet delivered (just remove svtools/ from #include lines). sfx2/source/appl/appuno.cxx is referencing variable nFound which is not defined.

Installation issues: During ./install RPMS /tmp/SRC680_m63 several lines like

warning: group other does not exist - using root

were issued. This is because of

$ cvs log solenv/bin/modules/installer/epmfile.pm|grep "sys to other"
2004/10/28 13:12:38 obr 1.12.2.4: #i35695# changed default group from...
#i35695# changed default group from sys to other

Well, #i35695# is about "Compress solaris pkgs" so I do not plan to re-open it because of this. Group other is non-standard...

Runtime issues: bad About (contains "my company" instead of user@machine as defined in makefile.mk), see cvs diff -r SRC680_m62 -r SRC680_m63 svx/source/intro/ooo.src for details.

News: directory presets instead of share, new "first-run" wizard and icons (coming from oooicons child workspace).

See screenshots for more details.

And again: SRC680_m63 is not yet ready, really.

I have used gcc-3.4.1 with visibility and enum patches - see the previous entry in my blog. -----

I have decided (due to various changes I do not want to describe here, because I'm still mad about them ;-) to update my gcc to the same version as Hamburg RE is using for building OpenOffice.org. They use gcc-3.4.1 with visibility and enum patches.

While doing so, I realized that current OpenOffice.org build environment is not ready for it. Why? You need to link with g++, but config_office/set_soenv.in exports LINK=gcc to the environment (#i37731#). There is no clear way for switching between gcc-3.3 (CVER=C300) and newer gcc-3.4 (CVER=341 aka unxlngi6). I've changed my tree manually to use Hamburg RE's unxlngi6.mk.

... I also had an interesting discussion with Ause about cooperative work on not-yet-ready milestones ("Why does my build (correctly!) broke on xml:lang in officecfg module and Sun's does not?") and community-RE. -----

.. I don't because I'm not willing to:

• use non-free operating systems that are able to run Adobe Acrobat
• install KDE to have KOffice

So yes, having PDF editing capabilities in OpenOffice.org would be nice, but anyway: PDF is designed to be a final-form of the document.

But I agree with Erwin that for creating PDF, OpenOffice.org is good enough. And it is free. -----

I have decided (well, Michael decided that I should be punished for not reading the source code of tools I use ;-) to extend my previous small tip about child workspaces in EIS to a complete user-level documentation of EIS.

Environment Information System (EIS for short, http://eis.services.openoffice.org/) is a system that provides valuable informations for OpenOffice.org' developers.

You can access it in two modes - as a guest user with read-only privileges or as an openoffice.org' registered user. I'll describe only access for registered users because guest user access is a subset of it.

To access EIS as a registered user, you have to log in: Use your OpenOffice.org' e-mail address as a Username.

If you login successfully, you'll see your OpenOffice.org' username at the right side of the GUI.

The most important part of the GUI is Child workspaces link: After clicking on it, new submenu is opened. Its entries are described in details below.

My CWSs allows the developer to track his own child workspaces. Clicking on it, you'll see the list of your opened child workspaces in a simple table with complete informations about them: You can also see the status of your child workspaces there (see below for possible states). The names of child workspaces are links to more detailed information about the corresponding child workspace (status history, tasks assigned to this child workspace, modules and other valuable facts): Child workspace can be in one of the following states: planned, new, ready for QA, nominated, integrated or deleted. When you create it using the below mentioned link in EIS, its initial state is planned. When you finally create it using the cwscreate command, it is promoted to new level. If you want to discard it, you change its state to deleted. After your planned changes are finished, you assign it to QA and promote the status to ready for QA. QA person then can change the status back to new (if there are problems) or nominate it for inclusion. After the integration of your child workspace, the status is changed to integrated.

Browse allows you to browse in the list of all child workspaces. As you can see in the image, you can browse the list by the master workspaces (like SRC680, SRX645, ...) and their state.

Another useful tool is Search. I personally found it as the most valuable piece of EIS. You can search child workspaces (TIP: use pj% to find all child workspaces whose names start with letters pj), IssueZilla' tasks etc.

Milestones is very useful if you need to know what was integrated into the milestones. E.g. the following picture shows child workspaces integrated into m62: Releases is very useful if you need to know what was integrated into the release - you have to choose the release in the left panel and the list will be displayed on the right side. In the Create menu, you can create child workspace (it will be in "planned" state until you promote it to new by using cwscreate tool). The name field is the name of the child workspace to be created. Please use descriptive name if it implements a new feature and add e.g. 01 to its name (e.g. writerperfect01, ihateword01 etc.). If it is simple bugfix child workspace, the common standard is to have your id/nick/username appended by the uniq number, like ause01, pj12 etc.

In the field Master Workspace you have to chose the master workspace of your child workspace. Only SRC680 and SRX645 makes sense. So if you plan to work on 2.0 issues, you have to choose SRC680.

You can't change the status of your child workspace while creating, because it will always be created in the state "planned". But later on, you can use the Status select box to change the status of your child workspace.

FIXME: filling QA representative.

The field Members is to be filed with people who are interested in this child workspace. They are then informed about states changes etc.

The Description field is self-descriptive. Please enter the complete description here. It should help people who do not find the child workspace itself descriptive enough.

QA comment is something like a chat between you, QA people and others. Enter useful information only and keep it short though.

To allow some planning, you must also fill in some dates like Estimated due date (ready for QA) and Estimated due date. The first one is your estimation on when it will be ready for QA work. If the date is slipped and your child workspace is not in the status of "ready for QA" you'll receive an e-mail notice about that. Use ISO format for dates (like 2004-11-17 for today). Or press the bubble help icon and read what it tells you ;-)

Level of impact helps people distinguish which applications could be impacted by the integration of this child workspace. For simple build fixes, use "Implementation Details Only".

If your child workspace creates new dialog or changes already existing UI, please check the UI-relevant checkbox. The same applies to Help-relevant. -----

Hamburg RE finished SRC680_m62 milestone with following child workspaces integrated: vq04, scp2fix, nojava1, numforensis, mh1960, hsqldb, fontlists04, hr9, xmlbasic, beansplit, calc24, localedatafixes, swqbugfixes08, jl13, gh8, os38, configure3, oasisbf1, tdoc3, dr27, schoasis01, vcl28, sysui02 and os37.

If you work on Windows, comment out epm check in configure (see #i36561#).

If you have old gcc take care in module automation (file source/server/statemnt.cxx, issue #i37204#).

If you have problems with fonts, please check if the "solution" I proposed in #i37144# helps you.

Please comment-out the check for WITH_FONTOOO in msfontextract (#i32814#).

And finally: hurry up, we are heading to beta! ;-) -----

This diary entry contains the list of issues that can slow down (at least) the process of localization and translation of OpenOffice.org 2.0. These are really only the issues with deep impact on comfort or speed of integration of new languages. I left minor issues out of this list.

• #i35471#: Sort readme / helpcontent2 localize extract content by their appearance in the source. This issues is very important for translation longer texts. localize tool does not export strings in the order as in the source code/source files. Thus translating helpcontent is very hard.
• #i35659# Conflicting files in language packs (after setting DEFAULT_TO_ENGLISH_FOR_PACKING). This is not that critical issue, but it prevents multiple language packs from installation if they share some files. And this is common if you create new language which and not provide e.g. extras yet. English extras will be used even for your language and we have a conflict.
• #i35263# simplify readlicense_oo/prj/d.lst. There is a list of all languages duplicated from solenv/inc/postset.mk.
• #i35265# and #i32386# are about using second naming scheme for language dependent files. One naming scheme based on ISO code is enough.
• #i36315#: gsicheck errors on all GSI files generated from SRC680_m59.
• #i37144#: SRC680_m62: Czech letters incorrect. This just came up with the milestone SRC680_m62.
• #i37105#: Generate scp2/inc/macros.inc during the build. macros.inc is another file where you need to add several lines for a new language. It is not necessary, IMO. It can be generated, at least.

If you have any other issue, please tell me and I will update this list. -----

I'm really impressed by the amount of artists we have in the OpenOffice.org project...

... when the image to be designed is the splash screen of upcoming OpenOffice.org 2.0! The issue to handle this (#i36491#) has unbelievable amount of attachments ;-)

I'm watching this issue very closely. I wouldn't tell you which one I prefer now, but it's name is hidden in this MD5: f509db07c9dec4da53cdfb290647ac9d ;-) It is very decent and I simply like it.

This issue also shows that we as a project have a problem with motivating such people. We are missing gallery themes, nice icon themes etc. But look how many nice images people can generate for splash screen. Because they are motivated. They are motivated to have their name connected with OpenOffice.org' splash screen. Can we motivate them to create e.g. icon theme or gallery?

Artists: please tell us how can we motivate you. -----

I updated my blog engine to latest CVS nanoblogger, which is very fast. Should you see any error, please told me :-)

Why I use nanoblogger? It is completely written is shell, uses classic unix tools like awk, cut, sed etc., works without database, works without PHP and without Java. It is simple, (now) fast and intuitive. You should try it too ;-) -----

After several days of "inactivity" I again digged into l10n@OOo.

Ivo H. fixed #i37043 (xmlex have to unquote the exported strings) so new POT files were generated (I will post them updated to SRC680_m62) and PO files were updated. So right now, we have the only one issue with PO/POT files - new lines are quote by two backslashes instead of one. David is working on it.

I reported several issues today:

• #i37097# - many old readme on sources is also in 2.0 - 692K of useless data in the source code.
• #i37102# - crashrep: is not localized in 2.0, but crashreporter is (according to ause) to be replaced for 2.0
• #i37105# - scp2/inc/macros.inc contains macros that could be generated from the list of all languages. Right now localizers have to add lines for their languages.
• #i37108# - while working on #i35263#, i found out that desktop's d.lst creates directories named according to old, obsolete phone codes.

I also updated Czech PO files and created nice visual statistics of the translation process of Czech team. -----

Milestone SRC680_m61 is now ready for your work! Announced by Hamburg RE with many child workspaces integrated (sb22, accessbugs01, desktintgr03, hroqfix01, dr28, sal08, ipv6ooo2, iha03, iculecrash, jmf3, pj10, aw019, ivo05, sab012, smoketest2, qadev19 and hr8).

If you are building on Windows, you probably need vq04 and also pythonupgrade (you do not need ConvertDSW then).

On all systems you need hr9 because otherwise your temporary space can get filled by HelpLinker ;-) -----

I have finished the first build of Windows native installer from my build system. This was somewhat un-ideal build with a lot of manual interventions, but I will start another one in a few moments.

The following image is a screenshot of the first installer screen:



Hope to get the process stabilized soon enough. -----

Yesterday, I wrote about generating PO files from PO Template files (POT files). And as I promised, this entry will show next step needed to create GSI/SDF file for OpenOffice.org.

You have all (or some of them) PO files translated in the same structure as it was generated, in the directory PO. To do the conversion process, you need the po2oo command from translate package. The current version is 0.8 rc1.

To install it, you can use this sequence of commands (you must have Python's distutils installed - e.g. from python-devel RPM package on SUSE Linux):

tar xfz translate-0.8rc1.tar.gz cd translate-0.8rc1 ./setup.py install --home=/tmp/SOMEWHERE

After the installation, you have to specify the path to the Python files using the following command:

export PYTHONPATH=/tmp/SOMEWHERE/lib/python

If you have root privileges or your private Python library, you probably know much better what to do ;-) Now you can test po2oo command:

oo@oo:~/> /tmp/SOMEWHERE/bin/po2oo usage: po2oo [--version] [-h|--help] [--progress PROGRESS] \ [-i|--input] INPUT [-x|--exclude EXCLUDE] [-o|--output] OUTPUT \ [-t|--template TEMPLATE] [--psyco PSYCO] po2oo: error: You need to give an inputfile or use - for stdin; \ use --help for full usage instructions

Now you have everything ready to transform your PO files to GSI/SDF file using the following command:

/tmp/SOMEWHERE/bin/po2oo -l cs -t cs.sdf PO GSI_cs.sdf

cs is the ISO code for your language (cs if for my language, Czech), cs.sdf is one of the GSI/SDF files used for generating POT files (see GSI directory on my FTP server from where you got POT files), PO is the name of the directory with PO files and GSI_cs.sdf is the final, long awaited GSI/SDF file that you can use with localize tool with -m (merge) argument.

Please let me know if this description is enough or what should I describe more properly. Thanks! -----

For translating OpenOffice.org we are generating POT files. See POT files from milestones (FIXME: this will be mirrored to *.openoffice.org/...).

How to get PO files from them? Some people prefer to use kbabel or other tools. But I simply do not believe them ;-)

I have prepared script that can be used to generate PO files from the above mentioned POT files. So let's start with it:

#!/bin/bash # # This script can be used to generate PO files from OpenOffice.org POT # files. # # Compendium generated from old PO files COMPENDIUM=~/.translations/COMPENDIUM.po # If you do not have compendium or you want to start from scratch ;-) # COMPENDIUM=/dev/null rm -rf PO for POT in `find POT -type f` do PO=`echo $POT|sed 's#POT#PO#'|sed 's#.pot#.po#'` echo $PO # Create directory for new PO file mkdir -p `dirname $PO` msginit --no-translator -i $POT -o $PO msgmerge --backup=off -w 200 -U --compendium=$COMPENDIUM $PO $POT done

It is pretty simple. It expects POT files unpacked in the POT directory and will remove and create PO directory with clean PO files from them. If you already have a database of translated strings in the form of PO file, you can define COMPENDIUM variable to point to it. If you define it, PO files will be initiated with already existing translations.

The next entry (it will be written tomorrow, for sure!) will be about generating GSI/SDF file from translated PO files. So stay tuned, because OpenOffice.org project can accept submissions of translations in the GSI/SDF format only (which you must use for your localized builds anyway). -----

Typical rainy day here in Rudná/Prague...

I updated my Emacs version to the current CVS, read the news entries (and proposed several changes to authors of newly added packages), updated Gnus to the current CVS, installed new SUSE Linux 9.2 to QEMU (current CVS) to test how it works.

My builds of not-yet-ready OpenOffice.org milestone m61 (with several fixes ready for planned pj11) were finished on GNU/Linux and also Solaris/SPARC. Windows machine is still building (in sw module now, getting low on free disc space though ;-). -----

My builds of SRC680_m60 are uploaded to ftp.linux.cz. Build on Solaris/SPARC is still running. We can't yet package Windows builds (but we are working on it!).

Update: Solaris/SPARC build is now finished and uploaded too.

You can also download GSI files extracted from the sources, POT files and also PO files reflecting the current status of translations for respective languages.

Next items on my TODO are: finish Windows builds, try merging GSI files back to the source, describe the whole l10n process ;-) -----

Hamburg RE team is very productive. They produced next milestone on the developer branch - SRC680_m60, which integrates the following child workspaces: dbwizard1, configure2, impress20ea, dclocking, os39, pdf02, writerperfect01, valgrind02, dzongkha, os36, gccvisibilityfix, rodarvus01 and withlang.

The last child workspace mentioned (withlang) brings builder visible change to the configure. Starting from m60, you can specify the language you want to support in the following form:

--with-lang=LANGUAGES

where LANGUAGES can be in one of the following forms:

• ALL - if you want to build all languages supported in the source code (have a look at solenv/inc/postset.mk)
• "en-US cs" - to build only English (US) and Czech version
• "ALL xy" - if you want to build all languages and also want to build language xy which is not supported in the source.

You do not have to specify en-US, because this is automatically added by build system. English (US) is also always build as the first language because it is supposed to build out of the box.

Update: do not forget to checkout new modules libwpd and writerperfect. -----

Vladimir Glazounov from Sun announced next milestone on the stable branch, SRX645_m52. Integrated child workspaces: pj09 and mh114.

My builds for GNU/Linux and Solaris/SPARC are available at ftp.linux.cz. Windows build will be started soon. -----