-
Notifications
You must be signed in to change notification settings - Fork 57
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
Comments
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). 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 @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 |
I think |
Good point. |
I ran in to this exact issue recently, where
|
I have the same issue that my 'half' translated The |
Project seems to be quite dead... unfortunately |
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 |
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 You can run And then you can run
to get the one you want. |
That's ok only till you have few locales to merge |
Also, for reference, I'm afraid So, I'd avoid naming flag as Though, it would be great some day to see |
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.
The text was updated successfully, but these errors were encountered: