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

First-party multilingual support for Keystatic #1080

Open
simonswiss opened this issue Apr 18, 2024 · 4 comments
Open

First-party multilingual support for Keystatic #1080

simonswiss opened this issue Apr 18, 2024 · 4 comments
Labels
enhancement New feature or request roadmap Something we're planning to solve

Comments

@simonswiss
Copy link
Collaborator

There are a lot of requests for a first-party support for multi-language sites with Keystatic.

Particularly when used with Astro, which supports i18n out of the box.

I think there is enough interest/demand to consider investigating a proper multi-language support solution for Keystatic, if time allows 😇

@zanhk
Copy link

zanhk commented Apr 19, 2024

I think the implementation in Decap CMS is quite clear (https://decapcms.org/docs/i18n). An additional "copy" feature would also be helpful (sveltia/sveltia-cms#120).

For the UI, I believe a simple select option would probably work best, without the need for side-by-side editing.

For validation, perhaps if there is an error in a language other than the one I am viewing, when I save, it could switch to the language with the validation error and scroll to the problematic field.

@filipesmedeiros
Copy link

In my case, the most important part of this integration is just the authoring experience. I would love to not have the language part of the slug in the list, and of course not have duplicates in that list, but instead have them in the same "page" (with a way to switch between languages like @zanhk suggested).

Of course other people will have other needs!

@zanhk
Copy link

zanhk commented Jun 8, 2024

Is there any news on this feature?

@louisescher
Copy link
Contributor

It could also be useful to en-/disable i18n on a per-collection/singleton basis, since there might be cases where only certain pages need translation.

Another thing that might be worth mentioning are localized images. From working with Hygraph I've come to like the option of providing two versions per image. This could, of course, also be disabled per image!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request roadmap Something we're planning to solve
Projects
None yet
Development

No branches or pull requests

4 participants