Does Meteor Kitchen hate Handlebars & i18n?

I am completely enjoying Meteor Kitchen. There’s little I like better than having the darn machine write code for me. BUT! I have, I think, walked into a wall.

I am doing an international/multilingual site. I was attracted to Tapi18n, it seemed pretty rational so I set about trying to fit the pieces together.

Unhappily, ALL the i18n packages use Handlebars notation for their translation point tokens. {{_ “some_key” }} And it seems that Meteor Kitchen chokes on that.

The json parser chokes on that as a string. And when it’s escaped, something else, and I think it’s the meteor kitchen program itself, puts the escape characters into the output. And that, of course, fouls up the translation process.

My first test case was on Menu components, being the most obvious. It’s now been several hours of torment.

I’d be much obliged for any tips or clues that anyone might have.

Thanks for reading.


It isn’t resolve your problem, but if you continue to use i18n, take a look on GUI for it

Just for the record, in case someone is reading here, I got it handled with the ostrio i18n package from atmosphere.

Took a little head scratching to get it just right (my requirements were rather specific) but in the end it was possible.

None of the other packages yielded to comparable levels of attention.

1 Like