How to structure large scale multi-lingual application with Ember-cli

Ember CLI
1

I am looking into Ember.js as a framework for redesign/rework of a large scale website/application at my company. I would love to turn the website into a Single Page Web Application and I think that Ember would be great fit for us. I really love the Convention over Configuration because it would make our life easier for managing things down the road and it would provide consistency with a lot of developers working on this application.

I have been messing around with Ember and Ember-cli by reworking the TodoMVC tutorial for Ember-cli and HTMLbars, adding a bunch of unit tests and additional plugins for Ember-cli and I think that I am getting a handle on how things work (at least to some extent!). However, I have some concerns regarding converting ~300 pages/views, handling localization and permissions for the currently logged in login. I am not sure what the best practices to handle all this would be.

Here are my thoughts/options as I see this:

1. Load up templates and translations through ajax

  • Load up templates via ajax, compile them on the fly in the browser and cache it
  • Load up translations for the view through ajax and cache it
  • Align everything together so that everything shows up correctly

Pros:

  • Smaller app load up size
  • Do not need to put all translations into one file
  • Localized texts could be included in the template directly as the server knows what language it needs to generate it in
  • Template could be optimized based on logged in login permissions - for example do not even include the edit button in the template if the login does not have permissions for that
  • Webservices would only have to serve the actual data and not permission based properties

Cons:

  • Things might be slower as the user is using the web app; on top of having to retrieve data we would have to retrieve both the template and the translations
  • Compiling templates in the browser is a bit scary as I assume it would really lower performance if some page/view has multiple templates
  • Need to load up a template and translations (to be used by the client side) separately
  • Need for some kind of automated resolver that would load up the necessary templates and translations automatically for each page/view

2. Pre-generate templates with placeholders for translations; pre-generate all translations

  • Have templates be in their own .hbs files and let Ember-cli compile them all together
  • Pre-generate all translations into separate js files, per language, have Ember-cli include them in the project file
  • Webservices would have to send not only data, but also whether logged in login has permission to edit the dataset

Pros:

  • Simpler to build, no server side generation necessary
  • Faster once the app loads up
  • No need for special resolver that would load up the templates and translations via ajax

Cons:

  • Large translation file
  • Large generated ember javascript file because of the number of templates (and other associated JS files)
  • Need to handle all permissions and different options in the templates on client side
  • Need to be able to associate translations correctly with the templates (for pages/views)

As I am just starting with Ember, I am not sure what the best solution to these problems is. I was not able to find any good documentation or examples on this, mostly because of the rapid development of Ember, but also due to the fact that each application has different requirements.

I would be completely ok if the application had to reload itself when the logged in user changes language; this happens very infrequently and would be ok to take the penalty hit. My big worries is how to structure everything correctly so that the resulting javascript files will not end up being huge and won’t take forever to load.

Thanks for all your help!

2

As far as this goes, a few thoughts. I’m working on a large app that matches what you’re talking about, so I fully understand the questions / concerns :wink:

Permissions

  • would suggest you use ember-can (https://github.com/minutebase/ember-can). We’re not very far into this, but looks like we’ll be able to pass back as much permission information as we need. This means you’ll have to pass back a lot of your (I’m assuming) RBAC rules, but you can theoretically run those (and cache them) on the server and then send back the cached versions. In our app, these rules don’t change that often, so it’s worth the headaches.

Languages. The two plugins to consider here seem to be

Of the two of them, ember-i8n has an older codebase and just recently started supporting Ember-CLI. However it is specifically designed to allow flexible translation loading (including loading up translations via Ajax on the fly). Ember-CLI-i8n has the Dockyard folks backing it (which is a big plus) and has a newer design. But they haven’t used it as heavily for translations on projects of theirs (per comments I’ve read on issues on their Github repo) as the ZenDesk folks (behind Ember-i8n).

At some point, they may end up getting merged into Ember-i8n, although that’s still an in-progress discussion. https://github.com/dockyard/ember-cli-i18n/issues/56

We’re currently leaning toward Ember-CLI-i8n but haven’t launched yet (or fully tackled the translation portion of our rewrite yet).

Would love to hear what you guys decide :slight_smile:

3

Realized I didn’t actually address your question.

I would suggest you do this:

Option #3 - pre-compile all templates using Ember-CLI, only load one language and load the rest using Ajax asynchronously as needed. That way you aren’t trying to handle templates / translations (Option 1) sent back from the server, seems like it’d get messy in a hurry. But you also wouldn’t need to send all translations with your Ember-CLI app (Option 2). This is the route we’re aiming to go.

4

Thanks for the response! The Option #3 is the one I was starting to lean towards over the weekend. I was just still afraid a bit of even one language translation file size, but it turns out to be 600kB for English, and 173kB gzipped, which is not bad at all. I wish there was a way to maybe split it up between core translations that would not change and possibly the rest so that we could cache at least something, but that might be too much trouble for not much benefit.

Thanks for mentioning ember-can, that definitely looks interesting. I have seen ember-cli-i18n previously and it seemed quite promising. Another tool that I have seen pop up recently is Format.js - http://formatjs.io/ember/ . I think it looks pretty cool, but not sure if it is meant to handle standard translations as well.

Thanks again!