Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Integration with Handlebars and RequireJS #7

Closed
lrlopez opened this Issue May 20, 2012 · 26 comments

Comments

Projects
None yet
10 participants

lrlopez commented May 20, 2012

I'm starting a new project and I intend to implement internationalization using the library. I'd also like to integrate messageformat.js with Handlebars and I found some references to this in the documentation. Is there any ETA on the implementation?

I could try to do it myself, but I'd need some indications on where to start to do it right.

Thanks in advance!

Collaborator

SlexAxton commented May 21, 2012

I have a working version of this, but I need to separate it out of specific app code. So it's quite close. I am hoping to finish it within the week.

lrlopez commented May 21, 2012

Cool! Thanks!

It has now been a developer's week. I'm just curious as to how you would use this in JS templates in general. I assume it would hook into the template compiler itself? How would it handle the placeholders within template? I'd really like to use this!

Collaborator

SlexAxton commented Jun 25, 2012

A Developers Week

:D

I like that.

It essentially wraps any text via handlebars block helpers:

{{_ "somekey"}}
  This is has {NUM, select, 4 {#} other {some-odd}} results.
{{/_}}

This block helper is scooped out of the parsed Handlebars AST. I compile the message into a function and register it as a unique handlebars helper.

So after I do that it ends up as a module that registers a helper and is automatically required as a dependency and can then be reused across other places in your code.

{{i18n_compiled_somekey}}

At build time, it can also log out all the keys that it hit and generate the base language files.

If you override the language, it essentially throws out the message inside the block and uses the data that you send it.

Does that make sense?

(I am writing a talk on this for jQueryConSF on thursday and would like to have it released before that talk, if it's any help)

Cool, I think that makes sense. I use dust and I know it has the concept of helpers as well, but I'm not sure if it will be directly translatable.

Collaborator

SlexAxton commented Jun 25, 2012

do you use the main dust repo or some up to date fork? I know it hasn't been updated in ages.

kalebdf commented Jul 11, 2012

Hey @SlexAxton, what is your status on this?

Collaborator

SlexAxton commented Jul 16, 2012

I am (obviously) having some trouble getting something that I'm generically happy with out there. However, I am working on a bunch of tooling and I hope I can get it ironed out soon.

If you're already using my require-handlebars-plugin, some of my new public code is using a super-alpha version of the idea I'd like to implement for this:

This is the file that parses out the stuff:

https://github.com/SlexAxton/messageform.at/blob/master/dev/js/hbs/i18nprecompile.js

That's the magic file, along with the modified hbs file. You'll probably want to diff this against changes that you've made. This whole file is becoming quite messy. However, you'll need most of the updates to this file, as the logic for writing out modules during build lives in the hbs.js file.

https://github.com/SlexAxton/messageform.at/blob/master/dev/js/hbs.js

Feedback/ideas welcomed.

Has there been any news about this?

+1

Collaborator

SlexAxton commented Nov 17, 2012

Did any of you check out the links I posted above? I was hoping to get some feedback as I'm not entirely happy with the way it works.

bleadof commented Dec 11, 2012

I get a 404 or was it already merged here?

bleadof commented Dec 11, 2012

Ah, I assume the development is going here: https://github.com/jedtoolkit/messageformat.js ?

Collaborator

SlexAxton commented Feb 19, 2014

I think there is some demand here still, but I'm going to close this out. I think @gseguin is working on something good here though :D

@SlexAxton SlexAxton closed this Feb 19, 2014

gseguin commented Mar 9, 2014

I've got something working here: https://github.com/gseguin/requirejs-messageformat. It's basically the i18n! plugin implementation but with MessageFormat strings.

Much demand. I haven't taken a look at this in two years but I need it now again! Any updates on integrating with handlebars? Or should this just be a step in a build process?

gadicc commented Mar 18, 2014

Not directly related, but I made smart package for Meteor based messageformat.js, with a few extras. Meteor uses a handlebars syntax. http://messageformat.meteor.com/

Contributor

jokesterfr commented Aug 27, 2014

I did a Gist here: https://gist.github.com/jokesterfr/dbaa43dd45623d542c44
However I'm looking forward a module/lib integrating this out, server-side (with optional precompilation) and client-side.

Collaborator

SlexAxton commented Aug 27, 2014

I was working on a handlebars compiler addon that would just add the correct helper to the output. It actually works in simple cases. I haven't had a ton of time to work on it lately, but probably will jump back on it sometime this fall as I need it at work:

https://github.com/slexaxton/mfbars

Contributor

jokesterfr commented Aug 27, 2014

@SlexAxton hum, mfbars develop the idea of storing i18n keys into the template itself. I was using another approach, with external JSON language files pre-compiled into one single file, en-UK.js for example. This file is then downloaded by the browser for the translation, so one single i18n handlebars helper was needed.

Collaborator

SlexAxton commented Aug 27, 2014

It would be more or less the same, but without the extra request. It means you'd have to build your app once per language, but it's generally going to be smaller/faster. Either way, it'd be pretty easy to output the compiled files to a separate file instead.

Contributor

jokesterfr commented Aug 27, 2014

Its not only a matter of separate file or not, mfbars is helping the programmer to write its code, but I'm sorry to say I don't see it as useful as it seems. mfbars example is :

{{#if friends}}
<article class="friend-count">
  <p>
  {{#_ "friend_count" .}}
    You {friends, plural, offset:1
      =0 {like this}
      one {and one other friend like this}
      other {and # other friends like this}
    }.
  {{/_}}
  </p>
</article>
{{/if}}

Why won't you write (as a developer again) :

{{#if friends}}
<article class="friend-count">
  <p>
  {{i18n "friend_count" .}}
  </p>
</article>
{{/if}}

And then write in a js file the messageformat rules for friend_count (or import the mf rules precompiled, or directly from plain json files...) :

var friend_count = mf.compile(
  'You {friends, plural, offset:1' + 
    '=0 {like this}' +
    'one {and one other friend like this}' +
    'other {and # other friends like this}' +
  '}.');

Handlebars.registerHelper('i18n', function(data, options) {
  if (data === 'friend_count') {
    return new Handlebars.SafeString(friend_count(options.hash));
  } else {
    return 'unknown';
  }
});

Like this the i18n helper could be generic for all sentences you have to translate, no need to change it. Only messageformat rules have to be changed where they are stored.

mfbars add another building step, and strongly relies on handlebars code changes. With respect, I'm not sure its the most convenient glue for linking messageformat to handlebars.

Collaborator

SlexAxton commented Aug 27, 2014

You certainly don't have to use it or like it. I'm sorry to have offended
you with it. In my experience, it's much easier for programmers to write
their strings directly into their templates.

Like this the i18n helper could be generic for all sentences you have to
translate, no need to change it. Only messageformat rules have to be
changed where they are stored.

There's just as much genericism in writing the message directly in the
template as there is in writing it in an external file, that doesn't
suddenly change. I'm not sure what you're referring to.

mfbars add another building step

mfbars is one less build step. Just compile your template and it works
out of the box. It entirely removes the need to separately build and load
external language files. It merely slightly modifies the handlebars
compiler.

The difference is that you have the full context of your template available
to you instead of just a bunch of keys. Templates are suddenly searchable
again. Programmers don't have to then hand edit a bunch of keys and values
in a json file and make sure all of their double escaping rules get in
right.

It's not terribly coupled to handlebars. It modifies the AST, but does so
via generating nodes via the parser. At most an update to handlebars would
require a few string/key changes, but it's been stable for years.

The result is that you get to write your programs more like you always
have, and you can just generate your strings.json files for the majority of
your strings.

Contributor

jokesterfr commented Aug 28, 2014

Templates are suddenly searchable again.

I didn't thought about that, and this is a very important point.
I now better understand, thank you for sharing your point of view :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment