Feat: multi content authoring

[barthc]

Summary
Closes #716

Based on the issue and comments, introduced new config options, a top-level languages option

languages
 - en
 - fr

and translate: true widget option. The fix here is to wrap the field inside an object widget, generating fields for each of the supported languages. For example, a folder collection fields like so:

- {label: 'Slug', name: 'slug', widget: 'string', translate: true}

would be transformed to:

 - label: 'Slug'
   name: 'slug'
   widget: 'object'
   fields:
      - {label: 'EN', name: 'en', widget: 'string'}
      - {label: 'FR', name: 'fr', widget: 'string'}

Editor UI:

Data should be saved like so:

slug:
  en: a-night-not-like-the-others
  fr: une-nuit-pas-comme-les-autres

Note that the identifier field and the markdown body widget are excluded from the translation.

[erquhart]

Thanks for digging into this @barthc! I don't think we're ready to implement a fix as we still need to determine the right approach from a UX perspective. There's also a lot of ongoing discussion about how this feature should look, and we want to get a feeling of consensus in that form before doubling down on a direction.

In lieu of this PR (for now), would you mind outline the approach you're recommending in that issue and allow some time for feedback from others?

[rchrdnsh]

I personally love the idea of grouping language by content, rather than content by language, as this PR is advocating for.

Me and my creators all seem to much prefer:

title:
  en: Hello
  fr: Bonjour

...over:

en:
  title: Hello
fr:
  title: Bonjour

...as it properly prioritizes the content over the language.

The most important thing, however, is that the languages need to be visible at the same time, or else translation, is, you know, impossible. I'm not sure if there should be a limit to the number of languages available, or if a dropdown for each added language would also be useful, or something along those lines, but I suppose it's not too difficult to follow along with this:

title:
  en: Hello
  fr: Bonjour
  es: Hola
  ru: Здравствуйте
  ch: 你好

...and maybe in the UI the author can select how many and which languages are visible under that particular content field.

But, to re-iterate, I am definitely casting my vote in favor of the approach outlined in this PR :-)

[Arno500]

• As said in Support for multilingual content authoring #716, (more specifically here Support for multilingual content authoring #716 (comment)), having a menu with a selection of languages when editing could be the best solution. You can select for instance your main language, then 2 or 3 more you can translate. This way, you prevent the issue of having million of fields, multiplied by the number of single-language fields.
• It may needs to be integrated to the API for custom widgets
• And a way in the config to specify how the files should be generated: by adding a "_lng" to the end of the file, or placing them in subfolders for example.

But definitely a good start for an issue staling for way too long! Thanks @barthc

[oskarrough]

Thanks for starting this! Two thoughts.

1. As inspiration, Hugo's multilingual mode groups by language first, then field.

en:
  title: Hello
fr:
  title: Bonjour

2. As much as I enjoy the simplicity of having a single markdown file with multiple languages, like @barthc's first example, isn't it more likely that your static site generator of choise relies on a folder for each language with each markdown/content file duplicated?

en/my-post.md
fr/my-post.md

[erezrokah]

I think there are two main distinctions:

1. How the CMS displays multi-language content (e.g. single page with buttons vs language selector, etc).
2. How the CMS persists multi-language content (same file vs different folders).

We have flexibility around 1, but probably would like to have 2 as the default way most static site generators handle multi-language content.

If anyone has any knowledge in area number 2 feel free to add that to the issue.

[erquhart]

Precisely - we have to work the way static site generators work. What I know at the moment:

• Hugo has solid built in support and I believe they require separate files for translations
• Many don't have built in support (Jekyll, Gatsby), so we need to align with plugins and best practices - as far as I can tell, the content approach is similar to Hugo, separate files

@barthc I'm going to say a feature of this size should have a lot of agreement and details nailed down before a PR is opened - this is in everyone's best interest, including yours, as I never want to waste your time! This is likely the next feature to get our full attention after editorial workflow for gitlab/bitbucket is complete, so let's focus on planning in #716 and get this feature specced out so we can come back with a rock solid delivery.

[chiefjester]

@erquhart, Firstly, thank you for this project which enabled a lot of people trying out the JAMStack way of doing things. But I hope you hear me out and don't come across something negative. I come in peace ✌🏻.

I don't want to be that guy, but getting 100% consensus on something is an impossible feat even with a standards body that netlify-cms doesn't have. The PR was based on suggestions on #716 which is 3 years old discussion. How much of a discussion do you want? 🤔. I hope it won't take another 3 years 🤞🏻. More power to this project 🙌🏻

[erquhart]

I hear you @thisguychris , definitely been way too long. This is a top priority, stay tuned.

_{Sent with GitHawk}

[jmdrawneek]

@erquhart Is there anything me or my team could do on this? We've got a project we'd love to use Netlify but multilingual is a blocker. We actually planned on building joallard solution (or at least something very similar) so could always build it and contribute it back?

[erquhart]

@jmdrawneek if you and your team are interested in implementing, @erezrokah and I would be happy to support the effort. As you mentioned, @joallard laid out a solid plan to go from with multiple phases, so the MVP path is already pretty clear. I'd encourage communication so we're all on the same page - happy to open a project specific channel in the community slack for this if you like, let me know what you're thinking.

[barthc]

Sorry guys, I hope you guys don't mind. I would be taking anothor shot at this based on the recent feedback, cheers.

[erezrokah]

@barthc, do you think we can split up the work?
I can see two main efforts here:

1. Having the backends support persisting multiple content files (e.g. saving both post.en.md and post.fr.md under the same entry). This should actually be configured - multiple files vs multiple fields in a single file, and defaults to the most common approach of static site generators.
2. Adding a side by side translation editor UI per Support for multilingual content authoring #716 (comment).

[barthc]

@erezrokah yes, that is how it would work.

[erezrokah]

@jmdrawneek, @barthc, @erquhart I'm moving this discussion to the issue.