search

decaporg / decap-cms

A Git-based CMS for Static Site Generators
https://decapcms.org
MIT License
17.77k stars 3.03k forks source link

Internationalization of the CMS #1166

Closed hdoro closed 6 years ago

hdoro commented 6 years ago

- Do you want to request a feature or report a bug? Request - adding internationalization behaviors to the CMS

- What is the current behavior? Devs must duplicate collections/files in order to provide multilingual support for the content and the CMS itself is a bit of a pain to translate.

- What is the expected behavior? For the admin: The interface translates itself automagically through i18n Javascript objects and the browser's language. It'd work quite similar to SnipCart's Localization API For the content: Devs can specify when files/folders have multiple languages in the config.yml, and the CMS generates the other language files based on the configured file extension (ex: .es.md for Hugo's), giving the users contextual editing through tabbed inputs for each language.

I find it hard to explain what I mean by the previous phrase by text, so here goes a screenshot: image

Also, I've dived deeper into the reasons behind each choice as well as gave my take on this based on my experience in this YouTube video! Any doubts let me know 😄

erquhart commented 6 years ago

Love the UI concept here @hcavalieri!

Regarding the UI itself, we have the same kind of setup described by Snipcart in a PR that's very close to ready: https://github.com/netlify/netlify-cms/pull/974

For the i18n field concept, individual widgets would probably have to opt in and handle their own UI, but we could maybe provide a default component like the one in your screengrab.

Benaiah commented 6 years ago

Content i18n that's based on separate files should probably wrap the tab container around the entire editor view instead of a specific widget, unless we want to ensure that all other fields remain the same in both (in which case, what do we do if they diverge?). The UI in the screenshot seems to correspond more closely with an internationalization scheme that uses different keys on the same object - and, if that approach were used, should be feasible to implement using the current widget API. The most difficult aspect of that approach would probably be making your SSG understand the content, as it would need to be structured data instead of a typical markdown-with-frontmatter format.

erquhart commented 6 years ago

@Benaiah nice, building this into the editor at large makes a lot of sense. I'd say this moves away from the dog-ear approach, but some kind of button group to switch between languages makes sense. I'd rather not see a dropdown since validation will need to occur across all languages, e.g. required fields, to ensure an entry is complete for all. We'll want max visibility for that.

erquhart commented 6 years ago

Closing in favor of #716, forgot about that one.

@hcavalieri please chime in on that issue, let's keep this moving!