Consider a JSP application with multiple JavaScript files. The backend is fully localized using multiple files .properties

, one for each language. The HTML provided contains strings in the correct language - this is all common stuff and works great.

Now, however, from time to time I need to use some localized string in a JavaScript resource. Suppose for example:

function foo() {
  alert('This string should be localized!');
}

      

        
        
        
      

    

Note that this is somewhat similar to the need to reference some AJAX endpoints from JavaScript, which is handled well by the reverse JS router. However, the main difference is that the backend does not use a router, but uses strings.

I have come up with several approaches, but none seem to be good enough.

Parameters

The JSP that outputs the code to call foo()

will select the line:

foo('<%= localize("alert.text") %>');

function foo(alertText) {
  alert(alertText);
}

      

        
        
        
      

    

Pros: It works. Cons: Method signatures are bloated.

Prototypes

JSP displays hidden range with string, JS selects it:

<span id="prototype" class="hidden">This string should be localized!</span>

function foo() {
  alert($('#prototype').text());
}

      

        
        
        
      

    

Pros: Method signatures are no longer bloated. Cons: Make sure the hidden <span>

one is always present.

AJAX

There is an endpoint that localizes strings by their key, JS calls it. (The code is approximate.)

function foo() {
  $.ajax({ url : '/ajax/localize', data : { key : 'alert.text' } })
      .done(function(result) {
          alert(result);
      } );
}

      

        
        
        
      

    

Pros: The server has full control over the localized result. Cons: One HTTP call per localized string! Any of the AJAX calls fail, the logic breaks.

This can be improved by getting multiple lines at once, but the problem with rountrip is significant.

Shared properties files

The properties file containing the current language is simply displayed as an additional JS resource on the page.

<script src="/locales/en.js" /> // brings in the i18n object

function foo() {
  alert(i18n.alert.text);
}

      

        
        
        
      

    

Pros: Fast and reliable. Cons: all lines are pulled in - also those that we don't need or don't want to show to the user.

This can be improved by keeping a separate rowset for JS, but this violates the DRY principle.

Now what?

So these are the ideas that I had. None of them are perfect, all have their share of problems. I am currently using the first two approaches with mixed success. Are there any other options?