Translated content

bensler

3 months ago

12

• 

  alessiogr

  Payload Team

  3 months ago

  That'd be localization! i18n is for the admin panel, localization is for the actual content

  
  

  
  

  Check out

  https://payloadcms.com/docs/configuration/localization
• 

  p6l.richard

  2 months ago

  @alessiogr is there a possibility to declare localization keys that are the same for all locales?

  
  
  

  We're translating out keys by upload .json files of them to some translation service and it would be great if users can define the English content for the key for a field but then we can translate later.

  
  

  
  

  Or more in general, how does localization of content work? I know I can query for

  locale

  but for this button (for which I've set

  localized = true

  ), I don't see any possibility for me to translate the label. 🤔

  
• 

  alessiogr

  Payload Team

  2 months ago

  Ah.

  localized: true

  only translates the content - NOT the label.

  
  
  

  For the label you can use

  
  
  

  label: {
          en: 'English Label',
          de: 'German Label',
  },

  
  

  (which is part of i18n, not localization)

  
  

  
  

  The label is only displayed in the Admin UI. It's not part of the content

• 

  p6l.richard

  2 months ago

  sorry, the field

  Button Label

  is a text block -- i want to translate that. bad example as button label is a bit confusing here.

  
  
  

  But I do want to translate the content -- just don't see any option how to do that

  
  

  
  

  
  

  
  

  i don't care much about i18n of the admin ui -- only interested in the content translation.

  
  

  
  

  Ah, I've found the

  en

  in the left sidebar (over my profile avatar)

  
  

  
  

  Ok, this made it work for me (along with providing the i18n config for the nextjs app).

  
  

  
  

  @alessiogr I would still be interested if it's possible for me to define translation keys for fields though?

  
  
  

  That would enable sharing common translations. It looks like my current only option is to pull the entire components out of payload and instead add them in the nextjs page directly -- that would make it impossible to include a commonly used CTA somewhere between payload blocks though.

  
  
  https://media.discordapp.net/attachments/1122900348185628732/1126152308112236714/CleanShot_2023-07-05_at_16.04.472x.png?width=1522&height=1045

  
• 

  alessiogr

  Payload Team

  2 months ago

  Mh I'm trying to understand your use-case here. So you know that you can add the localizations directly in the admin panel, right? Select the language in the sidebar, and then just enter the translation.

  
  
  

  Now, it sounds like you want some kind of placeholder here. So instead of writing the translation, you would write something like {button_label_en} which you can re-use in different components, right?

  
  

  Or, alternatively, do you just want the default value to use a pre-defined translation?

• 

  p6l.richard

  2 months ago

  Okay, let me try to explain my use case.

  
  
  

  We have 1000s of buttons across our web page. Some of them with content that we re-use a lot. something like

  Sign up today

  for example shows on our homepage, our blog, ... in a lot of places.

  
  
  

  We have this

  Sign up today

  string translated into multiple languages (>20).

  
  
  

  If someone in Marketing tomorrow decides that the string should be

  Sign up

  instead of

  Sign up today

  , they would need to update this translation in our translation service but also log in to payload to update this.

  
  
  

  However, they might not even have access to payload, so I'd love to be able to provide payload with my translation keys & translations to interpolate these variables if necessary.

  
  
  
  

  Does that make sense?

• 

  alessiogr

  Payload Team

  2 months ago

  Yepp, that totally makes sense! In this case, something like a placeholder system could work well for you.

  
  
  

  Basically, say you have a translation string called

  {button_label_en}

  that you would enter that in the payload button.

  
  
  

  Now, you just need to resolve this into the actual translation, based on the translation keys you want to provide. I see 2 ways to do that:

  
  
  

  1) use an afterRead hook. You can attach an afterRead hook to that button, which reads the text, and if it contains a translation key (e.g. {button_label_en}), it replaces it with one of your translation keys. Regex would work well with that. That way, every time you read the document with that button, the button text will contain your updated translation.

  
  
  

  2) the other way would be to replace that {button_label_en} placeholder with the translation key right in your frontend, e.g. in getServersideprops in next.js.

  
  
  

  The afterRead hook would probably be the cleanest solution for you

• 

  p6l.richard

  2 months ago

  1) and if it contains a translation key (e.g. {button_label_en}), it replaces it with one of your translation keys.
  

  That sounds interesting. I'm reading in the docs that the

  afterRead

  hook flattens locales -- does that mean I can have access to fields that are marked as

  localized = true

  in there?

  
  
  

  I'd need to provide this hook with my translation files, would need to see how I can make that work.

  
  
  

  (i assume that I can access the

  locale

  query parameter of the express request via the

  req

  )

  
  

  However,

• 

  alessiogr

  Payload Team

  2 months ago

  That sounds interesting. I'm reading in the docs that the afterRead hook flattens locales -- does that mean I can have access to fields that are marked as localized = true in there?
  

  Yep! I think it automatically just gives you the locale in the afterRead hook which was requested, so you wouldn't even have to worry about that.

• 

  p6l.richard

  2 months ago

  2) the other way would be to replace that {button_label_en} placeholder with the translation key right in your frontend, e.g. in getServersideprops in next.js.
  

  That's possibly more convenient for me since that's how our i18n package works (next-i18next).

  
  
  

  I could create a function to wrap every getStaticProps function (our site is mostly static) to fetch the payload data & resolve the translations.

• 

  alessiogr

  Payload Team

  2 months ago

  (i assume that I can access the locale query parameter of the express request via the req)
  

  I think so, yep!

  
  
  

  I'd need to provide this hook with my translation files, would need to see how I can make that work.
  

  You're free to do it the way which works best for you. You can put the localization file on the server and read it in the hook / on init, or alternatively make a network request and read it there. Gives you full flexibility 🙂

  
  
  

  That's possibly more convenient for me since that's how our i18n package works (next-i18next).
  
  I could create a function to wrap every getStaticProps function (our site is mostly static) to fetch the payload data & resolve the translations.
  

  Sure, that'd be an easy solution! It would be annoying if you had multiple frontends, e.g. a next.js website, and then maybe a mobile App. If you move that logic to payload, you wouldn't have to worry about resolving it in your frontend. Also should be pretty trivial to resolve the translation and replace it accordingly.

  
  
  

  Probably doesn't matter too much if you just have one frontend reading from payload, though.

• 

  p6l.richard

  2 months ago

  That sounds interesting. I'm reading in the docs that the afterRead hook flattens locales -- does that mean I can have access to fields that are marked as localized = true in there?
  

  
  

  > Yep! I think it automatically just gives you the locale in the afterRead hook which was requested, so you wouldn't even have to worry about that.
  

  
  

  I'm not really looking for the locale. Would just be great to filter for all fields that have localized enabled.