Bug 1034836 - [RFE] Support update_po --previous like msgmerge --previous
Summary: [RFE] Support update_po --previous like msgmerge --previous
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 3.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 4.1
Assignee: Jeff Fearn 🐞
QA Contact: Ruediger Landmann
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-26 15:17 UTC by Raphaël Hertzog
Modified: 2014-05-05 06:03 UTC (History)
2 users (show)

Fixed In Version: 4.1.0
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-05 06:03:23 UTC


Attachments (Terms of Use)

Description Raphaël Hertzog 2013-11-26 15:17:31 UTC
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 22:18:26 UTC
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 20:36:37 UTC
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 05:02:28 UTC
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 16:02:08 UTC
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 23:12:47 UTC
(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 05:48:08 UTC
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 06:07:49 UTC
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 07:17:08 UTC
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 06:03:23 UTC
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.