Merge lp://qastaging/~henninge/launchpad/devel-bug-597539-translationmessage-pofile into lp://qastaging/launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Henning Eggers | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 11504 | ||||
Proposed branch: | lp://qastaging/~henninge/launchpad/devel-bug-597539-translationmessage-pofile | ||||
Merge into: | lp://qastaging/launchpad | ||||
Diff against target: |
1384 lines (+279/-572) 18 files modified
lib/lp/translations/browser/tests/translationmessage-views.txt (+6/-34) lib/lp/translations/browser/translationmessage.py (+69/-42) lib/lp/translations/doc/gettext-check-messages.txt (+9/-44) lib/lp/translations/doc/pofile.txt (+1/-1) lib/lp/translations/doc/potmsgset.txt (+5/-3) lib/lp/translations/doc/remove-upstream-translations-script.txt (+0/-142) lib/lp/translations/interfaces/pofile.py (+7/-0) lib/lp/translations/interfaces/translationmessage.py (+6/-0) lib/lp/translations/model/pofile.py (+37/-15) lib/lp/translations/model/potmsgset.py (+0/-1) lib/lp/translations/model/translationmessage.py (+11/-1) lib/lp/translations/scripts/gettext_check_messages.py (+4/-29) lib/lp/translations/templates/currenttranslationmessage-translate-one.pt (+12/-12) lib/lp/translations/templates/translationmessage-translate.pt (+1/-1) lib/lp/translations/tests/pofiletranslator.txt (+1/-12) lib/lp/translations/tests/test_doc.py (+2/-6) lib/lp/translations/tests/test_pofile.py (+108/-2) scripts/rosetta/remove-upstream-translations.py (+0/-227) |
||||
To merge this branch: | bzr merge lp://qastaging/~henninge/launchpad/devel-bug-597539-translationmessage-pofile | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jeroen T. Vermeulen (community) | code | Approve | |
Review via email: mp+34441@code.qastaging.launchpad.net |
Commit message
Removed remaining uses of TranslationMess
Description of the change
= Bug 597539 =
With the advent of message sharing, the "pofile" attribute of a TranslationMessage became obsolete. TranslationMessage now has a "language" attribute which can be used to find the right POFile if you also know the POTemplate. Since a TranslationMessage can now be shared by multiple POFiles, a direct link makes no sense now.
A lot of code was still using this link, though, since the column in the database still exists and holds values. Since TranslationMessage was still setting pofile upon creation, it most likely pointed to the first POFile that this message was translated in and that mostly worked.
This branch cleans this mess up by hunting down all these uses of the pofile attribute and tries to find an equivalent replacement. Please excuse the diff size, it contains file deletions an repetitive changes in templates and such.
== Proposed fix ==
For each occurrence, one of these fixes was used:
- Use the new "language" attribute if the "pofile" was only used to get to the language. Luckily there were a lot of those cases.
- In view code it was mostly possible to use "browser_pofile" which caches the POFile that the message was currently being viewed in. Some extra code had to be added to make sure it is always set.
- Sometimes the POFile was actually known and there was no reason to use TranslationMess
- Sometimes getOnePOFile will do which just gets any POFile associated with the translation message.
- A new query to find all TranslationMessages for a POFile was introduced.
- Some scripts did not receive nice treatment, one was crippled, the other one plain deleted. ;)
== Implementation details ==
Notes for some specific files.
=== modified file 'lib/lp/
Using POFile statistics to show that a form submission succeeded is overkilll, so I removed them.
=== modified file 'lib/lp/
I introduced a new parameter 'local_to_pofile' which is passed in from the top to mark local translations explicitly instead of deriving that from the "pofile" attribute. The last chunk is the core of this change.
=== modified file 'lib/lp/
=== modified file 'lib/lp/
This script operates purely on the TranslationMessage table with no relation to a POFile. Finding an imported message is not possible without that information so it had be ridded of that functionality. Obviously this also affected the test. The change has just been commented out because that script will be revisited later anyway in our current feature work and maybe we come up with a better solution.
=== modified file 'lib/lp/
=== removed file 'lib/lp/
=== removed file 'scripts/
This script is not needed anymore so why bother fixing it? Yeah for code deletion!
=== modified file 'lib/lp/
=== modified file 'lib/lp/
=== modified file 'lib/lp/
As POFile.
=== modified file 'lib/lp/
=== modified file 'lib/lp/
The method ensureBrowserPOFile is simple but had to be in the model class because otherwise assigment to browser_pofile would not be possible.
=== modified file 'lib/lp/
This is at the heart of this branch because it stops TranslationMess
== Test ==
Just run all translation tests, it takes about half an hour.
bin/test -vvcm lp.translations
== QA ==
When this branch is on staging, the pofile column needs to b NULL'ed.
ALTER TABLE translationmessage DISABLE TRIGGER ALL;
UPDATE translationmessage SET pofile=NULL;
ALTER TABLE translationmessage ENABLE TRIGGER ALL;
Then various +translate pages need to be opened and also some imports would be great and similar. Check that
- nothing oopses
- the pofile column remains NULL'ed.
Hi Henning,
Thanks for finally ridding us of this blemish. Excellent cover letter! There are a few things that need fixing.
Points discussed on IRC:
Good job on cutting down redundant testing in translationmess age-views. txt. Don't introduce actions in doctests with "Let's" though.
I really don't like the idea of keeping dead and broken code in gettext_ check_messages. py. When we overhaul the script, it will help if all the code that's in there is valid. If we want to look up how it used to work, we have bzr.
The docstring for ensureBrowserPOFile is a bit ambivalent: it "ensures" and "makes sure" that the browser_pofile is set… "if possible." Which is it? The only scenario I can imagine it coming up empty is where all templates that contained a potmsgset have been deleted. (If a template merely stops using a potmsgset, there will still be a TTI linking the two). That could happen with manual database maintenance. Some 36% of our POTMsgSets (1.3 million) and 17% of our TMs (11.5 million) are orphans. You're adding a check to ensure that these don't show up as external suggestions; we should also clean them out of the database.
For convenience, ensureBrowserPOFile can also return self.browser_ pofile.
In getTranslationM essages, the Coalesce is a bit hard to indent nicely. How about e.g. creating a variable "applicable_ template = Coalesce( TranslationMess age.potemplateI D, self.potemplate .id)" and then having the query say "applicable_ template == self.potemplate .id"?
In updateTranslation you pass pofile=None to the TranslationMessage constructor. It's a bit moot with the Recife changes coming up, but better remove that argument altogether.
Points not yet discussed on IRC:
In pofiletranslato r.txt, I'd say that the oldest TM "belongs to" pofile #1, rather than "references" it. The reference is obsolete!
Nice job fixing up all those empty result sets we generated.
In test_pofile.py, you use factory. makeTranslation Message a lot. We now also have more specific factory methods that are 100% on the new model and don't use updateTranslation: makeSuggestion, makeCurrentTran slationMessage, makeDivergedTra nslationMessage . Please use those where possible.
Actually test_getTransla tionMessages_ baseline rolls a bunch of tests into one. That tends to weigh down diagnosis and maintenance—it's similar to the statistics check you removed from that doctest above. Could you break it down into separate "I'm creating a {suggestion, shared, diverged, obsolete} message, and it shows up in getTranslationM essages" tests?
In test_getTransla tionMessages_ condition, you're testing two factors at the same time: the addition of a query condition, and the effect of this particular condition on different types of messages. All you really want to test here is that the query condition works properly, which is 3 tests with one message each: message matching the condition is found, message not matching the condition is not found, and message matching the condition but for another pofile is still not found (i.e. the query condition narrows the search criteria rather than replacing them). If that's a lot of setUp work, consider giving getTranslationM essages a...