Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hugo's translationKey support for i18n paths #4645

Open
schindld opened this issue Nov 27, 2020 · 5 comments
Open

Hugo's translationKey support for i18n paths #4645

schindld opened this issue Nov 27, 2020 · 5 comments
Labels
area: i18n pinned type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@schindld
Copy link

Is your feature request related to a problem? Please describe.

I'm trying to find a way to get netlify-cms to understand French/English page pairs in different subfolders. I'm working with Hugo, and the way they handle translation of paths is to provide a translationKey frontmatter field that links two pages in differently named folders.

Given the following file structure:

src
├── content
│   ├── en
│   │   └── resources
│   │       └── index.md
│   └── fr
│       └── ressources
│           └── index.md

with frontmatter for the en one like:

---
title: Resources
slug: resources
date: 2020-10-30T14:33:09.744Z
translationKey: resources
---

vs the fr one:

---
title: Ressources
slug: ressources
date: 2020-10-30T14:33:09.744Z
translationKey: resources
---

and the following netlify-cms config.yml:

.
.
.
i18n:
  structure: multiple_folders
  locales: [en, fr]
collections:
  - name: 'page'
    label: 'page'
    folder: '/src/content'
    i18n: true
    create: true
    editor:
      preview: true
    nested:
      depth: 100 # max depth to show in the collection tree
      summary: '{{title}}' # optional summary for a tree node, defaults to the inferred title field
    fields:
      - { label: 'Title', name: 'title', i18n: true, widget: 'string' }
      - { label: 'Path', name: 'slug', i18n: true, widget: 'string', required: false }
      - { label: 'Meta description', name: 'description', required: false, i18n: true, widget: 'string' }
      - { label: 'Publish Date', name: 'date', i18n: true, widget: 'datetime' }
      - { label: 'Translation key', name: 'translationKey', required: false, i18n: true, widget: 'hidden', default: '{{slug}}' }
      - { label: 'Body', name: 'body', i18n: true, widget: 'markdown' }

Netlify-cms sees them as unrelated pages:
image
and
image

Likewise when creating content. I fill out the English and French sides of the editor, adding different path values, and get pages with this kind of frontmatter:

src/content/en/covid-19.md

---
title: Covid-19
slug: covid
description: ""
date: 2020-11-27T14:44:25.843Z
translationKey: "{{slug}}"
---

and
src/content/en/covid-19.md

---
title: Covid-19
slug: covid
date: 2020-11-27T14:44:25.859Z
translationKey: "{{slug}}"
---

(not sure why description doesn't show up in the French file, but that's another issue).

The {{slug}} part isn't being resolved as expected. I'd expect to see covid there.

Describe the solution you'd like

I'd like to see 2 things:

  1. The collections browser should use frontmatter like translationKey (for Hugo; not sure what equivalents are for other frameworks) to match translated files.
  2. The widgets like string and hidden should support parsing template tags like {{slug}}.
@schindld schindld added the type: feature code contributing to the implementation of a feature and/or user facing functionality label Nov 27, 2020
@martinjagodic
Copy link
Member

martinjagodic commented Dec 1, 2020

Could the solution to this be another structure option? It seems that language folders were not intended to be nested. I would love to see a solution for this because right now the only option with Hugo is structure: multiple_files, which is not my favorite.

I would use it something like this:

...
i18n:
  structure: hugo # or something
  locales: [en, fr]
collections:
  - name: 'resources'
    label: 'Resources'
    folder: 'content/{{locale}}/resources' # or something
    i18n: true
    create: true
    # I removed nested here
    fields:
      - { label: 'Title', name: 'title', i18n: true, widget: 'string' }
      - ...

Content structure

content
 ├── en
 │   └── resources
 │       ├── _index.md
 │       └── post.md
 └── fr
     └── resources
         ├── _index.md
         └── post.md

@erezrokah I hope this is possible

@schindld
Copy link
Author

schindld commented Dec 7, 2020

For the time being, I reverted to a flat file system, but would still like a solution for i18n paths.

@haroldao
Copy link

haroldao commented Mar 13, 2021

Could the solution to this be another structure option? It seems that language folders were not intended to be nested. I would love to see a solution for this because right now the only option with Hugo is structure: multiple_files, which is not my favorite.

I would use it something like this:

...
i18n:
  structure: hugo # or something
  locales: [en, fr]
collections:
  - name: 'resources'
    label: 'Resources'
    folder: 'content/{{locale}}/resources' # or something
    i18n: true
    create: true
    # I removed nested here
    fields:
      - { label: 'Title', name: 'title', i18n: true, widget: 'string' }
      - ...

Content structure

content
 ├── en
 │   └── resources
 │       ├── _index.md
 │       └── post.md
 └── fr
     └── resources
         ├── _index.md
         └── post.md

@erezrokah I hope this is possible

You can just write multiple_folders or multiple_files or single_file on "structure"... Something else will return an error...🤗

@martinjagodic
Copy link
Member

@haroldao I know, it's a proposal of what could be possible :)

@haroldao
Copy link

@haroldao I know, it's a proposal of what could be possible :)

Okay😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: i18n pinned type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

No branches or pull requests

4 participants