When you update a translation, you're really interested in knowing what changed in the original string. msgmerge has the --previous option to integrate the original string in a comment (line start with "#| msgid"). 1/ It would be nice if we could have a way to pass custom options to msgmerge when we use “publican update_po --msgmerge”. 2/ It would be nice if “publican update_po --previous” was possible and worked both with --msgmerge and without it (i.e. with Publican's internal support).
Is there much value in this? Most, yes I'm taking a liberty ;), translation projects are in an SCMS or a web based translation service. CMS will easily show you what changed. Web translation services have a habit of rewriting your PO file for you, and almost all of them save the entire translation history.
I translate in vim and I appreciate to be able to see the original string. I use Weblate for people who can't work with PO files directly. I don't think that weblate has such a feature currently. And furthermore, for such a feature to be reliable, the web translation service should be able to redo the exact same fuzzy mapping that publican has done to match original string and updated string. This is not realistic, in particular when you don't use msgmerge but some custom code... So yes, I do believe that there is value in this feature. The "git log" of the PO files is really not usable to be able to identify the small changes in a given string, at least not when you have a significant number of strings that have changed, or have moved because you reorganized some sections, etc.
As part of this I will investigate using Po4a instead of using our own PO code. Negatives look like being 1: it probably reintroduces gettext coupling, 2: it's not ported to Windows, 3: it's not in CPAN.
po4a is heavily used in Debian, and I know its upstream author. +1 from me on this choice. I don't see the gettext coupling as a negative. 2 (Windows port) and 3 (CPAN availability) are probably solvable although I don't really see what being in CPAN brings.
(In reply to Raphaël Hertzog from comment #5) > po4a is heavily used in Debian, and I know its upstream author. +1 from me > on this choice. > I don't see the gettext coupling as a negative. It is if you want to support Windows, the gettext version for Windows is old and missing many features. > 2 (Windows > port) and 3 (CPAN availability) are probably solvable although I don't > really see what being in CPAN brings. Being on CPAN means I can easily package something and all it's deps on all the platforms I need to support. So it reduces my work load of supporting multiple platforms. Not a blocker by itself, but it could sway a decision. FYI I tried building po4a on Windows 7 last night, had to remove some features, e.g. SGMLS, and then it blew up on gettext not having --previous support, which caused me to LOL ;) Will hammer on it a bit more in the coming days.
OK so for this bug I will not be doing previous for the publican PO work flow, but I will add it as a parameter that will be passed to msgmerge. Switching to po4a is unlikely to happen as it's very broken on Windows. Updating the current Publican PO work flow requires modifying Locale::PO to handle previous, requests for that should be made upstream.
Added --previous option to update_po. which gets passed to msgmerge. To ssh://git.fedorahosted.org/git/publican.git 97a8c61..4760642 devel -> devel
It would be nice if you could summarize the problems you saw with po4a on Windows in a mail to po4a-devel.debian.org. Maybe they can do something about it. I also filed the ticket for Locale::PO: https://rt.cpan.org/Public/Bug/Display.html?id=94231
A fix for this shipped in Publican 4.1.0.