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.

Some pickups from NLC meeting in Barcelona

I've reminded later that Basque team lead told that he has to overread every incoming file from translators from beginning till the end (if I understood right). I've tried to keep it simpler - when I've got the file, I'm doing following:

• remerge it to latest pot-set just to be sure
• take a look at statistics to find fuzzy and untranslated strings and fix them if I can
• commit to CVS repository
• read commit log to see what is changed
• fix the errors when needed
• commit again when needed

When I've got file from trusted people (hm, I trust generally all people, but lets say ... trusted quality) I'll skip the last 3 steps or I'll write it in my ToDo. It's easy to do because diffs of po-files are easy readable.