Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Templates i18n #60

Open
UltCombo opened this issue Apr 19, 2015 · 0 comments
Open

Templates i18n #60

UltCombo opened this issue Apr 19, 2015 · 0 comments

Comments

@UltCombo
Copy link
Member

If you open the Portuguese version of JS Rocks, you will see the templates' strings are hardcoded in English. The same is true for all other languages (e.g. Chinese).

What's the best approach for internationalizing the templates? Should we do it in the front-end, or have i18n support built-in in Harmonic's theme processing?

Doing it in the front-end may affect SEO negatively, I'm not sure. It also gives the user more work to choose and apply an i18n approach.

Having i18n built-in in Harmonic's core doesn't give the user as much flexibility, though.

Perhaps we should make a Harmonic plugin for i18n? That way, normal users can just install it and set up some .json files corresponding to template string translations, and if that is not enough for their use case, they can use or develop a more advanced plugin.

In the other hand, themes would be tightly coupled with i18n, meaning that for plugins to work out of the box, the currently selected theme would have to specify a plugin dependency and provide its configuration. This seems way more complex than necessary.

Perhaps, then, it would be better to ship with built-in i18n support, using e.g. (untested) nunjucks-i18n, then the theme's config.json may provide a translations key:

{
  "translations": {
    "en": {
      "foo": "bar"
    },
    "bleemer": {
      "binner": "glimmer"
    }
  }
}

IIRC, the config is already fed to the nunjucks templates, so theme developers would just have to make use of the i18n filters.

The more advanced use cases can still rely on custom plugins.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant