Localization Table Updates

[hydr0h0mie]

Hi Creators,

Today, we’re sharing two updates for localization tables :

1. We’re deprecating the older real-time ingestion system for Automatic Text Capture, as we’ve had two capture systems running simultaneously. We will now only be using the offline process in experiences, but you will still be able to capture strings in real time while playtesting in Studio.

2. All localization table assets are now private. This update automatically applies to all existing and future experiences and is separate from the asset privacy beta we announced for other asset types earlier this year.

Below, we’ll dive into more details about each update, so please continue reading!

Automatic Text Capture

Read more about Automatic Text Capture:

As we’ve shared, we have had two capture systems running simultaneously:

• A real-time ingestion system, which adds strings to your localization table within 1-2 minutes of you or a player encountering them in your published experience.
• An offline process, which checks your experience on a daily basis and updates your localization table when it identifies strings that should be added or removed.

While the real-time ingestion system works quickly, it often ends up over-scraping and filling localization tables with content that should not be translated, such as usernames.

As a result, we are deprecating the real-time ingestion system and will only be using the offline process in experiences. However, we understand that there may be situations in which you need to capture and add strings to your localization table immediately. You will still be able to capture strings in real time while playtesting in Studio.

New Automatic Text Capture Settings

Like before, ATC can be enabled in your localization settings page in Creator Hub. ATC evaluates over time which strings should be added to your translation table, so it may take a few days for new strings to appear in Translator Portal.

ATC also checks your experience for strings that no longer exist, such as usernames or strings related to a past event. By default, the tool will remove these stale entries when it identifies them. Only auto-scraped strings with automatic translations will be removed; strings that were manually added or that have manual translations will not be impacted.

If you do not want ATC to clean up your localization table, navigate to your localization settings and disable the second ATC toggle:

Studio Text Capture

You can use the text capture tool in Studio to capture strings while playtesting. These strings will be added to the localization table within 1-2 minutes of encountering them.

You can start text capture in Studio with the following steps:

1. In Studio, go to Plugins > Localization > Tools.

2. Enable the toggle under Automatic Text Capture.

Note that text capture will stay on if you start and stop playtesting within the same Studio session, but it will need to be enabled again when you start a new Studio session.

Next Steps

The new ATC settings will mirror your previous settings. This means ATC will stay on if it was previously enabled, and it will stay off if it was previously disabled. Note that if ATC is on, the localization table cleanup setting which removes stale entries will also be enabled by default. This can be disabled at any time in your localization settings page.

You can learn more by reading the localization guide docs. Please let us know if you have any questions or concerns. Thanks!

Asset Privacy for Localization Tables

Read more about asset privacy for localization tables:

All localization table assets are now private. You can now add source strings and translations to the localization tables of experiences without being concerned that they will be discovered before your experience is ready to be made public. This update automatically applies to all existing and future experiences, and is separate from the asset privacy beta we announced for other asset types earlier this year.

There are some restrictions to localization table privacy:

• External users can still gain access to your localization table if your experience is public and they obtain the table’s asset ID. Because the localization table asset is downloaded by the client upon game join, users who join your game can get access to your localization table which may include strings for unreleased content. The Creator Translation team is looking into a fix for this issue; in the meantime, if you have sensitive strings that you need to test for a public experience, we recommend that you use a separate, private test experience.

• Localization table privacy is not configurable. We currently do not have plans to enable creators to open up access to their localization tables, but we are open to feedback if creators have use cases for making them public or shareable.

We’ll continue sharing updates as we innovate our translation systems, with more to come in 2025. As always, please let us know if you have any questions or feedback!

Best,
Creator Services Translation Team

[0Tenth]

Would this make a significant difference in real time performance?

[PeZsmistic]

Bless, my scraped tables are a total mess from user generated strings. AutoLocalize being on by default is a disaster for me because I started my game a long time ago without thinking about localization at all. Now with everything powered by a mixture of React and conventional UI programming, it’s a major undertaking to make sure everything except for static labels have it turned off. At least with this change, I can purge the nonsense strings and have more control over the new garbage that gets fired into my tables and when. I can explore a new feature in Studio and just push what gets scraped for that session, rather than sending an entire session of user generated text.

[hydr0h0mie]

Hey @0Tenth - strings will no longer be scraped in real time when players see them in-experience; it may take up to a few days for them to be added.

If you need strings to be added to your localization table in real time, you can use the automatic text capture system in Studio. The performance of this real-time system is the same as the former in-experience system.

[metatablecatmaid (metatablecat)]

its 2024 and i still dont know how localization tables work, like, at all.

besides that, I noticed one of these two engines would consistently spit out “TextScraper: too large” errors depending on some games, has this been fixed by any chance because its hard to debug stuff when it gets spammed with text scraper errors.

[8O8_guy (808guy)]

you can prevent these warnings in your console by just turning off the AutoLocalize property for the textlabel, it happens because the text it’s trying to capture for translation is too long

[Herbz_Dev2106 (Herbz_2106)]

@metatablecatmaid

its 2024 and i still dont know how localization tables work, like, at all.

I don’t really know a lot about localization tables myself, but if I am correctly aware the LocalizationTable is supposed to store translations (more information here). It does not however, translate text automatically in real time; at least as far as I know of. For example, if you wanted to translate user inputs after the game loads if they are not in a desired language, I believe you would still need to send the text to a third-party site.

The LocalizationService and Translator system can be used to automatically replace text with translations, but it’s not a real-time process.

A LocalizationTable is not inherently designed to automatically translate text in real-time. It’s more of a centralized storage for translations that can be used to replace text in-game.

---

You can’t really predetermine every possible translation inside LocalizationTable though so I may be questioning the use of it. Not just personally, because every time I have tried to make positive use of it, it doesn’t work. This is especially true, because Roblox translates text into your game anyways, based on a user’s preferences, so long as it’s not in real time or where the text that needs to be translated is saved and loaded separately from a datastore; (this would be an example of real time text translation if it were to be translated, requiring a separate third-party to translate the text).

What is the point of including every translated word inside LocalizationService to be replaced in your game? Such use would become impractical and time-consuming. Am I missing something here?

[lostresosostedyIII (Server)]

When are we getting language detection that the player set in the in-game Roblox settings menu?

[Damp]

I’ve been familiarizing myself with the Translations category in Create because I can definitely see it’s potential effects, but I have a question:

For in-game translations on TextLabels, is this handeled manually or through this Translation feature?

[LvieReal (Lvie)]

I’ve noticed the prints from system, I don’t think they’re supposed to show up

[hydr0h0mie]

Hey @lostresosostedyIII - are you referring to the “Experience Language” dropdown in the in-game settings menu? For any GUI object that has the AutoLocalize property set to True, it will automatically be translated to the player’s selected experience language, even if they change it mid-session.

However, if you are performing localization via scripting (using Localization APIs), you’ll need to listen to the GetPropertyChangedSignal event for changes in the LocaleID property of the Translator instance returned by LocalizationService.GetTranslatorForPlayerAsync.

You can read more and see an example of how to do this in our localization guide docs.

[melonwhine]

HI there, you are correct - a LocalizationTable stores the translations for your in-experience strings.

You are also right in saying that the translation is not a real-time process, and it could take up to a couple of hours for automatic translations to be generated (if it is enabled in the first place). However, we are looking at enabling a real time translation API in the near future.

When a player encounters an in-experience strings, we look up the the source in your localization table and try to find a match. If a match is found, the translation is rendered, or else we will just show the source string.

I hope this clears up some of your confusion around our translation systems!

[hydr0h0mie]

Hey @Damp - TextLabels can be handled through our translation system.

If you want the whole process to be automatic, you can use the automatic text capture system described in the above post to add the text to your localization table. If automatic translation is enabled for your experience, these strings will then be translated for you. Learn more about automatic translation here.

You can also add the text manually if you would like - learn how to do that here.

[hello42]

Hi, @hydr0h0mie/@melonwhine

Can this Studio context print be turned off, or in some way hidden/minimized, please?

Every localized string in our experiences are being printed by Studio, despite being non-pertinent.

[lostresosostedyIII (Server)]

Thank you so much! I was looking for this everywhere.

[hydr0h0mie]

Hey @hello42 - thanks for flagging this! Seems like this is a bug from our end. We’re working on a solution now, and it should be fixed by next week.

In the meantime, you can work around this by setting your log level to Warning instead of Info until the fix is in. Sorry for the inconvenience!

[AlphaVibex (Vibex)]

I think this is great. It is also very good that it does not affect the performance of the game in real time because strings will no longer be scraped in real time when players see them in experience. It may take up to a few days for them to be added.

[Quenty]

Can we please get an API to explicitly add an entry to the cloud table if it doesn’t exist? We have to manually upload strings now and it’s a pain.