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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
