i18n not possible with this solution?

[mbrochh]

do I understand this correctly? With this solution it would not be possible to have {% trans "foo" %} tags in the icanhaz templates since those are no longer being parsed by django?

how do you handle i18n in your projects when using django-icanhaz?

[carljm]

True - I haven't yet needed both i18n and JS templating in the same project. It would not be too hard to add a pre-processing step specifically for i18n; doesn't seem worth running it through the Django template engine just for that.

[rmaceissoft]

what about another tags {% url %}, {% now "jS F Y H:i" %}, and many others.... @mbrochh I recommend you this custom template tag (https://gist.github.com/893408), improved by @maraujo from @ericflo's initial version.

So, @carljm, I recommend you parse templates with django engine and I thank you for this app.

[carljm]

@rmaceissoft Rather than using {% url %} directly in an icanhaz template, you can use it in a Django template and put the url in a data- attribute that JS can access and use when rendering the icanhaz template. As for now, Javascript itself can render the current time without help from Django; if you need the server version of the current time, you can take a similar approach with a data attribute. This may seem like more work, but in our experience it's compensated by the gain of having a clear mental separation between the server side and the client side and more readable templates.

Translation is more of a puzzle; I think it would make sense to add dedicated "translation" syntax to django-icanhaz and run a translation step on the template before outputting it. I'll probably get around to adding that when I run into the need for it.

Thanks for your comment!