Updating LocalizationTables with a LocalScript in a local non-published place file does not update already-created text

Bug Reports Studio Bugs
,
#1

In Studio, when a LocalScript creates or updates a LocalizationTable in LocalizationService in a non-published local place file, text objects that are already created do not update with the new localization. Toggling AutoLocalize fixes this for already-displayed text. Newly-created text objects are localized correctly. Existing but hidden text objects display incorrectly once made visible if they existed before the LocalizationTable was modified.

I do not know if this can occur on published games.

LocalizationFailRepro.rbxl (60.5 KB)

System Information

CPU: 12th Gen Intel(R) Core™ i7-12700H
Memory: 32.0 GB
GPU 0: Intel(R) Iris(R) Xe Graphics
GPU 1: NVIDIA GeForce RTX 3050 Laptop GPU

Expected behavior

I expect the existing text objects to correctly display localized text after LocalizationTables are created or modified locally.

Additional Context

I anticipate being asked why we even do this, and why we don’t use built-in localization tooling such as cloud localization. (for what it’s worth, I primarily expect this from community members, not staff, and I want to preempt any needless discussion!)

In Adopt Me! we create nearly all of our LocalizationTables with LocalScripts.

We do this because:

  • we have our own localization pipeline that uses a third-party localization platform
  • we support live localization updates in our localization pipeline (i.e. currently-playing players see translation changes while they play, when a change is made in our third-party tool’s website)
  • we need our localization to work on all games/universes, because we run QA tests on 20+ separate “universes” from production.
  • we send minimal localization data to the client
    • we send the client only their selected language
    • when translations change, we send only a patch of what changed
    • relying on built-in LocalizationTable replication is not feasible for us because it causes 8+ second freezes on update even when split into many pieces
    • the total size of all of our translations is over 8 MB
  • we support some live localization tools for our localization team, including the ability to hide all translated strings so untranslated ones stick out
  • we support some additional features that depend on dynamic generation of tables or depend on source locale → source locale translations
#2

Hey @Corecii thanks for the report. This is certainly an uncommon use case. We will take a look. Not sure if this lands in new feature territory or not. I will update here when I have more info.

#3

Thank you for taking a look!

It’s probably relevant that this used to work fine, so if it’s stopped working then it’s an unexpected change in behavior for us. This localization code has been active on our production universe for 11 months and it has worked in Studio for most of that time too. It would be fair to say that this is “new feature” territory if we were relying on undefined behavior, though, but still frustrating on our end to have to fix this without warning after it worked fine for so long.

I think if we have to we can work around this issue at the least, since we do have a mechanism to trigger re-localization of text.

#4

I just did some testing in Adopt Me! and this does also occur on production, I just don’t know the specific circumstances necessary to repro it on the client app as it seems to be more specific than Studio for most cases.