launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi all,

As we are starting our discussion on what approach to take for automatic
import of upstream translations into Ubuntu, here's our fresh LEP page:

  https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu

We are going to work only on getting translations out of LP hosted
projects into Ubuntu, simply because we are in the process of getting
all Ubuntu upstreams imported into Launchpad as LP projects anyway.

With message sharing, we have some basis for what we are trying to
achieve: approach similar (or even identical) to that would give
instantaneous sharing of translations two-way (from upstream to Ubuntu
and the other way around).  However, extending it to another dimension
is going to make entire Launchpad Translations data model almost
unmaintainable.

So, as we discussed today, I've seen mention of the following ideas of
how we can do it:

 1. introduce a "fall-back POTMsgSet" where we basically tag matching
POTMsgSets between Ubuntu and upstream
 2. re-use and fix is_imported flag to finally be is_upstream flag as it
should have been from the start, making use of existing message sharing
 3. do an actual import from upstream translations into Ubuntu
 4. cleverly extend message-sharing to support this another dimension of
the problem
 5. handle it at updateTranslation level: negotiate what action needs to
be taken in code, and do merging and duplication as necessary

2 and 4 would be more scalable (i.e. wouldn't grow the DB too much), 1
is close to that, yet 3 and 5 would be very much unscalable.  To top it
off, 3 would be the only one with only a one-way sync, which I think
scratches it off the list.

5 would make for obnoxious code in the exact spot that is already
obnoxious: updateTranslation method.  It's similar with 4: currently, a
single translation message can be: current (active), imported (coming
from an import), and diverged in any of the series for distro/project.
Now, any of these can be combined with each other, or none can be set
(when it's merely a suggestion), which totals a huge number of possible
states. Thus, "cleverly" extending message sharing to support this would
probably end up being not so "clever" in the end.

As such, I lean on looking only on options 1 and 2.  They both have
their problems, but I think they'd bring biggest wins with the least
amount of effort.  And as a matter of fact, after some thinking about
option 2, I believe it'd fix up a bunch of other problems in Launchpad
(the one where "is_imported" is confusing and not well implemented
because it's not really "is_upstream", but it's really close to it).

I'll be documenting what I feel needs doing for option 2 on 


https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported

I hope Jeroen can put some of his thoughts on

https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FallbackPOTMsgSet
  
Anyone else, with any comments and/or ideas?  Let's discuss them and put
them into appropriate pages under "Thoughts" on

  https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu

It's open to everybody's commentary, so let's hit it on.

Cheers,
Danilo