Menu
I'd like to hear feedback on my approach for internationalizing an AJAX application. Is this a sound approach? What kind of other approaches would be worth considering? Here's a summary of the app:
Build an ajax heavy application that is pretty much just a single standard HTML page. This page is dynamically generated via a server-side framework and is fully internationalized on the server-side. This page loads JQuery as well as several plugins.
From this point on, the application primarily only performs XHR requests. Some of these requests are for HTML templates (snippets of HTML code with placeholders for where real data should go) that are used by JQuery to generate dynamic content on the page. These types of requests typically do not contain any application data, but just placeholders for where the data should be displayed. These snippets are generated dynamically on the server-side and i18n is used. They only need to be requested once per template.
The bulk of the requests as the application is being used are for application data. This data is retrieved via XHR requests to a REST service that outputs JSON data. This raw data is then used by jQuery code to populate the templates and build parts of the page. Arrays of data cause the templates to be repeated. Because this data is what comes from the database, no i18n is performed on it.
If the UI ends up needing any other i18n strings, they could be stored in JSON and served either as part of the initial HTML page or as a special REST url that returns JSON key/text mappings. Features such as error messages might need this.
So this brings me to Localization. Things like dates and money are going to be transferred in normalized formats within the JSON data. So it will be up to the client to display this information in the correct format for the client. I don't think this will be too much of a problem, or will it?
If it will, maybe I should have the server-side return appropriate format strings based on the client locale. The client could use something like DateJS to format dates. I'm not quite sure about that yet, especially since DateJS is so big. But there are other client-side options that are much smaller.
I've found some jQuery plugins that might help with this. Anyone have anything to say about them? Or know of others?
221
your approach really interests me because it's an approach we've used in the past. I have some learning behind doing it that way. Here are some thoughts - hope they're helpful!
Note: I've just written this and realised that most of the content relates to the one-page-app approach rather than the localisation! Sorry. There is learning in here that you may find useful, but if you're interested only in the localisation part, skip to the Loads application data in JSON format from REST urls section!
AJAX app running from a single HTML page generated server-side with i18n
1 page web apps - ie: consisting of a single page where the content is refreshed by AJAX - in my experience are extremely fun to build. Keeping the interface as simple and as flexible as possible can only help you here. Once you get onto more complex interfaces you may end up relying on an ever increasing pool of plugins. It really depends on what your application does, so I can't really comment too much on that.
HOWEVER, in my experience the major problem I've encountered with one page apps with XHR-driven UIs is memory management. Browser memory handling around dynamically created objects is much better than it was, and it's a good challenge to ensure that your own code, and your third party plugins have good memory usage too. I've discovered that this isn't always so. If your application is expected to have short session times then great - it shouldn't be a problem. If you think people will spend a while - maybe all day or over a few days - on your application, then you'll definitely want to seriously consider this. In my experience, no matter how good the browser manufacturers say the memory management is, or how good you feel your code/third party code is at memory management, it's still not perfect. We still experience some degradation on our one-page apps now.
As a result we have taken to a sort of hybrid, where we split the application into logical areas, and have a 1-page-per-area setup. This way, the browser gets the relief of unloading the whole page every now and again and so can enjoy a good clear out. This, for us, was a much better solution. Having said that, it's really up to you, what your application does and how long you expect users to interact with it in one session. This is also good in rare cases where a problem with one part of the app cripples the whole page. This is definitely a worse-case scenario, but I'd rather have to reload one app area than the entire app.
HTML page imports JQuery and plugins
Love it. I'm relatively new to jQuery (having gone the ExtJS route), but I hear that there are some great plugins for jQuery, and there's a good solid community behind it.
Uses XHR to load server-generated i18n HTML templates as needed
Also a nice approach. When doing this, it's worth considering what your user is seeing whilst the browser is doing the work. You want to give them something to look at while you're loading the content in the background. I'm sure you've already thought of this. One thing I cannot stress enough in this approach, however, is error recovery and feedback. If something goes wrong and the page doesn't load up properly and the user is left with a crippled app - that is not a good interface experience! It's always worth spending lots of time considering what the user needs to know about what (if anything) went wrong, and good clear instructions on how to recover from it. Some users are paranoid and tend to go through a cycle of:
Something went wrong -> It was my fault -> I broke it, now I feel guilty and blamed -> I hate using this thing.
Or, you get outright teflon-shouldered users, which think along the lines of:
Something went wrong -> Not possibly my fault -> This thing is rubbish -> I hate using this thing.
Those obviously aren't the only types of user you get, but basically: anything you can do to divert the user from the "I hate using this thing" endpoint, the better! Once again, I'm sure you've already considered that!
Loads application data in JSON format from REST urls
Once again, a nice approach. We've used it ourselves. It feels great to keep the data separated from the interface. In your comments you say:
"Because this data is what comes from the database, no i18n is performed on it"
What we have done in the past is write a data-filtering system, whereby operations are performed on the raw data to make it user-friendly, and sometimes more secure, before sending it back to the client. Most server side platforms are pretty good at picking up details such as locale from the session info, so this could be where you apply your localisation changes.
If you're writing an extendible system it may be nice to open up a sort of interceptor/hook system whereby extensions also get a crack at modifying data at certain points. The world is your insert choice of shellfish, so to say.
One last thing: User "travel"
This is more a note about the one-page app approach, really. If you take the one-page-area route, it'll help you decide how to split areas too. Application users hate having to do things that they've already done and think they shouldn't have to do more than once. If your user "travels" through your interface system and something goes wrong, requiring a page-refresh to recover from (worse case scenario again!), and therefore they'll have to "travel" the same interface again to get to the place they want to be, it's going to get pretty tiresome for them. For example, in one of our one-page apps a the user travelled to functionality through a system of data-view style menus. If something went seriously wrong requiring a page-refresh they had to travel through the same menu system again to get to the same place. The solution was to move the areas of interest out to separate one-page-areas, and have menu exit points jump to these pages. That way, if an unrecoverable error did occur requiring a page refresh, the refresh kept them at their area of interest.
Sorry if I waffled. I'm new to stackoverflow - please forgive me if I've done it wrong!
181
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
