Uploaded image for project: 'GPII - Global Public Inclusive Infrastructure'
  1. GPII - Global Public Inclusive Infrastructure
  2. GPII-2444

Add a handlebars helper to render content from message bundles...



    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: gpii-handlebars
    • Labels:


      In recent discussions surround UI generation, we have been talking informally about i18n issues.  I had a few ideas for how gpii-handlebars might handle this better, and wanted to write this up as a feature request to gather comments.

      Currently, in order to internationalise messages, you would have to lookup the messages and then expose the internationalised strings as context variables. Ideally, there should be a handlebars helper that can lookup and render the message.

      So, for example, say you have a message bundle like:

        "my.static.message": "This is a static message.",
        "my.template.message.names": "This is a %variable message.",
        "my.template.message.positional": "This is a %0 message.",   

      In your handlebars template, you would refer to the message key, as in:

      {{message-helper "my.static.message"}}

      Note that block helpers support a space-delimited array of either strings (as shown here) or context variables. This leads us to string templating, where we want to have the ability to pass variable data in to parts of the i18n message template..

      I would propose that the second and subsequent arguments be treated as variables to be using in string templates.  If we use string templates and named variables directly, we can pass in all or part of the context.  Let's assume that the context for our renderer is as follows:

        "variable": "dynamic"

      Our template might look like:

      {{message-helper "my.template.message.names" . }}

      The dot (.) in handlebars represents the root of the current context, so the %variable placeholder in our template would be replaced with the variable value dynamic.

      We can also stringify a JSON object as one of the arguments, as in:

      {{message-helper "my.template.message.names" "{ \"variable\":\"dynamic\" }"

      Unfortunately, with the "named" approach, we cannot mix string and variable content.

      There is also the option to use only "positional" placeholders, similar to the templating offered in Java, in which {0} corresponds to the first argument passed to the MessageFormat object.  Using the same context and the "positional" approach, our template might look like:

      {{message-helper "my.template.message.positional" variable}}

      With this syntax, we can mix strings and context variable content.

      I would imagine that (except for the templating), the message bundles would look similar to what we use with the preferences component. We may be able to reuse some of the basic approaches demonstrated there, but would need something that would operate on both the server and client side.

      On the server-side, we would need for the helper to be aware of the request (like the initBlock helper), and to make the locale available when the message bundle is looked up. For client-side rendering, we would need something to retrieve message bundles via an AJAX call, perhaps from a piece of middleware similar to the "inline" middleware used to deliver handlebars template bundles.

      cc: Steven Githens Antranig Basman




            amb26 Antranig Basman
            the-t-in-rtf Tony Atkins
            0 Vote for this issue
            2 Start watching this issue