Internationalize (a.k.a. i18n) is a very basic practice when working with multi-lingual websites. A simple i18n mechanism involves only a dictionary containing the pairs of strings, and a dictionary lookup function (e.g. the underscore magic function _() ). Once these two things are ready, the implementation is relatively simple. Major programming frameworks also provide their own i18n functionality, or if it doesn’t, there is also a mature module called “gettext” available to help.
Well, all these are true when talking about server-side programming.
What about client-side i18n?
- Work with string identifiers(i.e. __(‘this_is_my_string’); ), but doesn’t work with full sentences (i.e. __(‘this is my string!’); ).
- Heavy weighted, even excluding the dictionary file.
- Dictionary needs to be pre-compiled.
- Cannot work without the JS framework. (Framework is heavy!)
What makes jsIn different?
I’m not saying jsIn is totally different from some others, because I don’t have the time to test all the available i18n solutions to see the difference. The methodology in jsIn is very simple (as mentioned before, the most simple form of internationalization is just 2 things : a dictionary file and a lookup function.), that some others may have already been using it. If this is the case what I can say is “coincidence”.
There are some features that I can’t find them all in any single solution but jsIn:
- Work with both string identifier and full sentence translation.(And string identifier gives extra performance boost.)
- Light weight, actually it’s tiny weight: just 1.3KB after minified, excluding the dictionary files.
- Standalone : no frameworks required. Actually you can even put the script in the header so that your strings can be translated before it shows to the visitors.
- Global magic function. Just call __(‘string to translate’) anywhere you like, even inside a jQuery plugins!
It also passed our unit test page and is used in production server now.