plugin: i18n

[DirtyF]

11ty-plugin-i18n helps with content localization:

• languages avalaible
• translated content
• translated strings

🇬🇧 🇪🇸 🇨🇳 🇫🇷 🇯🇵 🇩🇪 🇧🇷 🇷🇺 🇵🇱 🇦🇷 🇮🇷 🇹🇷

[chrisdmacrae]

@DirtyF can you point me at the "best" or most widely adopted i18n implementation for Jekyll?

[DirtyF]

I don't know about the most widely adopted, but I know about the latest attempt is to handle locales: https://github.com/ashmaroli/jekyll-locale.

[Ryuno-Ki]

For a project I've used jekyll-multiple-languages-plugin, but it caused some issues with SEO topics. Namely sitemaps and alternate links.

[Ryuno-Ki]

Just ran into https://www.webstoemp.com/blog/multilingual-sites-eleventy/ today.

[reubenlillie]

I’ve been playing around with the suggestions in the link @Ryuno-Ki shared. And, at least as of this post, I have three concerns.

1. Perhaps because this solution is not in the official docs (yet?), it feels like a hack rather than a bona fide integration. If this is, in fact, a preferable solution, then when we put it in the docs, it should include examples in other template languages (JS specifically), not only nunjucks.
2. There does not appear to be a way, with this approach, to associate language-specific endpoints with each other in the directory structure (cf. Hugo example).
3. On a related note, is this solution compatible with CMSs (e.g., Netlfiy CMS) or translation software like OmegaT or Pontoon?

[jeromecoupe]

Hey there. I wrote this post so please allow me to respond here.

1. Not a hack IMHO. It only uses core Eleventy functionalities, mainly directory data files (so you don’t have to put the lgg specific info in each front-matter) and global data files (for string translations). The rest is just using the API for collections. That approach can easily work with other templating lgg (liquid or js) since it is only using simple loops to display data.
2. Both the Hugo articles you reference are just content and string translations using dictionnaries, which are covered in the post. If what you want is a per content item lgg switcher (get other lgg versions from a single item), the easiest approach is probably to rely on a key/value pair in front matter to give you something to work with. This is a standard approach with SSG. Documented here for Jekyll for example (transposable to 11ty) https://forestry.io/blog/creating-a-multilingual-blog-with-jekyll/ You can then query for that key / value pair in your templates, either using custom multilingual collections or by using the ‘getAll()´ method of the collection API to build a single collection of all your items
3. Yes, since the solution relies entirely on collections and data files, you can configure Netlify CMS, Forestry, etc to work with that, no problem.

Sorry I am on a phone so no code samples, but I’ll try to write a post about lgg switcher whenever I get some time.

For me, there is a big difference in philosophy between Hugo and 11ty.

• Hugo is a bit of a (many air quotes) closed solution / a single binary that covers a lot of use cases in one single package.
• 11ty is more of an (many air quotes) open solution / toolbox that gives you access to a lot of things, among which js and the whole NPM ecosystem

Neither approach is right or wrong, they both have their advantages and drawbacks. What you go with depends on the project at hand, as always.

[reubenlillie]

@jeromecoupe, of course. I don't really believe your solution is a hack. It's actually rather elegant. Sorry if I contributed any confusion or hard feelings. I was more addressing how it might feel that way to folks (particularly clients) who want i18n in the official docs and who may be looking for a way of associating translation files. Also, I respect the differences between 11ty and other SSGs, and I cherish 11ty's flexibility. By sharing examples from other SSGs, I'm just looking for inspiration by way of comparison. I fully expect 11ty's preferred i18n solution to be better than the competition.

[jeromecoupe]

@reubenlillie No hard feelings at all, man. Just wanted to clarify / expand on the blogpost.

As for clients, this is not usually a problem for me. They would very rarely look at docs and most of them only see an admin like Netlify CMS, Forestry, Strapi, Dato etc.

Very rarely does one of my client care about the fact that their data is in markdown or in a DB somewhere. The ones that do generally like markdown and are technical enough to manage multilingual collections or data files as long as the basic infrastructure is built. One of them even uses Github as a CMS ;o)

[reubenlillie]

Sure, some of my clients are devs whom I'm trying to reassure they truly want JAMstack solutions. (Like migrating from WordPress, in which case I have to sell i18n as you've presented it over WPML or something.)

[jeromecoupe]

To be honest I have vowed never to do a WP project ever again. Using Craft for such projects

[reubenlillie]

I’m in the process of converting a lot of old WP projects with clients now. The i18n issues I’ve mentioned are among the primary sticking points.

[Ryuno-Ki]

@jeromecoupe Hey, thanks for chiming in here!

Sorry for not having you tagged in #420 (comment).

Would you mind to link from your blog to here in case people are looking for an official way?

[Ryuno-Ki]

@reubenlillie Could you add a comment in #488?

I was wondering about starting an importer repo somewhen soon (using my Jekyll blog + my old WordPress.com blogs as starting points).

Will drop a link to the repo in that other ticket. Feedback welcome.

[reubenlillie]

@Ryuno-Ki, I could add a comment to the other issue thread, but I'm not sure what you'd like me to say.

[zachleat]

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open.

View the enhancement backlog here. Don’t forget to upvote the top comment with 👍!

[Snugug]

Can this get reopened?

[DirtyF]

@Snugug It's how this repo works: Closed by default, vote for the feature, and hope that it will get some attention from the community.

[sirinath]

Following metadata might be good to have in the font matters:

• if the post is the original
• translations of the post
• reference to the original language post in the translations
• additional translation metadata like the translator

Also, tag/taxonomy management will be crucial as the translation will have to display the appropriate tags/taxonomies for the post. Therefore there should be a way to add to the site data:

• tag-synonyms - there might be within the language tag-synonyms also
• language each tag-synonym is in.

Similarly, all collections and each item in the font matter will need to have a translated mapping, but not essential as this is not part of the user-facing part. If it is not translation there will need to be a way to inherit font matter content so there is a single point of truth. This might open possibilities of duplication and omission also.

E.g.

images:
  - ???.jpg
  - ….jpg
  - parrot.gif

will become

රූප:
  - ???.jpg
  - ….jpg
  - parrot.gif

In the Sinhala traslation.

So en-uk:images will need mapping si:රූප. So in pagination and other places if there is images it should become රූප when looking through the collections in the Sinhala template.

[sirinath]

How Middleman handles localization (i18n) seams interesting.

[adamduncan]

Hey all, we're putting together a multilingual Eleventy site at the moment, and also found ourselves needing some translation support. Having been motivated by some of the articles here, we've come up with: https://github.com/adamduncan/eleventy-plugin-i18n

Hope it comes in handy. Would love to hear any feedback you have 🚀

[zachleat]

Docs page: https://www.11ty.dev/docs/i18n/
Plugin page: https://www.11ty.dev/docs/plugins/i18n/ (2.0.0-canary.13)

I don’t think Eleventy will take an opinionated stance on a library to localize strings but we do link to a few options on those pages!