Bug 1034836 - [RFE] Support update_po --previous like msgmerge --previous
[RFE] Support update_po --previous like msgmerge --previous
Product: Publican
Classification: Community
Component: publican (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: 4.1
: ---
Assigned To: Jeff Fearn
Ruediger Landmann
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2013-11-26 10:17 EST by Raphaël Hertzog
Modified: 2014-05-05 02:03 EDT (History)
2 users (show)

See Also:
Fixed In Version: 4.1.0
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-05-05 02:03:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Raphaël Hertzog 2013-11-26 10:17:31 EST
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).
Comment 2 Jeff Fearn 2013-11-26 17:18:26 EST
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.
Comment 3 Raphaël Hertzog 2013-11-27 15:36:37 EST
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.
Comment 4 Jeff Fearn 2014-02-26 00:02:28 EST
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.
Comment 5 Raphaël Hertzog 2014-02-26 11:02:08 EST
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.
Comment 6 Jeff Fearn 2014-02-26 18:12:47 EST
(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.
Comment 7 Jeff Fearn 2014-03-27 01:48:08 EDT
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.
Comment 8 Jeff Fearn 2014-03-27 02:07:49 EDT
Added --previous option to update_po. which gets passed to msgmerge.

To ssh://git.fedorahosted.org/git/publican.git
   97a8c61..4760642  devel -> devel
Comment 9 Raphaël Hertzog 2014-03-27 03:17:08 EDT
It would be nice if you could summarize the problems you saw with po4a on Windows in a mail to po4a-devel@lists.alioth.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
Comment 10 Jeff Fearn 2014-05-05 02:03:23 EDT
A fix for this shipped in Publican 4.1.0.

Note You need to log in before you can comment on or make changes to this bug.