Localized blocks look correct in Visual Editor, show as [object Object] when published

Technical Questions
1

I’m trying to add some block level localization of text. I’ve added locale as a custom targeting attribute. I’ve integrated the locale into both my BuilderComponent definition, and recently added it as a userAttribute to my getServerSideProps builder.get call. The localized text looks great in the Visual Editor but as soon as I publish my page, no matter what my browser locale is set to (I’ve tried en-US, en-AU and en-NZ explicitly), it shows the localized text areas as [object Object].

My BuilderComponent looks like this:

<BuilderComponent
        model={model}
        content={content}
        renderLink={renderLink}
        locale={locale}
      />

getServerSideProps looks like this:

const serverSide = serverSideService.fromGetServerSideProps(context);
  const { locale } = context;
  const utmContent = serverSide.getQueryParam('utm_content');
const landingPage = await builder.get(pageModelKeys.page, {
    userAttributes: {
      urlPath: `/mothers-day`,
      utmContent,
      locale
    },
  }).toPromise();

(The serverSideService is a helper class to give easy access to the data in the context object)

What am I doing wrong? FWIW, I do NOT have locales currently setup in NextJS (but I can see that the correct browser locale is getting passed in via context). Is that required for this to work?

Builder content link

Builder public api key
c3e3257ff5594facbf478a68d37f766d

What are you trying to accomplish
Trying to localize pricing content on a page for locales: [en-US, en-CA, en-AU, en-NZ]

Screenshots or video link

image
image1165×117 51.8 KB

image
image1136×542 137 KB

Code stack you are integrating Builder with
NextJS

2

I think you’re missing passing the locale option to the content API call.

const landingPage = await builder.get(pageModelKeys.page, {
   options: { locale }
    userAttributes: {
      urlPath: `/mothers-day`,
      utmContent,
      locale
    },
  }).toPromise();

Read more:

3

Thank you @aziz ! That was absolutely what the issue was, and I now have proper data showing!

I am a bit confused, though, as to why the Block Level solution didn’t work with passing the locale into the BuilderComponent. If I read the documentation correctly, the Block solution shouldn’t require updates to the getServerSideProps builder.get call.

Perhaps I’m just reading it wrong.

4

@chtbks-jason I re-read the documentation and we should’ve clarified this point, I’ll make a quick attempt here and share your feedback with the documentation team, thank you!

so Builder needs to transform the localized object:

"foo": {
  "en-US": "Hello",
  "fr-Fr": "Bonjour"
}

To the value that corresponds to the locale,

// locale=fr-Fr
"foo": "Bonjour"

// locale=en-US
"foo":"Hello"

But in order to do that, Builder needs to know about the locale from your codebase in two ways, both are needed and essential for full localization integration:

  1. By passing the locale to the BuilderComponent, the SDK will emit this locale while previewing or while editing to the editor so you’d get wysiwig experience on localized values.

  2. Passing the options: { locale: 'locale value' } when fetching the content from the API so it can send the JSON with resolved/localized value.

5

Thanks for explaining that both are necessary.

I’m still seeing a edge case weirdness and I’m not sure if it’s a bug or if I’m trying to do too much.

I’m nesting Symbols, I have a wrapping Symbol that contains 1…n symbols inside of it and the text inside of the nested symbols are localized. But if I have that nesting, it’s as though the nested symbol never receives the locale information from my code, and I again get [object Object] in my UI. FWIW, changing the locale selector in the Visual Editor makes no impact on the nested symbol localized text either, which leads me to believe the locale data isn’t getting passed through.

As a result, I’m detaching the wrapping symbol on each page, but I’m thinking this may be a bug that nobody ever really discovered because most people probably aren’t trying to do this kind of weird combination of nesting and localization.

It’s not an immediate showstopper since I can detach symbols, but it’d be nice if this CAN be fixed for it to be fixed. Thanks!

6

Thanks Jason, propagating the locale param down to nested symbols and references is something we’re adding support currently in the new api version, which I think will address the issue you described.

To hit the latest api version, recommend sitting that in the sdk

builder.apiVersion = 'v3'

This will soon be the default.

I’ll update here once the change is released.

1 Like
7

@chtbks-jason the latest api version v3 was updated to propagate locale param down to references and symbols.

1 Like