Windows 7

Past week I decided to try Windows 7 RC which is free to use in one year period.

To keep it short - not bad. Faster than XP on the same computer, all drivers work, all needed applications too. Only my GenoPro2007 compatibility options needed some tuning (Disable visual themes, Disable desktop composition) but GenoPro is a piece of software with really bad quality anyways, unfortunately there isn't anything better.

OpenOffice.org 3.0.1 installation was successful, I used it 2-3 days until I got 3.1.0 installer. Upgrading was not so good any more. After removing old version installer said that it is impossible to write into OpenOffice.org3/program directory. I had to stop installation, remove manually OpenOffice.org3 directory and then resume installation. This time I had success.

Windows native open/save dialogs in OpenOffice.org look freaky and behave so too. No autocompletition, no suggested file names. This means, I have used that when I export myfile.odt to pdf, dialog suggests file name myfile.pdf. In this dialog does it not. When I open file file14.ods, save it as file15.ods and then export it to pdf, suggestion line was empty. I chose previous export, file14.pdf and changed 14 to 15. It was clarly written on the file name line file15. When I hit Enter, dialog told me that file14.pdf already exists... so had to write all the filename letter by letter to save it with name file15.pdf.

Following pictures illustrate:

- Windows native dialog in Windows 7 / OpenOffice.org

- Next picture is thes same native Windows 7 file open dialog opened from Notepad2 (very old but my favourite simple text redactor under Windows):

Makes a bit difference?

And Windows Wordpad now supports odt file format (you know, this strange piece of software that comes with Windows and which no one uses). Somehow. Strange ways the formatting artefacts were almost the same as in KWord... mostly some offsets and distortions of paragraph borders and paragraph background colors.

Btw, these screenshots are made with Windows native tool, called "Snipping Tool".

And the most important - when you copy a large amount of files with Windows Explorer and there occurs an error, you can now skip problematic file and proceed instead on starting again... Unbelievable that it took so many years to implement this.

Attention to community translators!

(Edited 18.02) Today Pavel will generate new set of pot-files using translate-tools 1.1.0. This means that traslation teams, providing localized sdf-files for his build system should perform some additional moves.

1. Generate sdf-file from existsing translations (when you are not doing it everyday) using OLD TOOLKIT.
2. Backup all you have (when you keep your files in cvs it's not mandatory, you can easily rollback when something goes wrong).
3. Download and install the new toolkit from http://translate.sourceforge.net/wiki/toolkit/installation (as there were some issues with released 1.1.0, better download 1.1.1rcX from 18.02 or later)
4. You need additionally python-lxml package to work with new toolkit, setup doesnt give any messages about it but you cannot generate sdf-files when python-lxml is missing.
5. Regenerate your translation po-files (this is my command line, use your own paths and language codes) - attention - this will change duplicate styles from kde style to msgctxt:

   oo2po -l et /home/ain/ooocvs/et/GSI_et.sdf /home/ain/ooocvs/et/po/ (you can get a warning about 'targetlanguage not found...', this means that you have a file with indicated name completely untranslated, when you agree, it's OK)

6. Download new pot-files from Pavel's ftp site (with date 15.02.2008 or later).
7. Merge translations with new pot files (pot2po).
8. Regenerate new sdf-file with (this is my command line, use your own paths and language codes):

   po2oo -l et -t /home/ain/ooocvs/et/en-US.sdf /home/ain/ooocvs/et/po/ GSI_et.sdf

9. Run gsicheck. (Fixed in 1.1.1rc1 - You may encounter some errors which are caused by bogus whitespaces inside tags (was not problem before, because no tool had any idea that these double-escaped things are tags), for example by backconversion to sdf a tag "<ahelp >" is not recognized (space before closing angle), also tag"<ahelp hid..." (two adjacent spaces). These problems are created by translators using GUI tools because earlier gettext tools didn't know that this double escaped thing was a tag and put linebreak often inside of a tag, and it is very easy with gui tool put additional whitespace in end of such line (translator will not see line ending quotes). This problem should go with new toolkit.) When there are no errors go to 11.
10. Fix the errors and go back to 9.
11. Seems like you did it.

Attention: all these new pot files are generated only for OO.o 3.0 development tree. When you still want to provide translations for 2.4 tree (for your own use for example - or when you are distributing community builds), you should either have 2 versions of toolkits installed (eg. one in userspace, one systemwide) or you should convert 2.4 translations to new format too. Pavel told, he will not provide new pot files for 2.4 tree, as there should be no changes in this area any more.

broken readlicense in m234

As readlicense module's translatable content is a bit broken, Pavel removed m234 pot-tarball from his directory. It was not usable anyways, due po2oo and gsicheck errors. See issue 82771

Happy Birthday, OO.o!

After I've read about 7th birthday of OO.o, I started to dig mailing list archives to find out how old is Estonian translation of OO.o. Looks like we started translation project in 6th October 2001 (mailing list was created and started work with localedata). So we had a quiet 6th birthday without precious presents about one week ago. Using archives, I wrote a short localization chronology, unfortunately in Estonian... :)

new strings in m233

New module was introduced, sdext. The path to translatable files is at least 3 inches longer than in any existing module: sdext/source/minimizer/registry/data/org/openoffice/Office. There is something more too long, because GSICHECK gives an error checking this module:

• Error: Line format, Line 32589, UniqueID
  sdext/source\minimizer\registry\data\org\openoffice\Office\Addons.xcu/value/.Addons.AddonUI.OfficeMenuBarMerging.org.openoffice.Office.SunPresentationMinimizer.org.openoffice.Office.SunPresentationMinimizerCommand1.MenuItems.org.openoffice.Office.SunPresentationMinimizerExecute2/Title//:
  GID and LID may only be 125 chars long each!  "en-US"

• Error: Line format, Line 32591, UniqueID
  sdext/source\minimizer\registry\data\org\openoffice\Office\Addons.xcu/value/.Addons.AddonUI.OfficeMenuBarMerging.org.openoffice.Office.SunPresentationMinimizer.org.openoffice.Office.SunPresentationMinimizerCommand2.MenuItems.org.openoffice.Office.SunPresentationMinimizerAbout1/Title//:
  GID and LID may only be 125 chars long each!  "en-US"

Filed as http://www.openoffice.org/issues/show_bug.cgi?id=82571

My opinion about different options when translating OO.o

... is following:

• Some people translate sdf-files with spreadsheet applications... brr..
• Translation framework held up by Pavel Janik: it was the way to involve existing freeware translators to OO.o translation. It was very important to use their TM databases at starting point for many languages. As it is easy to use and quite flexible it is at moment a very good way for communities sharing translators with other teams.
• Pootle - it is the best way to involve EVERYONE. Some teams don't want everyone. Me too. OO.o is a production level application already long time, there are printed books about OO.o in many languages, we should think twice before changing something in user interface. It needs strong administration etc. Anyways, it is a very good option too in many cases and the best feature is that Pootle can be used together with previous option.
• Something for professional translators. I don't maybe fully understand what all this XLIFF etc. means, but I can understand that this may be important for so-said Sun-languages. I've never met any professional translator of my language personally, I've only seen some MSW and MSO translations and these make me sick (not only me, users too - these translations are subject of common fleering in our country). It is still for me unclear, how version control systems can handle XLIFF-format, as OLT output is packed to xlz-files and how readable is the changes output. Anyways, for my team this option is meaningless, as we don't have currently any people working with other formats except gettext one.

It's just my thoughts, I don't want to agitate someone. Maybe just we have to think not only 'what will be in future' but also 'what we have already'. And how to make it better.

Checking translations

We are checking all changes in string translations in very easy way: our Estoanian team linguist (Marek Laane, JCA) is subscribed to et-cvs@openoffice.org mailing lists. When a commit is made he just writes his comments to the same list. We are using the same system in all projects, for projects without needed infrastructure (Firefox, Thunderbird) we use Google Groups with or without RSS feature for redirecting version-control-system commit messages, for projects with common mailing list for all changes (like openSUSE) I first automatically filter out et/po messages using my GMail account which deletes all other languages commits and redirects et/po commits to Google group. It's very easy to do because diffs of po-files are easy readable.