Copy document structure for localizations

woellijlast year

11

• 

  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.

• 

  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.

• 

  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?

• 

  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
• 

  kariyngvalast year

  Thanks, I'll add my 2 cents 🙂

• 

  dribbens

  last year

  Thanks!

• 

  ssyberglast year

  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?

• 

  dribbens

  last year

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

• 

  ssyberglast year

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

• 

  dribbens

  last year

  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!

• 

  ssyberglast year

  Haha word, thanks Dan!