launchpad developmentThe purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess.
Automatic upstream translations import into Ubuntu
Translations in Launchpad upstream projects should be automatically used in Ubuntu whenever possible.
On Launchpad: import-upstream-translations-into-ubuntu
As an Ubuntu developer/translator,
I want to see up-to-date upstream translations in Launchpad,
so that it's easy to make use of them through global suggestions when translating Ubuntu.
Since we want to have all upstream projects' translations imported into Launchpad anyway, we are focusing on only how we share translations between upstreams in Launchpad (both hosted and imported) and Ubuntu.
Rationale
This is a critical step towards bridging the gap between upstream and Ubuntu translations: once upstream translations are in Launchpad, we need to get them into Ubuntu as well.
What do we get with this?
Better Ubuntu translations: they get imported from upstream very soon after they are done (<3 days)
- Less work for Ubuntu translators: they can focus on Ubuntu-specific strings
- Happier upstream translators: their translations get to Ubuntu users (at all, and faster)
- Less duplicate work: because of a smaller time difference since last import from upstream (currently it's based on packaged translations in upstream tarballs), it's less likely to get duplicate same translations happening both upstream and in Ubuntu
What is this basis for?
- Sending changes from Ubuntu upstream in a form useable by upstreams.
- Knowing what are Ubuntu specific strings so we can speed up translation of Ubuntu-specifics and report status on it.
Stakeholders
Ubuntu Translators Community
Canonical OEM
Ubuntu upstreams
GNOME, KDE, Debian, OpenOffice.org, Firefox, FreeDesktop, GNU
Constraints
What MUST the new behaviour provide?
What MUST it not do?
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
Workflows
What are the workflows for this feature? Provide mockups for each workflow.
You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.
Success
How will we know when we are done?
How will we measure how well we have done?
Release Note
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. It is mandatory.
Thoughts?
Put everything else here. Better out than in.
