functional partial PO export

[Adi Roiban]

Hi

Can we have a functional partial po export from Rosetta.

In the documentation it is written that we need to manualy add this text in order to use it with gettext tools:
msgid ""
msgstr "Content-type: text/plain; charset=UTF-8\n"

Can this text be automaticaly added?

Many thanks,

[Adi Roiban (adiroiban)]

I think that the full header should be included.

I tried merging just with the minimal header and some of the headers were deleted.

After adding the full headers in the partial export, I tried the merge again, but the result was a big mess.

The strings were not correctly replaced, and were generated many wrong fuzzy messages for messages that were not in the partial export.

I'm using msgmerge (GNU gettext-tools) 0.17

I have also attached an archive containing a partial export, the upstream export and the merged file

[Данило Шеган (danilo)]

We've intentionally didn't include a full header. If we did, people would upload partial PO files and mess up all the translations. We can include the "small" header and try to block such files on import (the idea behind partial PO files was that they'll be easy to read, i.e. review, but integration can be done in many different ways, out of which there's one proposed in the documentation: depending on what you want to do, it may not be the best thing for you).

What exact problems did you encounter with the merged files? Nothing looks bad to me, except that a message or two was marked fuzzy. This can be fixed by adding another option to the msgmerge command, i.e. to use existing translation as the compendium (change the one from docs to include -C upstream translation):
  msgmerge -o merged.launchpad.sr.po -C upstream.sr.po partial-export.sr.po upstream.sr.po

Is there anything else wrong? I understand your point about the header, but after extending documentation, there are many ways to merge this (i.e. even copy-paste should work, but I wanted to provide at least one way to do it automatically from command line if you "approve" all changes from Launchpad), without introducing risks of people messing up translations in Launchpad (i.e. re-uploading a partial file thus losing all the translations).

[Adi Roiban (adiroiban)]

This is the usecase I would like to follow:

1. Request a partial export from LP
2. Review the export, delete/fix wrong translations
3. The remaining strings should replace the coresponding string from the upstream translations

Step 1 is ok.

For step 2, i think that documentation should be modified and instead of just copying the character set information, all headers should be copied.

Step 3 is not a merge, but rather a replace step.

----

When following the documentation I got about 8 fuzzy string... and they were very fuzzy :) ... not very usefull. Doing the merge by hand would result in a better result.

Using the upstream version as compediums result in new translations being marked as obsoleted.

I got a better result using msgcat in this way.:
msgcat -o merged.po --use-first patial.po upstream.po

But then in Vertimus my merged.po will be merged again with the upstream version.
Working with msgmerge always result in stupid fuzzy text.
-----

Maybe you can inlcude the full header containing a X-Launchpad-PartialExport , and deny such imports.

I am looking at a simple method for doing the replace and be able to merge it using Vertimus without generating to much noise.
I will keep messing with gettext tools and try to come up with a good solution.

[Данило Шеган (danilo)]

У пон, 23. 03 2009. у 16:21 +0000, Adi Roiban пише:
>
> Maybe you can inlcude the full header containing a X-Launchpad-
> PartialExport , and deny such imports.
>

That would keep it in the fully merged PO file as well, and we might
reject the file when it comes back from upstream if you forgot to remove
it there (which you most likely would). I think that's worse than what
you have now.

I don't think there's a perfect solution since we are using something
which looks like a PO file and yet it isn't ("partial" PO files are not
really PO files). We might switch to something which doesn't resemble
PO files at all and provide a separate tool to do the merging, but I
don't think that'd be better than what we have now.