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 files with a subset of translations #6932

Open
JMLFP opened this issue Oct 8, 2023 · 2 comments
Open

i18n: Allow files with a subset of translations #6932

JMLFP opened this issue Oct 8, 2023 · 2 comments
Labels
area: i18n pinned type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@JMLFP
Copy link

JMLFP commented Oct 8, 2023

Issue

Right now the i18n support in Decap will create a file for every enabled locale even if no data was entered for this locale. This can be undesirable when the user would like to fallback to the default locale if content is not available in the user locale (or if translation will be done later). You can see the effects of this issue mentioned here: #4480 (comment).

Example: if the user creates a new page and enters the content in the default locale (en), but leaves one of the other locales blank (es) the CMS will still commit a new-page.en.md and new-page.es.md. This means that new-page.es.md may show up on index pages and as a linked translation even though it's a blank file with just header data.

Proposed Solution

I suggest that we add a boolean configuration flag that would require manually enabling a translation. It would default to true to keep the existing behavior and keep backwards compatibility.

# config.yml
i18n:
  save_all_locales_by_default: false

This config flag could trigger an updated UI element that would require the content editor to enable a translation. If the translation is enabled, the translated file will be saved. If not, no translated file will be created:

image

Other Solutions

I have also thought about discarding the translation if certain fields are empty (for example, no body) - but this seems more likely to break workflows. Thoughts?

Final Thoughts

I am interested in cooperating on a PR to help implement a feature to resolve this issue, but I would appreciate some feedback on the architecture before I begin writing code :-)

@JMLFP JMLFP added the type: feature code contributing to the implementation of a feature and/or user facing functionality label Oct 8, 2023
@martinjagodic
Copy link
Member

@JMLFP I like this idea. If you are willing to contribute a PR, that would be great.

I would rename the flag to save_all_locales. It's shorter and explains about the same. Like you said, default valuse is true to keep the current behavior.

i18n:
  save_all_locales: false # default is true

I am not sure what to do with the new UI element. We are talking about whether an MD file exists or not. That means that setting it to false should delete the file, which will delete all content. That should be very obvious to the user.

One option would be to set it to false for all locales when starting a new entry. When the user enters one i18n: true field, it switches to true automatically.

If the user sets it to false on a non-empty entry, we should display a warning that this will delete the file and therefore all i18n: true fields.

When enabling a translation back again, we have to be careful to include all i18n: duplicate from the default locale.

@JMLFP
Copy link
Author

JMLFP commented Dec 4, 2023

One option would be to set it to false for all locales when starting a new entry. When the user enters one i18n: true field, it switches to true automatically.

That's a good thought - that way the user doesn't need to do any extra steps and we don't need to clutter the UI with another option.

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

2 participants