Copy document structure for localizations

default discord avatar
woellijlast year
11

Hi there.


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

en

with Hero and Layout.


- Save as draft


- switching to

de

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.

  • discord user avatar
    dribbens
    last year

    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.

  • default discord avatar
    woellijlast year

    Thanks for the response.



    I got it working by removing

    localized: true

    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.

  • default discord avatar
    kariyngvalast year

    Hey @dribbens


    In the case where you localise on the field level wouldn't that mean, if you'd remove a block on the

    de

    version it would also be removed on the

    en

    version?



    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?

  • discord user avatar
    dribbens
    last year

    This is up to your config @kariyngva . If you want the document to have the same blocks, you would not set

    localized: true

    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.



    https://github.com/payloadcms/payload/discussions/1234
  • default discord avatar
    kariyngvalast year

    Thanks, I'll add my 2 cents 🙂

  • discord user avatar
    dribbens
    last year

    Thanks!

  • default discord avatar
    ssyberg11 months ago

    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?

  • discord user avatar
    dribbens
    11 months ago

    @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.

  • default discord avatar
    ssyberg11 months ago

    @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

    update

    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.

  • discord user avatar
    dribbens
    11 months ago

    Yeah, fetching the document first would mimic how the admin UI is operating.


    An alternative option you could consider would be to use the

    payload.collections[slug].Model

    directly instead of going through

    payload.create()

    and having to then call

    payload.update()

    . 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!

  • default discord avatar
    ssyberg11 months ago

    Haha word, thanks Dan!

Star on GitHub

Star

Chat on Discord

Discord

online

Can't find what you're looking for?

Get help straight from the Payload team with an Enterprise License.