Pass Locale into Symbol

I have created a reusable symbol, so call Header, and there is a Title field with type Text and with multiple locale, such as en, zh, ja and Default.

So, after that I went to create a Page and include that resuable Symbol into the Page and I notice, those elements I have added onto the page will get affect and turn into the correct locale (chinese in our case) but not the the text in Symbol (Header Symbol)

On the nextjs coding side, I include the ‘zh’ - Chinese Locale at the page level, image|661x500

just wondering why only those elements/ components on the Page level get affect and not Symbol ? Can you please advise how should I pass it to my Symbol from the Page level please ?

Hi @leontan welcome to the Forum, and great question!

By default, symbols are a contained component that have their own state, so the locale being passed into the page-level state wouldn’t necessarily pass down into the symbol-level state, where the binding is set up.

If you click on the Symbol and check the Advanced Options tab, you should see a toggle to allow the Symbol to inherit state. Once it is inheriting state it should receive that state.locale value, try that out and see if that works for you!

hi TimG,

thank you, yes, it is working now. Another quick question, since this Symbol is a Header and it will be included for almost all pages. Imagine I have 100 pages, does it mean on every pages, I have to go in and toggle this field Inherit State one by one? may i know is there a way I can set it to be enabled by default or any hack such as create a Template which wrap the Symbol etc

Hi @leontan hmm that is an interesting…yes there is potentially ways you could do it, possibly setting the inherit state value to true in the parent content json manually but I think that could get messy.

Let me ask you this, are all of your pages going to have this header? If that is the case, instead of manually adding them to the page, you could just as easily fetch it within your code base and add it as a on the app or some other top level page?

You can see an example doing something like this in our React Design System starter:
Header component
added as a top-level component on index.js

Hope this helps!

thx Tim for the idea.

yes, you are right Header and Footer are actually more straight forward and can be added from the code level. However, for our website, every single page comes with multi-lingual, definitely there will be some other reusable components in the Symbol form, which are expected to be inserted into the middle section of random page, and need to be locale enabled. Because one thing I like about is, it releases out Programmer, but I cannot ensure most of my business entity colleague would be consistent enough to enable the Inherit state when they drag those Symbol components in.

mind sharing hows the parent content json works ? where the entry, I would like to try it out please.

Hmm actually, I am not sure it would be a great option. My thinking was, if you look at the response from hitting our API endpoint directly:

..."blocks": [
    "@type": "",
    "@version": 2,
    "id": "builder-54acb58f09f34d90a87bd6ecd97ebbe1",
    "component": {
      "name": "Symbol",
      "options": {
      "dataOnly": false,
      **"inheritState": true,**
      "renderToLiquid": false,
      "symbol": {
        "model": "symbol",
        "entry": "66bf2bfb01374a6bb2700db01c182a1f",
        "data": {
        "textInput": "default input text",
        "author": {
          "@type": "",
          "id": "026dc09cf19b4546bdb21aee320261a0",
          "model": "author"

You could theoretically use the write API to manually find all content with a symbol and add the inheritState: true but given that symbols can be nested, etc it would be very difficult to accurately set up.

Instead, I actually think the best route might be to instead of inheriting state, add a locale input to your Symbol entries themselves that is marked as Required

Then, whenever a user places a symbol on a page, they will be required to select the locale. Here, instead of setting a value, you can actually bind the locale to a locale value from the parent page’s state:

This requires a little more of a setup, but as long as you set it as a required field that should force authors to set those values and avoid any user errors.

Hopefully this makes sense, please try it out and see if that works for you!