Only use base class accessors (24, can be split)
use unit.source instead of .msgid or pootlefile.getunquotedmsgid
use unit.target instead of .getunquotedmsgstr and .setunquotedmsgstr setmsgstr still used, because it actually does more like updating the header, etc.
handle plurals the toolkit way (use .hasplural(), and plurals are in .source.strings and .target.strings) Don’t assume that .strings exist.
comments (think about different types) (#: comments are done in baseclass (locations), perhaps getnotes(origin=” ...”) similar to addnote(text, origin=”...”)
header, isheader, updateheader
istranslated() - implemented, perhaps not yet used everywhere?
...
Optional/later: Take out statistics (16, can be done in parallel with above, with risk)
Statistics object (full, quick) (this already is partially done by merging from pootle-locking branch)
unify use (no code duplication, no unnecessary file loading)
(added later) redo suggestions code that still uses msgidcomments (4 - once we know what we want to do with them) This is still done for PO files
Delegate to a storage object from pootlefile rather than overriding (16) pootlefile.py should delegate to a .store member which can be po or xliff (or something else). It should not be overriding storage.po (being done by merging from pootle-locking branch)
get file name and/or file extention by means of an API (8) Wherever the filename of a pootlefile is needed, it should be obtained by a member/function to ensure that no code makes an assumtion about “.po” anymore.
use factory to construct storage (3) - The .store member of pootlefile should be constructed using storage.factory to make such code mostly unaware of which type of file it is dealing with.
Have one merge implementation across toolkit and Pootle, if possible (perhaps hooks, for handling things like conflict → Pootle suggestions) (24, can be started at any time) check pootle’s uploadfile, pot2po and pomerge
Project attribute to specify local fileformat (default XLIFF) (4, can be done earlier) This must be a project property that specifies what the native format is that Pootle uses. ←-- Project file format now supported via Project Admin Web page
Project attribute to specify upstream fileformat (default PO) (perhaps also style: GNU/non-GNU) (4, can be done earlier) This must be a project property that specifies what format is used by the upstream project. This is mostly useful for version control integration, and updating from templates, etc.
Add XLIFF <alt-trans> suggestion methods to Pootle, allowing for xliff suggestions. ←- Also apply methods throughout Pootle
Figure out implications for templates/
First move to XLIFF, test: (12) (just basic regression testing)
listing
statistics
checks
goals
assigns
file view
file edit
suggestions (review)
merge from XLIFF and PO
CVS update from XLIFF and PO (XLIFF→XLIFF, XLIFF→PO, PO→XLIFF, PO→PO) (12)
CVS commit to XLIFF and PO (XLIFF→XLIFF, XLIFF→PO, PO→XLIFF, PO→PO) (4)
download xliff should give real XLIFF, not some conversion (1)
download PO should generate if XLIFF is used locally (2)