Extract comments

[gabegorelick]

gettext has the notion of "extracted comments." These are comments from the developers designed to aid the translators, e.g:

// Please leave %s in your translation. It is a variable.
gettext("Foo %s");

Obviously, you need to get creative in how the same is done in a markup language. Maybe a sub-expression?

[gabegorelick]

I'll probably implement this using subexpressions, e.g.

{{_ "foo" "bar" (i18n-comment "comment")}}

[smhg]

Isn't it possible to use Handlebars comments like so:

{{! Extra information about this sentence.}}
{{_ "This should be translated."}}

It would match gettext in other languages.

And can it be triggered by an addComments option?
With a value matching the --add-comments argument in xgettext?

I ask because gmarty/xgettext is an attempt to mimic GNU's xgettext (for template languages). It is where this project is mainly used.

[gabegorelick]

FYI, I ended up forking this project to implement some more features. For one thing, I don't need to use gmarty/xgettext (I plan on using build tools instead of a command line tool). gmarty/xgettext's API is also very limited, e.g. no domains, so I feel no reason to maintain backwards compatibility.

Feel free to cherry-pick whatever features you want. I may contribute some of them back to here if I have time.

[smhg]

I might have been a bit quick pushing you to contribute. I'm sorry, but I am a bit short on time this month.

I do think it is crucial this project can be used stand-alone. It isn't just a library for gmarty/xgettext.
It is gmarty/xgettext that needs to adapt to extra parameters and API changes. To the extent that there is some common API for other template language parsers to rely on.

This might not have been clear, but I'm very appreciative of your work to take this project to a better level of gettext-feature support.

The only "guideline" I used up until now were xgettext's CLI parameters as a list of possible parameters. Most of which are meant for gmarty/xgettext, but some of which flow through to this library. You think that is too much of a constraint?

[gabegorelick]

Sorry for not getting back to you sooner. I have no problem merging my fork back into this project if that's what we decide is best. My only concern is that gettext-handlebars isn't the best name for this project, since it really only implements extraction, not the gettext runtime functions. Obviously not a huge deal, but something to consider.

There's still a bunch of stuff I want to implement in my fork, but then I'll circle back and see what we can merge back up into this project.