Add JADE support about angular-gettext-tools

[rubenv]

I've given this some thought.

I use Jade for everything, server and client-side, so I'm definitely a fan.

Having said that, why would you need this? Are you sending Jade directly to the browser?

Given that you probably don't want to do that (parsing Jade in the browser is slow and pointless), pretty much any workflow will involve pre-compiling to JS. The only exception might be server-side generated pages that are augmented with Angular.JS.

I wouldn't mind having Jade support though (for the server-side case). Let's say we add it: either we write a Jade parser (might be quite complex) or we compile to HTML internally and parse that (reuses most of the code so trivial to add).

The former approach is a lot of work and error-prone: I'm not sure that we want that. The latter approach will be just as slow and you'll potentially have double the work if you also precompile your Jade to HTML elsewhere.

If speed is your main motivation then I think there's not much to be gained here over the current approach. We can add it for improving the functionality related to dealing with server-side generated parameters, but it won't do much about the speed. Better to get the motivations right from the start to avoid disappointment later on.

Unless I'm missing something, in which case I'm happily proven wrong.

[gunta]

There are some use cases for this, not only being the speed one of the factors.

For example, this is my current situation:

1. Jade compilation is slow (takes time specially when translating back and forth)
2. One needs to set up a temporary directory to store the intermediate HTML files (ugly)
3. I don't have any need for doing Jade to HTML compilation (using Express which does it on the fly, and this is a pretty common scenario nowadays)

Now, if this is implemented in angular-gettext-tools, there is one reason of why there will be a performance improvement, and also all the plugins will benefit from it (grunt-angular-text, gulp-angular-text, ...).

While I agree that parsing the Jade files would be the fastest way, because it's error prone and would take time, meanwhile doing the Jade->HTML pre-compilation would still be faster than the current situation.

Why?
Because right now if you do a grunt Jade->HTML step, and then a angular-gettext extract step, all the intermediary html files needs to be written to disk and read back to be able to work, while by doing it inside angular-gettext-tools it would be done everything on memory, thus saving the two write/read steps.

As you can see here, if this get's implemented in angular-gettext-tools, other plugins will be able to just use it. This issue is also related.

Also I'm planning on making a webpack-angular-text plugin, like this and this, so by having all the input formats centralized in angular-gettext-tools makes sense, even not only for Jade but for other formats also (maybe making this a bit more modular?).

What do you think?

[rubenv]

Why?
Because right now if you do a grunt Jade->HTML step, and then a angular-gettext extract step, all the intermediary html files needs to be written to disk and read back to be able to work, while by doing it inside angular-gettext-tools it would be done everything on memory, thus saving the two write/read steps.

Very much less so than you'd expect: any modern operating system will keep these blocks cached. And even then, the impact is insignificant compared to the time spent on processing.

Don't do this because you want to improve performance: you'll be disappointed.

Avoiding temporary files for server-rendered Jade is a valid point though.

---

Back to performance: It sounds to me like you have a workflow problem. The whole point of gettext is that you build your application in English. Then you translate all strings in one session and afterwards you integrate them back. Going back and forth between poedit and your app for every string is a huge waste of time and doing it wrong. A couple of seconds [1] for parsing string on the occasional integration won't make a difference.

[1] To give some perspective: we have a huge platform with tons of Jade files and nggettext_extract runs in under 3 seconds. Jade itself also 3 seconds. Whatever you're trying to gain here has already been lost in time discussing this thing :-)

[gabegorelick]

Why stop at Jade? Why not other templating languages? It could quickly become a mess if we're not careful.

[rubenv]

Oh, I'm perfectly fine with other template languages (the broader the support, the better), but we need to do it for the right reasons :-)