jamesarosen/ember-i18n — pull request #44 by heartsentwined (2013-04-14 07:19:08+00:00)
Title: Rewrite

I have originally forked `ember-i18n`, intending to implement recursive dynamic translations + bindings, with this use case in mind:

```coffeescript
Em.I18n.translations =
error: '{{model}} is invalid: {{reason}}'
user: 'User'
wrong_format: '{{attribute}} is wrongly formatted'
```

```handlebars
{{t error model="user" reason="wrong_format" attributeBinding="view.email"}}
```

Rendering something like `User is invalid: foo@bar is wrongly formatted`.

We can do "static" composition at present via helpers:

```coffeescript
Em.I18n.translations =
user: 'User'
email: 'Email'
user_email_wrong_format_error: '{{t user}} is invalid: {{t email}} is wrongly formatted'
```

But I'll still have to specify the whole matrix of `user_email_empty_error`, `user_password_empty_error`, etc, and this still does not solve the bindings issue.

I'm sure I'm not the only one encountering this use case in apps.

As I hacked on it, the limitations of the current architecture become apparent. Mainly, this relates to the logic in the `{{t}}` helper. I was unable to property maintain scope while doing recursions; there was also the difficulty of keeping the context tied to the original View at entry point, which is vital for bindings to work. Somewhere along the line, I managed to get the js to work for like 70% of the cases, but the logic has already spilled over three screens.

So I decided to refactor the library, splitting the original source file into logical chunks, adding sprockets, using coffeescript where I feel a lot more comfortable, etc. Long story short, I managed to implement translation interpolations + bindings, all recursive, and it was trivial to extend it to {{translateAttr}} as well in my implementation.

The rewrite has also implemented some features that are on your roadmap / docs:
* Support for interpolations + bindings on attribute translations
({{translateAttr}}) (your main README doc)
* CLDR Pluralization integration (#31, #38)
* npm support (#31, #32)

However, the changes are now, IMHO, sufficiently and significantly different from the original repo and, to a certain extent, the original architecture, that I consider this more a fork + rewrite than a patch / pull request.

The full list of changes can be seen in the new [Changelog](https://github.com/heartsentwined/ember-i18n/blob/master/CHANGELOG.md).

This PR is more like a discussion thread on how `ember-i18n` should proceed. Back-porting the new features and architectural changes to the `i18n.js` file is, I think, counterproductive; although I don't mind if somebody volunteers to do this task.

I have started my work based on the latest `v2.0` branch, so it should have already included all changes that you have pushed to the github repo.

I have also written a corresponding `package.json` and `ember-i18n-source.gemspec`, ready for publishing as npm and gem package. (Bower is still supported; it can auto-generate a `component.json` based on repo name and tags.) I have listed myself as the maintainer to take responsibility; but the original code - and credit - goes to you guys, so I am happy to take a back seat and list you as the author and maintainer if you want to.

Please let me know if you plan to integrate this PR, let my fork take over, or keep both. In the latter case, I will rename the package to avoid taking over your namespace.

Many thanks for your great work in this library.

heartsentwined