Launchpad itself

Please unblacklist ubiquity and oem-config debconf translations

Asked by Colin Watson

For a long time, we've aggregated all installer translations into a single special template, namely debian-installer/+pots/debian-installer, matching the way installer translations are handled upstream. We've included in this master template two additional packages that aren't part of the upstream suite, and aren't likely to be - namely oem-config and ubiquity. As such, oem-config/debian/po/templates.pot and ubiquity/debian/po/templates.pot are, I believe, currently blacklisted so that they don't show up in Launchpad.

While there were good reasons at the time for doing it this way, this has worked out to be a bit confusing. The aggregated debian-installer template is fine in itself, but translators are typically quite confused about the way that oem-config and ubiquity - especially ubiquity, an important package for translations of Ubuntu - are included in it. The installer team would like to stop including oem-config and ubiquity in the master templates file (which I can take care of), and simply handle them as ordinary separate templates.

Could you please undo whatever blacklisting is applied to oem-config/debian/po/templates.pot and ubiquity/debian/po/templates.pot? I trust that message sharing means that translations that haven't been applied to the package will automatically be carried over from debian-installer/+pots/debian-installer, but if not, let me know what we need to do.

Question information

Language:
English Edit question
Status:
Answered
For:
Launchpad itself Edit question
Assignee:
Данило Шеган Edit question
Last query:
Last reply:
Revision history for this message
Данило Шеган (danilo) said : 		#1

I believe we are fully blacklisting anything in debian/po paths to reduce number of blocked entries we had to re-add with every Ubuntu release (I believe we discussed this with pitti: we are talking about thousands of PO files that would otherwise clobber import queue). Is there any way to move them to another path in the generated tarball?

Revision history for this message
Colin Watson (cjwatson) said : 		#2

Painful - the build system is complicated enough as it is and the build-time debconf utilities assume debian/po. Is there no way to unblacklist specific things? I don't mind waiting for an LP release cycle.

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

It's painful for us as well: we try very hard to not hard code exceptions like these in our code, especially since we do a lot of test-driven development, where you've got several pieces to maintain with any exception (a unit test, code and documentation, and sometimes an acceptance test as well). This won't help our goal to get auto-approver for Ubuntu into much better shape either.

Of course, we can still do it, so if you insist, please file a bug with these details and I'll try to schedule it asap.

Note that message sharing works across "same" templates, and such newly created ones would not be considered as "equivalent" in Launchpad (they are in one equivalence class if they have the same sourcepackage name and potemplate name): you'd likely have to manually prepare translated PO files and upload those instead.

Revision history for this message
Colin Watson (cjwatson) said : 		#4

Would a symlink in the source package (po -> debian/po) take care of the problem? That would be low-maintenance for us, and if it works for you it would be acceptable.

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

It should, we are just ignoring files with a path starting with debian/po, nothing else.

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

To clarify, even using something like debian/ubuntu/po should work.

Can you help with this problem?

Provide an answer of your own, or ask Colin Watson for more information if necessary.

To post a message you must log in.