File names of exported PO files are non-standard.

Bug #353981 reported by Henning Eggers on 2009-04-02
10
Affects Status Importance Assigned to Milestone
Launchpad itself
Medium
Unassigned

Bug Description

The downloaded tar.gz has all of the files suffixed with the translation domain. For example for Italian, rather than it.po, it is named domain-it.po. This makes it very difficult to just download the translations directly into the po/ directory for my project. I would really like to be able to just download the translations and import them directly into my project.

Henning Eggers (henninge) wrote :

The reason for the current behaviour is that we cannot be sure that PO files for different templates end up in the same directory. So we prepend the template name (or is it translation domain?) to the file names not prevent the tar archive from breaking because of duplicate file names.

Christian Reis (kiko) wrote :

So from the thread I read on -users that referred to this bug, ISTM that the main issue this causes is that you can't use the tarball to reimport. Is that true? And if so, could we just make it so the importer was able to detect and process tarballs that have this filename/structure?

The main issue (at least for me) is that there is that you can't just drop
this into the po/ directory of a project that doesn't have overlapping
files. It's time consuming to have to rename all of the files whenever you
import translations.

On Thu, Apr 2, 2009 at 13:15, Christian Reis <email address hidden> wrote:

> So from the thread I read on -users that referred to this bug, ISTM that
> the main issue this causes is that you can't use the tarball to
> reimport. Is that true? And if so, could we just make it so the importer
> was able to detect and process tarballs that have this
> filename/structure?
>
> --
> File names of exported PO files are non-standard.
> https://bugs.launchpad.net/bugs/353981
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mario Limonciello
<email address hidden>

Matthew East (mdke) wrote :

I often encounter this bug when downloading translations for gnome-user-docs and ubuntu-docs packages in Ubuntu - it's a pain. We have adopted a script [1] to workaround it, but it would be more convenient if the naming of the po files followed the naming convention used by the package when uploaded.

[1] http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-karmic/annotate/head%3A/scripts/hack.sh

Henning Eggers (henninge) wrote :

I am also all for fixing the export. Two possible approaches would be:

1. Check first if there is a directory conflict between the templates involved in the export. If not, export all po files into the template's directory. If there is a conflict, create a subdirectory for each template and export into that instead of prepending to the file name.

2. Always use the subdirectory-per-template layout.

The goal is to give the user a set of PO files that need not be renamed. Also to create a layout that can be re-imported directly.

FWIW, I know of at least one user that had no problem with the current situation because he knew enough shell foo to do the renaming in one command. But I still think most users are confused by the current layout of the tarball.

We should also keep in mind that problems Matthew East is running into is lack of support for gnome-doc-utils packages which use a slightly different layout: domain/lang/lang.po : it'd be nice to recognize this layout and support it as well.

Matthew East (mdke) wrote :

Danilo - I think that is a separate bug and have reported it as such - bug 354372

I am not sure these two are separate bugs. For instance, we should include translation domain inside PO file names only if the original uploaded files did. I.e. by solving bug #354372, we'd solve this bug as well. Of course, just solving this one won't solve the other one, so they are not strictly duplicates, but #354372 is a superset in my understanding.

Changed in rosetta:
importance: Undecided → Medium
status: New → Triaged
Henning Eggers (henninge) wrote :

This is a duplicate because it has the same root problem.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions