local check before importing on LP

Asked by Adi Roiban on 2008-07-07

Is there a method for checking local po files before uploading to Launchpad?

I was using "msgfmt -c" for testing the files, but for example the file from the link below, gives no errors but the import process failed with this reason: "
Line 3037: String not terminated"

This is the file:

By checking the files before uploading we can reduce the uploading time and servers load.

Many thanks!

Question information

English Edit question
Launchpad itself Edit question
No assignee Edit question
Solved by:
Jeroen T. Vermeulen
Last query:
Last reply:
Jeroen T. Vermeulen (jtv) said : #1

It may be something to do with the line endings. If there are Windows-style CR/LF line endings, different systems and even different programs can have different ways of interpreting them. It can be hard in those cases to tell what the problem really is.

In cross-platform editing, it can even happen that a CR/LF pair is broken up. We once had a whole batch of uploads fail because they all reused the same header which had this problem.

Adi Roiban (adiroiban) said : #2

I was using only Ubuntu while working with that file. It was exported from LP, modified using "tr" on Ubuntu and uploaded again.

The end of lines are in Unix format.

with msgfmt -c i get no errors.

I'm doing this operation to fix all sedilla characters with comma bellow variant.

This is the content around line 3037.

#. Type: text
#. Description
#: ../cdrom-detect.templates:62
msgid "Scanning ${DIR}..."
msgstr ""
"#-#-#-#-# ro.po (debian-installer) #-#-#-#-#
"Se scanează ${DIR}...
"#-#-#-#-# ro.po (ro) #-#-#-#-#
"Se examinează ${DIR}..."

I think this is a problem with the file exported from LP.
This translation contains 2 suggestions.

The correct export should look something like this one:

#. Type: text
#. Description
#: ../cdrom-detect.templates:62
msgid "Scanning ${DIR}..."
msgstr "Se examinează ${DIR}..."

Maybe this is a bug.

Kind regards,

Jeroen T. Vermeulen (jtv) said : #3

There's definitely a problem with the newlines: there are ^M (carriage return IIRC) characters inside the "#-#-#" strings. The HTML rendering here exposes those as newlines, so the problem is evident.

This could be a bug, but it's actually drawing our attention to bad data in this case: the "#-#-#" warns you that two translation files have been merged, which had two different translations. The file should not be used with that "#-#-#" marker still in it.

Launchpad didn't add the marker; it has different ways of dealing with merge problems. So my best guess is that somebody ran msgmerge on Windows at some point and neglected to check for conflicts. To resolve this one, replace it with the correct export you give, and upload the resulting file.

Adi Roiban (adiroiban) said : #4

That was the failure cause.

I still don't know why this error was not raised by msgfmt -c and how can I test the po file localy before uploading on launchpad.

After uploading the file in Launchpad the new imported strings have a wrong author. Instead of beeing credited for Adi Roiban, they were credited for "Ionut Jula" (la previous last contributor, "Last-Translator: Ionuț Jula <email address hidden>\n").
I think this is also a bug.

Thank you for you response!

Best Jeroen T. Vermeulen (jtv) said : #5

I've also had the experience that msgfmt doesn't complain about it. It may be because of the ancient GNU wisdom: "be liberal in what you accept and strict in what you generate." It could be doing something smart to recognize this case, or not treating the ^M as a newline (which might hurt if the file had been edited on a Mac IIRC).

I've filed bug 246553 about making this clearer.

Adi Roiban (adiroiban) said : #6

Thanks Jeroen T. Vermeulen, that solved my question.