zaach
Support for msgmerge like functionality or otherwise enable smarter merging.
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.
If you can spec out the exact behavior you are expecting I'd be more than happy to help.
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.
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 ;)
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.
I ran in to this exact issue recently, where --join-existing was less than ideal. So, :+1:.
--msgmerge would be okay as a name as long as it doesn't overpromise what our feature does.
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?
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.
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.
+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.
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.
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...)