Multilingual solution based on data language files

[fdeneux]

Hello, first of all great work on panini!

I'm looking for a specific multilingual solution, where you have a single multilingual structure (page) that is compiled to language specific html files for every language file in data.

Example:

root
│
│───src/
│   │
│   │───data/
│   │   |───en.yml
│   │   |───es.yml
│   │   └───fr.yml
│   │
│   │───layouts/
│   │   └───default.hbs
│   │
│   └───pages/
│       └───index.hbs
│
└───dist/
    │───index-en.html
    │───index-es.html
    └───index-fr.html

This can be achieved with the combination of gulp-swig and gulp-data, but I'd like to know if such a solution is possible with panini as I really like the generator.

An even better solution is to compile to a folder for every language:

root
│
│───src/
│   │
│   │───data/
│   │   |───en.yml
│   │   |───es.yml
│   │   └───fr.yml
│   │
│   │───layouts/
│   │   └───default.hbs
│   │
│   └───pages/
│       └───index.hbs
│
└───dist/
    │
    │───en/
    │   └───index.html
    │
    │───es/
    │   └───index.html
    │
    └───fr/
        └───index.html

Another interesting solution is to have a structured languages data subfolder, that would allow you to split your data files.

root
│
│───src/
│   │
│   │───data/
│   │   │
│   │   └───languages/
│   │       │
│   │       │───en/
│   │       │   │───info.yml
│   │       │   └───item-list.yml
│   │       │
│   │       │───es/
│   │       │   │───info.yml
│   │       │   └───item-list.yml
│   │       │
│   │       └───fr/
│   │           │───info.yml
│   │           └───item-list.yml
│   │
│   │───layouts/
│   │   └───default.hbs
│   │
│   └───pages/
│       └───index.hbs
│
└───dist/
    │
    │───en/
    │   └───index.html
    │
    │───es/
    │   └───index.html
    │
    └───fr/
        └───index.html

[fredericpfisterer]

I would love to read an answer about this. I have a site to make in two languages and I don't know how to do it with panini.

[giofilo]

Me too. My company sends newsletter (I use foundation for emails) to 8 different countries. Would be awesome to have a solution!

[XmlmXmlmX]

That would be awesome! Actually we do it like that (out of the box):

root
│
│───src/
│   │
│   │───layouts/
│   │   └───default.html
│   │
│   │───pages/
│   │  │───Foo.Bar.en-GB.html
│   │  │───Foo.Bar.de-DE.html
│   │  └───Foo.Bar.html
│   │
│   └───partials/
│       │───Footer.html
│       │───Foo.Bar.html
│       └───Header.html
│
└───dist/
    │───Foo.Bar.en-GB.html
    │───Foo.Bar.de-DE.html
    └───Foo.Bar.html

Each page contains localization inside the front matter block.

Downside: For common partials like footer or header, all translations are duplicated.

After compiling we have a batch script wich generates npm packages for each template namespace to use it in our services.

[XmlmXmlmX]

Nothing new here?

[fdeneux]

@XmlmXmlmX I ended up mirroring the project on GitLab and tweak it to my needs on a custom branch.

[XmlmXmlmX]

@fdeneux can you share your work or make a PR here?

[shaneog]

@XmlmXmlmX Looks like @fdeneux's work is here.

I'm in need of a similar solution, but I haven't tried this fork yet.

[XmlmXmlmX]

Hey, I have published my solution in a gist here. It's a bit more complex, because the requirements are very high (currently 12 pages * 31 languages = 372 different emails).

Hopefully this enhancement will be integrated sometime.

@gakimball Is it worth to make a pull-request?

[gakimball]

@XmlmXmlmX This looks great! Let's talk a little about how we can simplify it. In general I want to give people one way to do things. Here are a few ideas and questions.

Helper

For the #i18n helper, we could use an inline helper instead of a block helper. Makes it a little faster to write.

{{#i18n 'path.to.key'}}

Locale Strings

For file structure, I think we should enforce one method of organizing and one style of writing file names. A basic structure might look like this (taking inspiration from other i18n libraries I've used):

- src/
  - locales/
    - en.json
    - pl.json

That being said, some folks will mostly likely have too many translation strings to reasonably fit in one file, so an alternative way would be:

- src/
  - locales/
    - en/
      - home.json
      - about.json

Now, that is perhaps giving people two ways to do things, but the hierarchy is the same.

If a locale is a single file, accessing it involves writing the object path to the key. If a locale is multiple files, it's still an object path, but the first key is the name of the file.

Notably, this doesn't enforce any particular style of organizing translation strings. If you want to go by page, you can do that, or if you want to keep things in one place, you can do that as well.

This does differ from your approach in that it doesn't automatically load a set of translation strings based on the page. With this approach, you'd have to specify the page each time, like so:

<h1>{{#i18n 'home.title'}}</h1>
<p>{{#i18n 'home.subtitle'}}</p>

This would make mixing global and page-specific strings easier, however. It also matches the way data files are loaded: one file = one object with name of file.

Thoughts on this approach?

[gakimball]

Hey! I've implemented the basics of this in 8b2d617. Here's what the input/output looks like:

[gakimball]

Closing this as the basics of i18n are in place. If people have more ideas we can definitely talk about them :)