I'm currently evaluating several headless CMS and so far payload-cms is my favorite.
But i'm having trouble adding localizations and keeping the structure of an existing localization.
I cloned the public demo.
- Adding a new page for
with Hero and Layout.
- Save as draft
- switching to
clears the layout and i have to build it from scratch.
Is there a simple way to keep the structure when switching to a different locale? (Do i have to use a hook or something?
Thanks in advance.
The nice thing about Payload's localization is that it can be applied at any level of your document structure. Since the blocks layout you're working in has localization: true, this is being set at the top in your project currently. It sounds like you would prefer to have the localization applied at the field level, inside your blocks instead of at the top.
Thanks for the response.
I got it working by removing
from the Page Layout. It might be a bit misleading for total newcomers trying out the demo.
But it is a great feature to be able to localize even the layout of documents.
I'm more than likely going to recommend going forward with using payload-cms in the project.
In the case where you localise on the field level wouldn't that mean, if you'd remove a block on the
version it would also be removed on the
I ran into the same thing and kinda figured keeping the localisation on the block field would be a better option. Do you think it would be tricky to implement a custom component to copy block structure from the original language?
This is up to your config @kariyngva . If you want the document to have the same blocks, you would not set
on the block field and instead put it on the fields within the blocks.
We have a task right now to improve our localization editing experience
I'd say this is a great point to make in the discussion on github to capture your pain paints.
Thanks, I'll add my 2 cents 🙂
I think this is related to this thread, but we're running into a related issue when migrating data from a different CMS. When we have a localized field nested within a block/array, we need to get the non-localized block/array structure complete with Payload generated block/array IDs and then fill in the translated details. I know this must be a payload core utility method somewhere, because it's effectively what the admin dashboard is doing when you switch locales (keeps the non-localized block structure/field values, zeros out the nested localized field values). @drojkind or anyone else, could you point me to where in core it does that so I can copy/import the functionality into my migration script?
@ssyberg. Since you're talking about importing and not export, I'm not sure I follow 100%.
The frontend requests the data in the locale from the selector and the backend returns it in the shape needed. It isn't a core function so much as that is how the API currently works.
You can look at the network requests to see this happening as you change the locale, the local API returns the same data shape and you should be able to use that in your scripts.
@dribbens thanks maybe I'm just thinking about this incorrectly, but here's the use case: we have a bunch of json objects that we are looping through and importing, we import English versions of a bunch of blog posts. Now we start importing Spanish translations, so I'm going to run an
on an existing record with existing English field values. I've found that with "scalar" fields, I can just do this update no problem, I don't need to query the local API first at all. But if I run the update with an object field like an array, since I don't have the payload generated ids in my data object, it just overwrites what is already there in the English version. I think what you're hinting at is correct though, I'll need to do a local API call on that record first with fallback locale false and that will give me the non-localized "structure" of the data object (with all the ids) without any of the localized values.
Yeah, fetching the document first would mimic how the admin UI is operating.
An alternative option you could consider would be to use the
directly instead of going through
and having to then call
. If you don't have many defaultValues, custom hooks that populate data dynamically, then this could be a better option. Populating with MongoDB directly would let you write the field values in the object structure for localized fields directly without having to make as many calls. It would be quite a lot of code though and depending on how complex your data is, might not save you any time. 🙂
@ssyberg Good luck!
Haha word, thanks Dan!