What are the options for making a simple static website multilingual?
Asked Answered
S

2

22

I'm setting up a static website which I want to display in two languages.

I can't find a comprehensive overview of the different options (e.g. server-side loading vs front-end loading vs using different folders. What are the advantages of each option (e.g. for SEO, maintainability, scalability etc.)?

Ideally the translations will be stored in separate json files. The main thing I care about is translation - less so the other aspects of i18n and l10n.

For example how might I translate:

<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <h1>Welcome</h1>
    <p>Here's a website</p>
    <p>Here's a <a href="https://www.google.com/">Link</a> to language specific Google</p>
    <button>Click here</button>
  </body>
</html>

Some of the many options I've encountered so far:

  • i18next - most standard option. support for loads of frameworks, but not clear which one is appropriate for most basic usage. i18nextify? jquery-i18next?
  • i18js - simple, but for rails?
  • i18n - most popular on npm, but has build status
  • i18n-2 - updated version of above

I feel like i18next is the most standard way to go, but is it suited to a simple site?

Storage answered 28/3, 2019 at 22:21 Comment(1)
use whatever suites your needs. I use node-polyglot i18n is nice, yes.Melodramatic
S
24

For anyone else looking around, I found an overview on this Reddit thread. I'll also explain the option I went with below.

To summarise the thread:

1) Front-End JS (e.g. jquery.i18n)

  • Generally fairly easy to implement
  • They can negatively impact SEO
  • Can increase page weight
  • Website doesn't work for people who don't run JS
  • Not recommended but ok for very small projects

2) Multiple Pages

  • This is easiest to setup, but maintenance becomes a nightmare. Not recommended

3) Server Side (e.g. node-i18n)

  • Because it avoid the disadvantages of front-end mentioned above, this is generally recommended for larger projects

4) Using a build tool like npm scripts or gulp (e.g. static-i18n)

  • Generates separate directories for each language using build scripts
  • Bit of initial set up but easy to maintain and extend
  • Since only static html pages are generated, html code can be safely embedded in the translation json files.

Solution

In the end I went with option 4 using static-i18n. While it took a bit of setting up, it works well for SEO, works for static sites, is easily maintainable, is scalable, and avoids the messiness of front-end dynamic language loading.

Storage answered 11/4, 2019 at 22:22 Comment(1)
Do you have any useful tips or links for language routing after static-i18n processing?Dragonhead
H
0

I don't think you need to bother with a library at all if all you are doing is text translation. All you need to do is write a simple function which switches between two (or more) json language files and a mechanism to display the right string from the selected json file.

Heehaw answered 28/3, 2019 at 22:38 Comment(2)
That's a limited solution. Works fine with js files, but what do you suggest for html files? Static pre-processors solves the problem better for those kind of tet translations. Not only for body content, but for metatags as well.Exiguous
"All you need to do is <describes hours of work that involves completely restructuring your website>"Spermatophyte

© 2022 - 2024 — McMap. All rights reserved.