So we have an application that does all kinds of neat stuff and we end up with help dialogs for a lot of it. Some of the help dialogs are small - a simple paragraph or two. Others are small tutorials the user can scroll through and read, mostly text with tables and pictures and links that go to target=_blank tabs. They live in a dialog over the top of the app, rather than navigating the user away from the current context, and are intended to be read and dismissed.
Today, we populate them by supplying translated text for “title” and “message”. The “message”, of course, is a single large hunk of HTML. That’s a single really big ember-intl or ember-i18n string, full of newlines. As a stopgap, we might convert that to an array of strings and provide a helper to turn it into a big htmlSafe(t(concatenated stuff, substitution_hash)).
Of course, it would be really nice if the translators could just edit the whole page body like it was a page body. Then they wouldn’t lack for context and it would be much easier to see what they’re doing. It would be even easier to work with if it were something like markdown rather than HTML. If it could be precompiled into the translation files, with maybe an @name in the authored intl file to tell which separate file to process, we could stack all of these up in our per-language subtrees and it could be done in broccoli ahead of the other application tooling.
I’ve further thought about authoring tutorial apps with little animations as Ember components, a kind of interactive textbook. The pages would need to be localized, with some data injected, so it would use intl localization substitutions, but we’d also want to inject Ember components. (And, of course, it would be nice to use markdown for most of it.)
Right now we build applications from Ember components and use {{t "id"}} to inject localized strings into them, which is great for things like forms. Here, we’re talking about 90% localized text and 10% fragments of Ember content in components, not as separate embedded apps. I’d want to run the whole thing as a single Ember app, rather than having Ember islands.
Has anybody done anything with the notion of localized handlebar templates, possibly starting from a non-HTML syntax like markdown, transforming into a standard .hbs, which can then be compiled and the appropriate translation used? (I’m kind of feeling my way around in the dark here.)
Have you thought about grabbing translations from server rather than compiling them in? They could potentially be dynamically updated after Ember app load based on triggering events such as route transition.
I’ve got an out of date demo app of this that is meant to plug in translations from a server that retrieves them from a service such as lingo hub here:
It’s a good start, Walter. It could definitely be used as plumbing.
In any app, only loading the language that the user needs makes sense. It’s also vital to avoid user-visible latency, to lazy load but bury latency where the user can’t see it, while the user is busy at something else. No XHR should ever make a user stop and wait. A subset needed for initial use should load with the page - preferably in the page. After that, you want to load the translated content as you need it.
As long as intl lets me throw on additional translations as I need them, I can use that, but for latency’s sake, I’d prefer the translations to arrive packaged into code-splitting bundles, which means that for static-content-heavy apps, I’d want the code-splitting bundles to be per-locale. For the “tutorial app” situation, using routes for tutorial pages makes sense and then I can code-split into multi-page tutorial modules so that each page loads fast, while letting the user complete a module offline.
So I’m envisioning:
compiled handlebars that do substitutions
pre-translated markdown to compile to handlebars in the build so we can embed components in it
the handlebars need to support embedded translations (the {{t}} helpers)
the translations, both in markdown and handlebars need to use industry standard translation substitution mechanisms
it all needs to play well with code splitting to minimize experienced latency, especially on cheap phones
I wonder whether it is possible for a single piece of markdown text to contain both intl substitutions and handlebars substitutions unambiguously – three syntaxes nesting in the same space beg for trouble. Beyond that issue, assuming it all compiles down to what we have today, the logistical challenge in the plumbing is probably manageable: Markdown → Handlebar HTML with embedded translation substitutions, then strip all text into separate translation JSON accessed through generated{{t}} helpers with a hash for the parameters supplied via the handlebars. Handlebars then compile as usual.