@Billy, I agree with @Simon and will avoid window.name and stick with localStorage and then Cookies for IE7- I will look into TRACE but, as their are some security concerns and the fact that not all servers will be configured for this, one will need to test and see whether TRACE is configured and if not, fall back to the ‘service’ url.

I think you’re not talking about i18n library, but l10n library. I18n JS library is being developed by TC39 EcmaScript comitee – https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnM&ndplr=1

For L10n needs, I’m afraid that your lib is not different from gettext in the sense that it supports plain key-value pairs without any flexibility for placeables, genders, declensions, plural forms etc.
For Jetpack JS l10n I’m working on the library called Common Pool – http://diary.braniecki.net/search/Common+Pool and a more powerful but complex library called “l20n” – http://wiki.mozilla.org/L20n (JS bindings even have some initial patches for Gecko js service).

If you want to chat about it, join us at #l10n-tools IRC channel! I’m going to start a l10n technologies community at Mozilla very soon and projects like yours are welcomed! I’d love more people to think and work on various approaches to localizability of our technologies

First, you can replace the server-side component. Instead, use an XHR and set the HTTP method to “TRACE.” TRACE tells the web server to return the HTTP request you made (including the Accept-Language header) to you as the response. Now you can parse the Accept-Language header in JavaScript. Most web servers have this turned on by default, and its a trivial configuration change if its not. (Also, there were some security concerns with enabling TRACE, mainly around XSS attacks, but all modern web servers have patched this issue).

Second, you just want to temporary cache the JSON data with localized messaging. And a polyfill for this is too heavy as you said. Why not replace localStorage with using window.name? It’s a bit of a hack, but will give you dozens of kilobytes to cache the JSON string, and it works in all browsers. This makes you logic very simple: if in window.name cache, parse the JSON, if not, fetch it and cache it.

http://www.sitepoint.com/cookieless-javascript-session-variables/

I am not pushing i18njs as ‘the’ solution for internationalization but, what often happens when people mix JSP, or PHP or whatever with JS to provide internationalization is that their JS are embedded in the page and they are not using an external JS files of a more modular nature that can be reused and better maintained.

The idea behind i18njs is to provide a solution within JavaScript that is completely server agnostic. If however you have a solution that allows you to mixin JSP tags within an external JS fiile, great, use it. If not, consider i18njs and let me know your thoughts.

Thank you for your comment,
Schalk

var error =
….

Is this right or there is another alternative to this ?