Import stuck in queue for 2 days

Asked by fisharebest

The documentation says to contact you if importing takes longer than expected. This is my first import, so I don't know what to expect, but my import (project = webtrees) has been waiting for two days, and doesn't appear to be moving up the queue.

If the problem is my filenames, can someone confirm whether es_419 (latin american spanish) and sr_Latn (serbian in latin script) are valid?

I renamed them to es_AR and sr for this import (trying to keep things simple!), but would prefer to keep the original names, if allowed.

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
David Planella
Solved:
Last query:
Last reply:
Revision history for this message
Best David Planella (dpm) said :
#1

Hi fisharebest,

El Fr 26 de 03 de 2010 a les 07:26 +0000, en/na fisharebest va escriure:
> New question #105578 on Launchpad Translations:
> https://answers.edge.launchpad.net/rosetta/+question/105578
>
> The documentation says to contact you if importing takes longer than expected. This is my first import, so I don't know what to expect, but my import (project = webtrees) has been waiting for two days, and doesn't appear to be moving up the queue.
>
> If the problem is my filenames, can someone confirm whether es_419 (latin american spanish) and sr_Latn (serbian in latin script) are valid?
>
> I renamed them to es_AR and sr for this import (trying to keep things simple!), but would prefer to keep the original names, if allowed.
>

I'm not a Launchpad developer and I don't usually look at the imports
queue other than for the Ubuntu project, but I thought you might find
this feedback useful.

Regarding the time it takes to import manually uploaded translations,
I'd recommend using bzr imports [1] instead to speed up the imports and
further automate the translations process.

Regarding the names of translation files, I'd recommend to stick to the
standard (throughout GNU projects, not only in Launchpad) PO file naming
conventions, which are ll.po or ll_CC.po. ll denotes a two or three
letter ISO 639 code and if necessary CC denotes a country or region
code.

As for the particular files you are mentioning:

      * es_419: the '419' should be best removed or changed to a two
        letter country code, such as es_ES. In any case though, I'd
        recommend using the standard Spanish language 'es' for all
        Spanish translations, rather than fragmenting the translations
        community by using translations for every dialect (unless
        explicitly necessary).
      * sr_Latn: that's a bit of an exception. Latin is an alternative
        script for Serbian, which can be written in Cyrillic. In this
        case, the alternative script defines a variant, which is denoted
        by a @ modifier. There are not many @ locales comparing it to
        the whole list of other ones, but that's one of them, and the
        file should be named as <email address hidden>. If you are interested in
        the background on the naming scheme, I'd recommend you to read
        [2].

Note that it might take a bit for the LP devs to reply, since they are
away in a coding sprint.

I hope this helps.

Regards,
David.

[1] http://blog.launchpad.net/translations/import-translations-from-bazaar-branches
[2] http://www.openi18n.org/docs/text/LocNameGuide-V10.txt

--
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com

Revision history for this message
Данило Шеган (danilo) said :
#2

I've approved your template: translations will be approved automatically, and all template uploads should be approved automatically in the future (after an hour or so, sometimes faster than that, sometimes slower). After this approval, they get imported pretty quickly. Please also use "<email address hidden>" for Serbian Latin, because Serbian is best used for Cyrillic translation.

Revision history for this message
Данило Шеган (danilo) said :
#3

And, I'd also suggest to use the bzr integration instead: that'd be much smoother.

Revision history for this message
fisharebest (fisharebest) said :
#4

Thanks David Planella, that solved my question.