Released on 1 June 2007
Many toolkit tools that only worked with PO files before, can now also work with XLIFF files. pogrep, pocount, pomerge, and pofilter all work with XLIFF, for example.
All XML formats should now be more human readable, and the converters to Qt .ts files should work correctly again.
Fuzzy matching can now be entirely disabled in pot2po with the
--nofuzzymatching parameter. This should make it much faster, although
pot2po is substantially faster than earlier versions, especially if
python-Levenshtein is installed.
The file previously called match/Levenshtein.py was renamed to lshtein.py in order to use the python-Levenshtein package mentioned above. If you follow the basic installation instructions, the old file will not be overwritten, and can cause problems. Ensure that you remove all files starting with Levenshtein.py in the installation path of the translate toolkit, usually something like /usr/lib/python2.4/site-packages/translate/search/. It could be up to three files.
The toolkits output PO format should now resemble Gettext PO files more closely. Long lines are wrapped correctly, messages with long initial lines will start with a ‘msgid “”’ entry. The reason for this change is to ensure that differences in files relate to content change not format change, no matter what tool you use.
To understand the problem more clearly. If a user creates POT files with e.g. oo2po. She then edits them in a PO editor or manipulate them with the Gettext tools. The layout of the file after manipulation was often different from the original produced by the Toolkit. Thus making it hard to tell what where content changes as opposed to layout changes.
The changes will affect you as follows:
They will only impact you when using the Toolkit tools.
You manipulate your files with a tool that follows Gettext PO layout
your experience should now improve as the new PO files will align with your existing files
updates should now only include real content changes not layout changes
You manipulate your files using Toolkit related tools or manual editing
your files will go through a re-layout the first time you use any of the tools
subsequent usage should continue as normal
any manipulation using Gettext tools will leave your files correctly laid out.
Our suggestion is that if you are about to suffer a major reflow that your initial merge contain only reflow and update changes. Do content changes in subsequent steps. Once you have gone through the reflow you should see no layout changes and only content changes.
The toolkit is gradually becoming more aware of the differences between languages. Currently this mostly affects pofilter checks (and therefore also Pootle) where tests involving punctuation and capitalisation will be more aware of the differences between English and some other languages. Provisional customisation for the following languages are in place and we will welcome more work on the language module: Amharic, Arabic, Greek, Persian, French, Armenian, Japanese, Khmer, Vietnamese, all types of Chinese.
The escapes test has been refined with two new tests, newlines and
tabs. This makes identifying the errors easier and makes it easier to
control the results of the tests. You shouldn’t have to change your testing
behaviour in any way.
pomerge now handles fuzzy states:
pomerge -t old -i merge -o new
Messages that are fuzzy in merge will now also be fuzzy in new. Similarly if a fuzzy state is present in old but removed in merge then the message in new will not be fuzzy.
Previously no fuzzy states were changed during a merge.
If you use pofilter with the --mozilla option then
accelerator failures will produce a serious filter error, i.e. the message will
be marked as fuzzy. This has been done because accelerator problems in
your translations have the potential to break Mozilla applications.
We have added the --personality option to allow a user to select output
in either java, or mozilla style (Java property files use escaped
Unicode, while Mozilla uses actual Unicode characters). This functionality was
always available but was not exposed to the user and we always defaulted to the
Mozilla style.
When using po2moz the behaviour is not changed for the user as the programs will ensure that the properties convertor uses Mozilla style.
However, when using po2prop the default style is now
java, thus if you are converting a single .properties file as part of a
Mozilla conversion you will need to add --personality=mozilla to your
conversion. Thus:
po2prop -t moz.properties moz.properties.po my-moz.properties
Would become:
po2prop --personality=mozilla -t moz.properties moz.properties.po my-moz.properties
Note
Output in java style escaped Unicode will still be usable by Mozilla but will be harder to read.
There is some initial support for reading from and writing to compressed files.
Single files compressed with gzip or bzip2 compression is supported, but not
tarballs. Most tools don’t support it, but pocount and the --tm
parameter to pot2po will work with it, for example. Naturally it is slower than
working with uncompressed files. Hopefully more tools can support it in future.