Merge lp:~danilo/launchpad/get-current-translation into lp:~launchpad/launchpad/recife
| Status: | Merged |
|---|---|
| Approved by: | Graham Binns on 2010-11-16 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 9195 |
| Proposed branch: | lp:~danilo/launchpad/get-current-translation |
| Merge into: | lp:~launchpad/launchpad/recife |
| Diff against target: |
314 lines (+243/-8) 4 files modified
lib/lp/translations/interfaces/potmsgset.py (+9/-0) lib/lp/translations/model/potmsgset.py (+34/-1) lib/lp/translations/model/side.py (+2/-6) lib/lp/translations/tests/test_potmsgset.py (+198/-1) |
| To merge this branch: | bzr merge lp:~danilo/launchpad/get-current-translation |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Graham Binns (community) | code | 2010-11-15 | Approve on 2010-11-16 |
|
Review via email:
|
|||
Description of the Change
= getCurrentTrans
== Background ==
This implements a getCurrentTrans
The work that we are doing is enabling sharing of translations between Ubuntu and upstream projects. The concept that we introduced earlier is "translation sides" — Ubuntu or upstream — which indicate what particular translation we are interested in. So, a single POTMsgSet (basically, an English string container) will provide a translation for both an upstream project and Ubuntu package (and it can even be the same one).
This work extends our existing message sharing infrastructure, where one POTMsgSet can be in more than one POTemplate. The concepts that are relevant to this branch are "shared" and "diverged" translations. A shared translation is one that is not specific to any one POTemplate (so it has TranslationMess
== Implementation ==
IPOTMsgSet.
for a given POTemplate and a given Language. By default, it assumes you are looking for whatever side POTemplate is on (either upstream or Ubuntu)
When POTemplate is not passed in, it is treated as a request solely for the shared message.
TranslationSide traits class is used to generalize some common operations which depend on the side (UPSTREAM/UBUNTU) without having to write code that specifically calls that out. For instance, getFlag call that is used on TranslationMessage is used to construct "TranslationMes
However, that gives me a security proxied object so I had to add a removeSecurityProxy around it. I am not sure how I could better solve this (other than moving it into the traits implementation itself, but that's probably even worse). Any suggestions welcome.
Rest of it should be fairly self-explanatory, except perhaps for the order_by clause at the end: it simply sorts diverged translations (those with POTemplate set) before shared ones (so they are preferred ones).
Tests are unified for both "sides" and only basic methods are re-implemented. If test set-up is not clear, I'd be happy to re-write it and provide better commentary.
== Demo & QA ==
This goes into our integration branch, and will be QAd together with it. At the moment, this method is not used and that's coming in follow-up branches: we are taking it step-by-step.
== Tests ==
bin/test -cvvt GetCurrentTrans
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
| Jeroen T. Vermeulen (jtv) wrote : | # |
| Jeroen T. Vermeulen (jtv) wrote : | # |
(By the way the branch I'm working on has a basic 3-line stub implementation of getCurrentTrans
| Данило Шеган (danilo) wrote : | # |
Hi Jeroen,
Thanks for taking a look.
У уто, 16. 11 2010. у 07:16 +0000, Jeroen T. Vermeulen пише:
> Doesn't this duplicate TranslationSide
> POTMsgSet.
Uhm, yes. That's the whole idea: create new methods which support the
new semantics (concept of sides), while keeping old ones intact.
> If so, you could use this new code to replace those (and conveniently
> sweep out any non-Storm code along the way).
Ultimately, yes. The branch's sole purpose is to not remove/replace any
existing code because that's going to cause a lot of test breakage.
I've even tried that long time ago and decided to split it up for that
very reason. I think it was even you who strongly pushed for the
approach, so I am very much surprised by these questions. :)
FWIW, TranslationSide
this method or the other way around. Not in this branch, though.
> That would require splitting it up a bit further though.
This originally started as an internal method to replace _getUsedTM. As
soon as we decide to switch actual callsites (wrapper methods in
IPOTMsgSet) to the new method, I believe it should be made private
again. Or perhaps not, and we should just use this single method.
> Also, I question the wisdom of intelligently deriving the translation
> side from a potemplate argument that is optional. We're using the
> same argument for two very different purposes: divergence and
> side-sensitivity.
Yes, I did consider that too. It turned out it's useful and simplifies
testing. It's easy to split that code out, but as we start using this
method in tests more and more, we are going to hate to have to pass in
potemplate.
live in the test helpers, and I am fine with that if that's what you'd
agree with.
Still, I feel it's not heavy at all and could very well stay in, but I
am not very attached to the functionality. ;)
> It gives rise to two kinds of call: "figure out the
> side from this template" and "I'll figure out the side; the template
> may be None." We'd be better off with those as separate methods to
> represent side-sensitive and side-insensitive "layers" in our code.
> The latter is basically our existing
> get{Current,
> wrapper around that layer.
>
> To do case-sensitivity right we'd need another optional argument,
> along the lines of ignore_
> interfaces cleaner and more helpful overall.
Uhm, not really (on the "we'd need"). You can get a shared translation
for either side by passing the side explicitely in (while keeping
potemplate=None). As I said, this method could probably be made private
instead.
| Данило Шеган (danilo) wrote : | # |
Ok, Jeroen and I discussed this on IRC in order to agree on a general approach (and clarify what I've been doing). I've done a few minor changes and am now looking for a proper review :)

Doesn't this duplicate TranslationSide Traits. getCurrentMessa ge and POTMsgSet. _getUsedTransla tionMessage? If so, you could use this new code to replace those (and conveniently sweep out any non-Storm code along the way). That would require splitting it up a bit further though.
Also, I question the wisdom of intelligently deriving the translation side from a potemplate argument that is optional. We're using the same argument for two very different purposes: divergence and side-sensitivity. It gives rise to two kinds of call: "figure out the side from this template" and "I'll figure out the side; the template may be None." We'd be better off with those as separate methods to represent side-sensitive and side-insensitive "layers" in our code. The latter is basically our existing get{Current, Imported} TranslationMess age and the former is basically a wrapper around that layer.
To do case-sensitivity right we'd need another optional argument, along the lines of ignore_ diverged= False. I think that would make the interfaces cleaner and more helpful overall.
Jeroen