Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for msgmerge like functionality or otherwise enable smarter merging. #90

Open
JanezStupar opened this issue Apr 9, 2015 · 14 comments

Comments

@JanezStupar
Copy link

Default PO generation will overwrite existing translations with empty strings.

Using --join-existing flag leads to stale contextual comments and code references that clutter the PO file - which leads to either confusion on translator end or additional manual maintenance of the PO files.

Default solution is to incorporate another step and use msgmerge program from the Gettext utilities, however I find that slightly inconvenient and unnecessary while working on pure JS projects.

Are there any plans to improve on this behaviour?

I am also open to contributing a PR for this if you can give me some guidelines.

@BYK
Copy link
Collaborator

BYK commented Apr 9, 2015

If you can spec out the exact behavior you are expecting I'd be more than happy to help.

@JanezStupar
Copy link
Author

https://dl.dropboxusercontent.com/u/37411674/foo.po.tar.gz

In the linked package you will find three files.

foo.po is the original file (i.e. the existing file located in the jsxgettext user's repo).
foo2.po is the new file (i.e. output of jsxgettext's latest invocation).
foo3.po is the file obtained through invocation of msgmerge foo.po foo2.po > foo3.po

You will notice that foo3.po contains the existing translation from foo.po, however code references and comments are replaced with the ones from foo2.po.

This is the kind of behavior I would expect from the new feature. I.e. when jsxgettext runs with the msgmerge flag it should take translations from existing po file and comments/code references from the parser output.

However it should be first considered whether this feature does make sense at all in jsxgettext project. Because it seems that thus far jsxgettext seems to be aiming for feature parity with xgettext.

On the other hand - this feature would free users from having to install gettext and writing separate script tasks for msgmerge.

@BYK
Copy link
Collaborator

BYK commented Apr 13, 2015

From the examples you've provided, all I can see is you actually want a --keep-translations option or jsxgettext to keep any existing translations for the same string which actually makes sense to me.

@zaach - What do you think? I'd opt for direct behavioral change to avoid adding too many CLI parameters.

PS: @JanezStupar you should rename the file extension to .tar.gz instead of .zip since they are not the same thing. I took me a few minutes to understand why 7-zip was complaining and not showing 3 files ;)

@JanezStupar
Copy link
Author

I think --keep-translations route would be a better option as current jsxgettext behavior is in line with the xgettext command behavior. I would even argue that naming the flag --msgmerge would be a better solution as it alludes to the standard gettext toolkit behavior.

@BYK
Copy link
Collaborator

BYK commented Apr 13, 2015

as it alludes to the standard gettext toolkit behavior

Good point.

@zaach
Copy link
Owner

zaach commented Apr 13, 2015

I ran in to this exact issue recently, where --join-existing was less than ideal. So, 👍.

--msgmerge would be okay as a name as long as it doesn't overpromise what our feature does.

@fraserxu
Copy link

I have the same issue that my 'half' translated .po file is override when generating the same .po file with some updates.

The --msgmerge seems the right way to do it, any update on this?

@ArmorDarks
Copy link

Project seems to be quite dead... unfortunately

@BYK
Copy link
Collaborator

BYK commented May 31, 2015

Dead? Far from it! I'm just in one of those super busy episodes of my life.

I may be able to get to this around this week.

@ArmorDarks
Copy link

Sorry if I've sounded offending.

I just was quite upset that it's the only, in fact, one gettext parser for Jinja, and it wasn't updated for a while.

I wish I could do more for project, but I still need to learn a lot before I can get my hand on parsers code.

@geekyme
Copy link

geekyme commented Jul 29, 2015

+1 for this issue. I am also currently using -j option but I realized that this simply appends new translations to my .pot files, it does not check for stale translations and remove them from the pot file / mark as fuzzy.

@fraserxu
Copy link

I'm using this module to generate the po file from my JavaScript code, in order to be abel to merge new translation with the existing one, I use the original gettext from homebrew.

You can run brew install gettext and run brew link gettext --force if needed.

And then you can run

msgmerge my.po my.new.po -o my.po

to get the one you want.

@ArmorDarks
Copy link

That's ok only till you have few locales to merge

@ArmorDarks
Copy link

Also, for reference, I'm afraid msgmerge isn't that simple:
https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html

So, I'd avoid naming flag as msgmerge, since it won't do all things, which are expected from such utility.

Though, it would be great some day to see jsmsgmerge (ouch, that's hard to read name...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants