How to use the @commercetools-frontend/ui-kit.LocalizedTextInput.createLocalizedString function in @commercetools-frontend/ui-kit

// data provided when first opened. When the user would submit the form,
  // we would read the version from the cache (where it has increased).
  // We would thus skip the APIs ConcurrentModificationError, but the user has
  // never seen the updated version of the data. This is quite bad and can lead
  // to accidental loss of data. By keeping the version in the form values
  // instead an update of the version in the Apollo Cache does not affect the.
  // form. On submission the version from the form values will be used, and the
  // user will see the APIs ConcurrentModificationError as expected!
  version: doc.version,
  key: doc.key,
  // The name is initialized with all supported languages set to their value
  // or an empty string. This circumvents a lot of edge cases where we'd
  // otherwise have to deal with either undefined or an empty string, or a
  // filled string.
  name: LocalizedTextInput.createLocalizedString(resourceLanguages, doc.name),
  slug: LocalizedTextInput.createLocalizedString(resourceLanguages, doc.slug),
  // The product does not contain a "description" field by default. However,
  // the form expects description to be a string. Hence, we have to fall back
  // to a string here!
  description: doc.description || '',
  // The inventory should either be an empty string or a number. The inventory
  // could be undefined, in which case toFormValue will set it to an empty
  // string. This eases validation later on, as we don't have to deal with
  // undefined anymore.
  inventory: NumberInput.toFormValue(doc.inventory),
  // parseMoneyValue will ensure that the price field will have currencyCode and
  // amount filled out or set to empty strings. This reduces the cases we
  // need to deal with (amount, currencyCode or the whole object being
  // undefined).
  price: MoneyInput.parseMoneyValue(doc.price, locale),
});

// cache. The form will not reinitialize with the new data. The form uses the
  // data provided when first opened. When the user would submit the form,
  // we would read the version from the cache (where it has increased).
  // We would thus skip the APIs ConcurrentModificationError, but the user has
  // never seen the updated version of the data. This is quite bad and can lead
  // to accidental loss of data. By keeping the version in the form values
  // instead an update of the version in the Apollo Cache does not affect the.
  // form. On submission the version from the form values will be used, and the
  // user will see the APIs ConcurrentModificationError as expected!
  version: doc.version,
  key: doc.key,
  // The name is initialized with all supported languages set to their value
  // or an empty string. This circumvents a lot of edge cases where we'd
  // otherwise have to deal with either undefined or an empty string, or a
  // filled string.
  name: LocalizedTextInput.createLocalizedString(resourceLanguages, doc.name),
  slug: LocalizedTextInput.createLocalizedString(resourceLanguages, doc.slug),
  // The product does not contain a "description" field by default. However,
  // the form expects description to be a string. Hence, we have to fall back
  // to a string here!
  description: doc.description || '',
  // The inventory should either be an empty string or a number. The inventory
  // could be undefined, in which case toFormValue will set it to an empty
  // string. This eases validation later on, as we don't have to deal with
  // undefined anymore.
  inventory: NumberInput.toFormValue(doc.inventory),
  // parseMoneyValue will ensure that the price field will have currencyCode and
  // amount filled out or set to empty strings. This reduces the cases we
  // need to deal with (amount, currencyCode or the whole object being
  // undefined).
  price: MoneyInput.parseMoneyValue(doc.price, locale),
});