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

i18n: allow requiring/validation of fields for non-default locale #5112

Open
rumack opened this issue Mar 14, 2021 · 0 comments
Open

i18n: allow requiring/validation of fields for non-default locale #5112

rumack opened this issue Mar 14, 2021 · 0 comments
Labels
area: i18n type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@rumack
Copy link

rumack commented Mar 14, 2021

I'm setting up a bilingual site (two locales) using Netlify CMS and the i18n feature. Things are working the way the documentation suggests they should but I'm trying to do something that doesn't seem to be possible for the moment - or at least I can't find the answer I'm looking for in the docs or in other issues raised here on GH.

I would like to be able to require a field for the second locale as well as for the default locale. As it stands, if the CMS user doesn't complete the translation fields, both files are saved (I'm using the multiple_folders setup), but the file for the second locale is just empty, except for the data fields that were set to i18n: duplicate.

I'd like a way to require certain fields for the second locale too.

Ideally what I'd like is that if the user doesn't fill in the fields for the second locale, then the fields are automatically duplicated from the primary locale fields, which will always be completed because they are required.

At the very least, if the user doesn't fill in the second locale, I'd like the generated file for the second locale to at least have the fields (keys) even if there's no data attached to them. Otherwise I have to incorporate a lot of extra logic into my application (parsing the files to check what data is or isn't present) which is possible of course, but I'd like to avoid it.

This seems like important functionality, so maybe I'm just completely missing something obvious and this is already possible?

Anyway, thanks to all the contributors for their work on netlify cms!

Edit: adding my very simple config.yml

backend:
  name: git-gateway
  branch: master

media_folder: static/assets/uploads
public_folder: assets/uploads

local_backend: true

slug:
  encoding: "ascii"
  clean_accents: true
  sanitize_replacement: "-"

i18n:
  structure: multiple_folders
  locales: [en, ga]
  default_locale: en

collections:
  # Blog collection
  - label: "Posts"
    name: "posts"
    folder: static/data/_posts
    slug: "{{slug}}"
    create: true
    i18n: true

    fields:
      - label: "Headline" 
        name: "title"
        widget: "string"
        pattern: ['^.{25,70}$', "Must have between 25 and 70 characters, ideally about 50!"]
        i18n: true

      - { label: "Subheading", name: "subheading", widget: "string", i18n: true }
      - { label: "Publish Date", name: "date", widget: "datetime", i18n: duplicate }
      - { label: "Body", name: "body", widget: "markdown", i18n: true }

Another edit:
Thought I was on to something there with CMS events and preSave, but I see that won't work either: #4729

In the end I just solved it on the application side which wasn't a terrible big deal. For a statically generated site you could just integrate it into the build process. My app isn't statically generated though so the parsing of the data happens upon every request to the api which is fine for this small app in development, but wouldn't be ideal for bigger applications with a lot of data I suppose.

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

No branches or pull requests

2 participants