Outputting all other localizations/locales of a collection in the REST API

AlessioGr

2 years ago

1 1

• Selected Answer
  

  jmikrut

  2 years ago

  Hey @AlessioGr — more good news!

  This is currently possible. 😎

  You can use the query parameter locale=* and all locales will be returned for any given doc through the REST API. Note that this is only possible in REST or Local APIs though, due to how GraphQL data is strictly typed.

  Give it a shot!

  6 replies
• 

  AlessioGr

  last year

  Hey @AlessioGr — more good news!

  This is currently possible. 😎

  You can use the query parameter locale=* and all locales will be returned for any given doc through the REST API. Note that this is only possible in REST or Local APIs though, due to how GraphQL data is strictly typed.

  Give it a shot!

  Thank you!! I tried it out, and it does display all languages, but it doesn't quite do what I want it to do. The biggest issue is that it changes a lot of my REST API schema, so I would need to parse it completely differently. Example:

  "title":{
              "en-SG":"Thrustmaster TMX Review",
              "de-DE":"Thrustmaster TMX Review DE"
  },

  versus just

  "title": "Thrustmaster TMX Review"

  Instead, I want it to JUST display one language and then display all other possible languages as a separate object - without the content. I used to have an object like this (not containing any content):
  

  Is that possible? Otherwise, I would have these huge Rest API responses for just one language page containing the content of all other languages, even though I basically just need the "links" to the other languages, not just the content.

• 

  jmikrut

  last year

  Ah ok. I see what you're saying.

  What we've seen done in similar situations is to maintain an activeLocales field or similar, maybe positioned in the sidebar of the doc, that allows for you to "enable" locales for any given document. Then once you have translated a doc, you would simply add that locale to the list of activeLocales and then boom. You're done.

  Would a setup like that work?

• 

  AlessioGr

  last year

  activeLocales

  Optimally it should be automated and based on if the translation is published or just drafted, but for now, that would work! What kind of field type would work best there? I've tried a hasMany relation, but I cannot select every single locale in it.

• 

  jmikrut

  last year

  Well, do you have a locales collection? That would be the only time you'd want to use a hasMany relationship field - to relate to a locales collection. But typically locales are hardcoded (or shared) in your config and so here I'd just use a select field with hasMany: true, where the options are equal to all of your config's available locales.

  You could also prefill / auto-update this field with hooks, too!

• 

  AlessioGr

  last year

  Well, do you have a locales collection? That would be the only time you'd want to use a hasMany relationship field - to relate to a locales collection. But typically locales are hardcoded (or shared) in your config and so here I'd just use a select field with hasMany: true, where the options are equal to all of your config's available locales.

  You could also prefill / auto-update this field with hooks, too!

  The select field works! And yep, locales are hard-coded, so I just copy and pasted them. Good idea with the hook, I'll try autofilling them based on the information of the local api and then making them read-only.

  Or alternatively, is it possible to directly extend on what the REST API outputs via a plugin? That might be an even more elegant solution which does everything behind my back.

• 

  DanRibbens

  last year

  I don't think you wjould need to extend the REST API other than with the field you're describing. Consider setting admin.hidden to true to keep it out of the admin UI.

  It could be made in to a plugin once it's all working. It sounds pretty useful.