Import queue problems en mass

Asked by Christian Funder Sommerlund

Hey guys.

Lübbe Onken (https://launchpad.net/~luebbe) and me are trying to get started with Launchpad Translations for TortoiseSVN (https://translations.launchpad.net/tortoisesvn), but unfortunately, we are having quite some trouble.

1) For some reason all our .po imports fail without any reason given (see https://translations.launchpad.net/tortoisesvn/+imports). How come they fail? (Yet the languages are still created (empty though) for the project (see https://translations.launchpad.net/tortoisesvn/trunk/+pots/tortoise))

2) When trying to clean up the list by selected "Deleted" for any of the entries and clicking "Change status", LP tells me that "There are 2 errors." - again without any kind of indication or explanation of what kind of errors. Refreshing the page reveals that no changes have been made. What are these errors?

3) Out current .po filenames follow the syntax "Tortoise_<language code>.po". Is this OK for LP? I also tried uploading a "<language code>.po" instead, but while both failed, that one, unlike our current syntax, does not even get a "Will be imported into..." tag in the import queue.

Any help? :)

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Christian Funder Sommerlund
Solved:
Last query:
Last reply:
Revision history for this message
Jeroen T. Vermeulen (jtv) said :
#1

Oops. Several things going on here:

1) I see some of the failures in the log... It turns out to be an error that is not being caught and sent to you like it should. This is what I see:

Original text (u'Revision: %ld\nURL: %s\r\nAuthor: %s\r\nDate: %s\r\n\r\nLogmessage:\r\n%s') mixes different newline markers

So looks like a header was edited partly on a Windows system and partly on a non-Windows system, and then copied to a lot of translations, with mixed line ending codes. That should be either accepted (if that is safe) or reported in an email, or possibly both. I've filed the failure to email this as bug 239452.

2) That's a UI bug that I thought generally wasn't bothering non-admin users... :-( It's filed as bug 139176. Try this workaround: make it so that you only see those entries that you want to delete on the current queue page. If that's not possible by clicking, try adding a parameters like batch=3 (to see only 3 entries per page) and start=4 (to view the batch starting at entry #4) to the URL.

3) It's actually better to use just <language code>.po: nl.po, de.po, en_GB.po, pt.po, pt_BR.po, zh_CN.po, zh_TW.po, nb.po, nn.po, and so on. The template can be called <anything>.pot. That way the system can easily recognize what language you're uploading for, and no human operator needs to look at that before the import can proceed. So that could save yourselves and us a lot of time.

Revision history for this message
Christian Funder Sommerlund (zero3) said :
#2

1) It should be safe (for us at least). I'll report back to the devs nevertheless to see if we can change that line to only use a single type of newline marker. What about outputting those errors at the import queue as well? Would make sense in a multi-dev environment to attach the error message there as well...

The drop-down-box-action-thing is not really very informative by the way. It took me a while and a bunch og googling before i figured out what you are supposed to do with them. Perhaps split the current drop-down-box into 2 columns: One with the current status as text ("Pending review"/"Approved"/"Failed" (with error message either next to, or as hover-text perhaps)/...) and one with action to be done as a drop-down-box ("<blank>"/"Delete"/"Request review"/...). But I guess that is a whole other are? :)

2) I tried adding &batch=3 and marked the 3 as deleted, but simply got the same error message (now "There are 32 errors." though (there are 35 items in total, so I guess that would be the other 32 not shown?)). It can wait until the bug is fixed though (I've subscribed).

3) Roger that.

Revision history for this message
Christian Funder Sommerlund (zero3) said :
#3

1) Correcting the newline inconsistencies fixed the problem! Thanks.

4) (Not sure if I should start a new question, but since they are related, I figured I'd just add to this one)

The "English (United Kingdom)" language was added automatically, even though no .po was imported for that language. How can we remove it?

Revision history for this message
Jeroen T. Vermeulen (jtv) said :
#4

For 2), I'm bumping bug 139176 to a higher priority.

For 4), there's no way to remove it, but is there really a need? Generally the system only shows you translations for languages you're interested in, and if those translations don't exist yet, it will pretend that they do (but are empty). So if you have UK English in your list of preferred languages, you will see a UK English translation in the list even if one was never created.

Revision history for this message
Christian Funder Sommerlund (zero3) said :
#5

4) Ah, I see. It doesn't get exported either, so thats fine - no worries. Wasn't that easy to figure out, as UK English also appears on "View Template & All Languages... "

Thanks for the promt replies. I have a few more minor things as well:

5) Some strings are "word-wrapped" in an odd way. Example:

msgid "All your changes will be lost! Do you really want to reset all toolbars and menus?"
msgstr "Alle dine ændringer vil gå tabt! Er du sikker på at du vil nulstille alle værktøjslinjer og menuer?"

imported and then exported becomes:

msgid ""
"All your changes will be lost! Do you really want to reset all toolbars and "
"menus?"
msgstr ""
"Alle dine ændringer vil gå tabt! Er du sikker på at du vil nulstille alle "
"værktøjslinjer og menuer?"

Any particular reason for the empty-quoted msgid and msgstr?

6) Just wondering: The added "X-Generator: Launchpad (build Unknown)\n" is missing a build number/version/identifier? Not much information gained by "build Unknown"? :)

7) TortoiseSVN is taking advantage of automatically compiled nightly builds and language packs. While the export request seems fairly simple to trigger via wget/cURL, fetching the link from the mail seems unnecessarily complicated. Is there an easier way to automatically fetch the latest export? E.g. is it saved at a static location somewhere, so we can simply trigger the export an hour or two before the nightly build, and then fetch the export from a static URL?

Revision history for this message
Jeroen T. Vermeulen (jtv) said :
#6

5) is just convention. It's easier to read than having the msgid and msgstr identifiers on the same line as the text.

6) is from the time when we didn't number our versions. I don't think it'll matter much though.

7) is not possible at the moment, sorry! We're still considering the options.

Revision history for this message
Christian Funder Sommerlund (zero3) said :
#7

5) Fair enough, a matter of preference I guess :).

6) Roger.

7) Looking forward to that. That would definitely make things a lot easier.

Thanks a lot for your assistance.