Comment 13 for bug 884270

Ok, I've prototyped a merge hook calling msgmerge as outlined above (available in the branch associated with this bug).

See 'bzr help po_merge' for details.

Note that there is some glitches I discovered while writing/testing this plugin:

1) *during* the merge, the resulting merged .pot file is not easily available (either the .po files are merged before it or the resulting file is in limbo, waiting for the merge to complete before being put into the working tree).

This is both good and bad:

- good: the .pot file present in the tree (with the content prior to the merge) is available and therefore can be used

- bad: since this is the basis .pot file it may not contain the expected strings

2) remerge currently refuses to act on files that are not conflicted

Since the hook trigerred with the basis .pot file, there is no easy way to trigger it again with the merged .pot file (once conflicts are resolved).

That being said, I've added a test that outlines a possible workflow:

- merge with the hook disabled => conflicts in .pot and .po files
- resolve conflicts in .pot files
- remerge with the hook enabled => the .po files are then merged with the correct .pot file

Before going further, I'd appreciate some feedback, especially on:
- the workflow above, is it acceptable ? Does it capture enough use cases ? Can you see simpler alternatives ?
- config: there is one option for the .pot file and one for the .po files, it's a bit error prone. If there is a single .pot file in a given po directory, then a single option specifying this po dir can be used and '*.po' and '*.pot' can be used by the plugins to achieve the same effect. This assumes that there is always a single .pot file in a given directory. Is this assumption valid ?