What are the options for making a simple static we

2020-07-10 05:52发布

问题:

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?

回答1:

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.



回答2:

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.