Launchpad itself

How to remove a translation?

Asked by David Paleino

Hello,

I'm trying to remove some unmaintained translations from wicd.

wicd is currently using LP also for translations, and it is setup so that it imports/exports .po files from the bzr repo. However, even "bzr rm" didn't work, since LP re-added the files on the next sync.

  http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/revision/773

Is there a way to completely remove some languages?

(in this particular case, they're unmaintained language variants, say en_CA or es_MX, which are largely incomplete, so that a Mexican user prefers having "es", instead of a few strings in "Mexican Spanish" and the rest in English)

Thank you,
David

Question information

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

There's no way to remove unmaintained translations, really. Generally speaking, anyone can come in and help out, so it should be better to fix the lack of maintenance. we don't really have a line we can draw for “this is sufficiently translated to ship.” Some might say a bit of translation is almost always better than none at all. We set no bar that translators must reach in order for their efforts to have any effect at all.

A workaround is to clear those translations, or set them to copies of the “proper” language (e.g. by browsing them with the “proper” language as a guide, and selecting the translations that are suggested from that language) The project owners may want to assign the translations to a translation group, and ask their translators to join or work with that group.

Revision history for this message
David Paleino (dpaleino) said : 		#2

This reasoning works well for "main" languages. However, for language variants (think at es_MX, es_AG, es_CL, ... being the main language es), "a bit of translation" is not useful. It's better to ship the "main" language translation (es in this case).

Surely I can put a threshold in my project's buildsystem.

Anyhow, please remove the following languages from wicd:

po/en_CA.po
po/en_GB.po
po/es_AR.po
po/es_CL.po
po/es_CO.po
po/es_GT.po
po/es_MX.po
po/es_NI.po
po/es_VE.po
po/fr_CA.po

Thanks,
David

Revision history for this message
Laura Czajkowski (czajkowski) said : 		#3

Hi, as I said above it's not possible, but you could be better off keeping a list of "maintained" translations in his build procedure, and just not shipping translations that aren't on that list. Or shipping them in a separate directory as optional extras. You could also consider exporting to a separate branch, rather than straight back to his development branch, so that there's an extra step in accepting them back that you have control over.

If you create a separate branch _based on your development branch_ that you can export translations to, then you can use “bzr merge” etc. to manage the PO files. It does mean that there's an extra step to be performed in getting translations back in, but that's the price of wanting to customize that flow: You have to implement your own version of the flow. (Note that you can only _import_ from the series' main branch, but you can _export_ to a branch of your choosing)

Revision history for this message
David Paleino (dpaleino) said : 		#4

Sorry, this question is not answered yet. I _hate_ to play ping-pong, so I won't reopen it a third time.

I see there are similar "please delete translation X" filed along this one, which are completed just fine. Why this one can't be acted upon?

I surely will make a check in my buildsystem though.

Thank you for your help so far,
David

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

Deleting translations is technically possible, of course, but not very practical. We do it occasionally but it takes a lot of time and work. We haven't invested in making it more practical because “deleting a translation” can mean lots of different things technically, and for a variety of use cases. In some of those use cases, deleting translations sounds like a solution but is actually wrong, or just a temporary way to hide another problem.

In the case of wicd, there's not much point talking about deletion if its translations operate under the Structured permissions model. With those permissions, anyone can add translations for languages that are not managed by the translation group. It just takes one drive-by contribution to bring an unwanted language back! We try to discourage language variants that we think unnecessary, but we don't go as far as to block them completely.

And that does create a problem for you. If your translations go straight into your branch, and from there straight into your build and from there, straight into release then the good and bad effects of whatever level of openness you choose for your translations will show up in your release. To control the bad effects without obstructing contribution, the best thing to do is to filter out any translations that aren't good enough near the rear end of the process — basically the build stage.

The translations-to-branch exports are an earlier stage of the process: they were designed to store your translations as part of the development process, not to make the final call on which translations you consider usable for a release. It might be nice if Launchpad could automate that step, but as things stand, it doesn't. It's not as easy as it sounds: Launchpad doesn't know if maybe you or some of your translators prefer to commit translations through the branch, for instance, and we think adding even more buttons and switches to control those things is detrimental to the effectiveness of the Launchpad application. The application doesn't know if you like to release your translations as part of the same package or separately, or as part of larger language packs. Nor does it know whether your translators prioritize strings effectively, which can make an enormous difference to how much coverage you need for a useful translation — but you can't just set a custom percentage because practice will differ between languages. We could make Launchpad find some of these things out, but complexity also has a way of making your life harder.

So how do we make things better? I can think of one thing. Perhaps the Launchpad Translation Group should have empty translation teams for languages it thinks are redundant, such as national variants of Spanish. That way, people will still be able to suggest translations for those languages but not actually approve them in any project the group manages. I'll start a discussion about that; if they agree, then we're in a position where deleting translations in some way makes sense as a one-time cleanup.

Revision history for this message
David Paleino (dpaleino) said : 		#6

Thank you very much Jeroen. :)

Revision history for this message
David Paleino (dpaleino) said : 		#7

Thanks Jeroen T. Vermeulen, that solved my question.