If you have to store your text strings for internationalization (i18n) on the server, that's <a href="https://jaketrent.com/post/i18n-strings-javascript/">one thing</a>.  But, if you can store them in Javascript, you might think about using RequireJs and its i18n plugin, because it makes it nice and easy.



Get the Plugin
--------------

RequireJs is a single [download](https://requirejs.org/docs/download.html).  It's an AMD-style module loader.  And it rocks.  Especially if you dig those little arrows ![arrow img](https://requirejs.org/i/arrow.png)!  

The [i18n plugin](https://requirejs.org/docs/api.html#i18n) is another .js file to [download](https://requirejs.org/docs/download.html#i18n).


Specify your Strings
--------------------

The i18n uses the philosophy that you have a default/fallback language specified that usually the entire set of strings that your app will display.  Then, you can specify a set of those strings in another language or even partially implement them.  For instance, if my default language is English and I have 10 strings total but then I only specify 6 of those strings in the Spanish version of the bundle, then English will be used for the remaining 4 as the fallback language.

Your directory structure should look something like this:

```bash
js/
  nls/
    spa/
      str.js
    str.js
  main.js
  require.js
  i18n.js
```

The important thing is that there is a subdirectory as sibling to main.js, your main Require module, that is named 'nls'.  This is what the plugin looks for by default.  The names of the 'str.js' files don't matter.  In fact you can have as many and name them things with meaning in to app if you'd like.

Here's an example bundle of the English/default bundle:

```javascript
define({
  'root': {
    welcome: 'Welcome!',
    eng_only_idiom: 'You have got to be pulling on my leg!'
  },
  'spa': true
});
```

In the `root` property, we default an object with string keys and the English text that we want associated with that key.  The name 'root' specifies that this is the default set of strings.

Below, we list a new property for each language code that our app supports (or doesn't if it's listed as false, but I just leave them off if they're false).  You can use whatever language code you care to use.  On our app, the server is feeding us a three-letter language code with no locale.  Browsers will feed you a two-letter code, with locale if available (eg, 'es-mx').

The Spanish bundle would look something like this:

```javascript
define({
  welcome: '¡bienvenido'
});
```

Note that only the `welcome` string was implemented.  English only things or unsupported or not-yet translated strings can just remain unmentioned in the language bundle.

Specify RequireJs Locale
------------------------

In our main Require module, we want to specify which is the current language so the plugin knows which language bundle to look up and use.  That might look like this:

```javascript
require({
  locale: lang
}, ['myModule'], function (myModule) {
  var myMod = new myModule()
  myMod.doCoolStuff();
});
```

We haven't used the language string yet.  We've only specified the current user's language.  In my case, with the language code being provided by the server, `lang` is a global js var that gets rendered on the html page from the server.  You could interrogate the browser langugage here instead via Javascript if you'd like.

Use i18n Strings in a Require Module
------------------------------------

We know what strings we need to have translated.  We know our current user's language.  And now finally we need to use our bundles.  Here's how to import the bundle via the i18n plugin into your require module:

```javascript
define(['i18n!nls/str'], function(str) {
  return {
    doCoolStuff: function () {
      alert(str.welcome);
    }
  }
});
```

Note that we require as a dependency the main/English `str.js`.  And because we import it with the 'i18n!' prefix, it will be read as a language bundle and the appropriate language's bundle will be used.  So if the require `locale` was set to 'spa', then we would see '¡bienvenido' alerted to our screen.  Pretty dang exciting. 

Bonus:  With Handlebars!
------------------------

But you wouldn't normally just blast out strings via your Javascript code.  At least, if you love your sanity, you'll stop using string concatenation and a Javascript-based templating language.  There are many out there, but one that I have recent success with is [HandlebarsJs](https://handlebarsjs.com/).  It's a superset of mustache -- based on the same syntax but with built-in helpers and ability to extend with other custom helper functions.

So, if we were using a Handlebars template to blast our i18n strings plus markup to the DOM, our handlebars template could look like this:

```javascript
<h1>{{ str.welcome }}</h1>

```

And you could import it and use it in your module:

```javascript
define(['i18n!nls/str', 'text!template'], function (str, myTmpl) {
  return {
    doCoolStuff: function () {
      var compiledTmpl = Handlebars.compile(myTmpl);
      document.body.appendChild(compiledTmpl({ str: str }));
    });
  }
});
```

Note that I'm making a couple leaps here:  Have the RequireJs [text plugin](https://requirejs.org/docs/api.html#text) available, and have handlebars.js available. 

Compile the template with handlebars and then pass in the `str` module as a property called `str` (or whatever) to the template and then just access it like the Javascript objec that it is within the template, using `str.welcome` or `str.eng_only_idiom` or whatever other strings you invent in that wild, internationalized mind of yours.

If you have to store your text strings for internationalization (i18n) on the server, that's <a href="https://jaketrent.com/post/i18n-strings-javascript/">on

i18n Strings in RequireJs

I've seen a number of different ways that internationalized strings get put into Javascript code.  Of all of them, I kind of like just bundling the resource bundle of key value pairs in Javascript files themselves, one for each language or something close to that.  But, in a recent project, there were a few other constraints, so we did it another way.



The Situation
-------------

* We're using MarkLogic on the backend -- our data is stored in xml.  Our server-side code is XQuery.
* Some of these strings are needed on the server side as well, so storing them all on the client in .js files wasn't going to cut it.
* We wanted to get all of the strings into the same place to make the list more manageable to update and maintain.

So, now there are two parts to getting internationalized strings available in the front-end code: The data transform on the backend and the strings made available on the front-end.

The Backend Transform
---------------------

The resource bundle data looks like this:

```xml
<resource-bundle xml:lang="spa">
  <resource key="my.key.name">
    <value>Translated String</value>
  </resource>

</resource-bundle>
```

The transform a la:

```
declare function get-lang-dict($bundle-collection as xs:string, $lang as xs:string?, $keys as xs:string*) as xs:string* {
  let $eng :=
    if (fn:exists($keys)) then
      get-resource-bundle($bundle-collection, "eng")/resource[@key = $keys]
    else
      get-resource-bundle($bundle-collection, "eng")/resource
  let $translations :=
    if (fn:exists($keys)) then
      get-resource-bundle($bundle-collection, $lang)/resource[@key = $keys]
    else
      get-resource-bundle($bundle-collection, $lang)/resource
  let $max := fn:count($translations)
  for $translation at $i in $translations
  let $engTxt := $eng[@key eq $translation/@key]/value/text()
  let $key := if (fn:exists($engTxt)) then
    json:escape(fn:normalize-space(fn:string($engTxt[1])))
  else
    fn:string($translation/@key)
  return fn:concat("'", $key, "': '", json:escape(xdmp:quote($translation/value/text())), "'",
    if ($i eq $max) then () else ",")
};

declare function get-resource-bundle($bundle-collection as xs:string, $lang as xs:string) as element()* {
  fn:collection($resource-collection-uri)/resource-bundle[@xml:lang eq $lang]
};
```

Now we have our xml transformed into a sequence of xs:string, each a json object where the English text is the key and the language text is the value, like this:

```json
{ "English String": "Translated String" }
```

The XQuery expression that renders the html page includes a call to populate the Javascript "lang" object with the json:

```
declare function lang-dictionary($lang as xs:string?) as element(script) {
  <script type="text/javascript">
    jQuery(document).ready(function(){{
      lang.dict("{$lang}", {{
        {get-lang-dict("bundle-collection", "spa", ("keys", "if", "any"))}
      }});
    }});
  </script>
};
```

Note that if you provide a pre-known set of i18n string $keys to the get-lang-dict() function, it will only add those resources to the dictionary.  Otherwsie, all the resources in your bundle are added.

Front-end Usage
---------------

The lang object that stores the dictionary of translated strings is like so:

```javascript
var lang = (function () {

  var current_dict = "eng";
  var dicts = {};

  var is_array = function (obj) {
    return Object.prototype.toString.call(obj) === '[object Array]';
  };
  var set_lang = function (lang_code) {
    current_dict = lang_code;
  };
  var dict = function (lang_code, dict) {
    dicts[lang_code] = dict;
    set_lang(lang_code);
  };
  var get_translation = function (key, number) {
    var isPlural = number != undefined && number != 1;
    var dict = dicts[current_dict];
    var entry = dict == undefined ? undefined : dict[key];
    var val = null;
    if (is_array(entry)) {
      val = isPlural && entry[1] != undefined ? entry[1] : entry[0];
    } else {
      val = entry;
    }
    return val == null ? key : val;
  };

  return {
    dict: dict,
    _: get_translation,
    get_current_lang: function () {
      return current_dict;
    }
  };

})();
```

And when you want to grab a string from the language dictionary, just call:

```javascript
lang._("English String")
```

Plurals
-------

Note that the lang object implementation also allows for storage of a plural form of the translated word.  In practice, it was decided not to store our resource bundles in a parallel format.  Still, you provided data to the lang.dict() populating function that looked like this:

```json
{ "Result": ["Resultado", "Resultados"] }
```

And then got the translation like this:

```javascript
lang._("Result", results.length)
```

If it had a plural form, it would use it, falling back to the singular (1st) form.

Thoughts
-----------

So, what are the pros and cons here?  The main design issue that I felt created a bit of give and take was the keying of the strings by the English word.  The pro: If the string doesn't exist, the intelligible English string is shown in its place.  The con: It's less reliable and more brittle because you have to be able to control and escape properly the text that appears in the key.  What alternate solutions might you create?

Update: "RequireJs"
-----------------------
Or if you're using some sweet new Javascript tech, check out `this article on i18n in RequireJs <http://rockycode.com/blog/i18n-strings-requirejs/>`_.

I've seen a number of different ways that internationalized strings get put into Javascript code.  Of all of them, I kind of like just bundling the resource