You may have noticed some new features in the Localization Portal for your game and the Localization Tools Studio plugin, such as the ability to add Translators and enable Automatic Text Capture, along with some other settings.
These are part of our new suite of Cloud Localization Tools, which - you may have noticed - we haven’t announced quite yet.
We’re working on a series of posts and DevHub resources to explain how to use these features, which are currently live and in early beta, but wanted to fix some issues before sharing those with you. We also want to collect feedback from developers who have already begun using these features on their own - please share your thoughts below.
Look forward to some exciting new announcements about the Cloud Localization Tools in 2019.
Until then, happy holidays and have a happy new year!
seems like you might need to click the image to see the problem: note the number of pages!
The problem is that it captures usernames which appear on an end of round screen, and so its left me with an enormous amount of entries (which I can’t delete either). I have two questions:
Is it possible to detect when a username is present in a string and block that out with a placeholder like currently happens with numbers?
Does uploading a csv overwrite these entries and clear the 1,735 pages of strings I’ve collected on a small game?
Otherwise definitely excited to see how this plays out as doing this translation on the website seems a lot less fiddly than downloading a CSV, uploading it to google docs, sending links to translators and downloading them to put back into the place again.
Aw man was hoping this would be about automatic translating (Yeah I know its lazy, but it would much easier for large games for the system to just translate for us no matter how bad the translation may be. I’m really not up for spending like $200 to translate a couple sentences when auto translation does a decent enough job in most cases.
Yeah, this is one of the issues I presently have with the text scraper tools. It seems to have trouble understanding context and the variety of naming techniques that developers use.
It works well as a means of identifying what things should be subject to localization, but I wouldn’t advise mapping localization to what it generates alone. It’s the task of the developer to make it something efficient and dynamic enough for translators to work with.
Yeah, currently my flow is to use the Studio scraper tool, edit it to remove all the usernames it captures (basically just mine if I’m in Play Solo) and make everything tidy for a Google Sheet.
The automatic text translation sounds great but it just floods the online tool. I just tried uploading a .csv that I currently use and it looks pretty good on the site, although none of the translations actually populated on the website despite being in the file.
This is one of the known issues we’re trying to address for the automatic text capture.
Typically, the text capture does recognize and correctly format playernames in strings.
For example, if the text was “PlayerFoo has died!”, it should be captured as {playername} has died! in the Source, and only have one entry for all playername variants.
What’s happening instead is that we’re seeing `PlayerFoo{1} has died!" with an entry for each playername variant. Hence, the rapid growth of your cloud localization table.
Short-term fix: if you can currently download your cloud localization table using the Studio plugin, then you can - as you guessed - upload a new CSV (your original local Localization Table, for example) to replace what’s been collected by the Automatic Text Capture.
However, if you can’t download your current cloud localization table with the Studio plugin, that’s a second known issue: very large cloud LTs currently hang forever when attempting to download them via the plugin. This, unfortunately, also prevents you from uploading a new CSV to the cloud to replace the current cloud LT.
We’re working on fixes for both issues, but due to the holidays, the fixes aren’t going to land until after the New Year.
It does! Disabling GuiBase2d.AutoLocalize allows you to control which GUI elements are or aren’t captured by the Studio text scraper/Automatic Text Capture or auto-translated.
Spoiler warning, but yes: Automatic Text Capture shifts the burden off of the developer when it comes to capturing all text in the game. What developers currently have to do with manual input or with the Studio text scraper will now be done automatically as players play through your game, helping guarantee more comprehensive capture of text in your game.
Interesting note about none of the translations actually populating on the website, despite being in the file. Is your embedded (e.g. local Localization Table in Studio under Localization Service) localization table still intact? Did you also enable the Use Translated Content setting in the Localization Portal?
I also find it a bit unintuitive that I have to upload a new CSV to the LocalizationService in game and also the website through the tools. It would be better if they were both synced perhaps.
Are you using “es-es” as your Spanish column header when you upload your embedded table or “es”? The cloud localization tables currently require “es” instead of “es-es” - that might be why your translations aren’t showing up correctly. Let me know if you are using “es” and the translations still aren’t showing up.
Yay! Yes, sorry, that’s one of the currently undocumented requirements of the new cloud localization tables. While you could create your own locale ids for the embedded tables, and we recommended using language-locale pairings like es-es, pt-br, etc. in the DevHub documentation, the new cloud tables only accept language codes (es, pt, fr, de).
We’ll be updating the DevHub localization resources and including this and other details/changes in the full rollout in 2019.
(Yeah I know its lazy, but it would much easier for large games for the system to just translate for us no matter how bad the translation may be. I’m really not up for spending like $200 to translate a couple sentences when auto translation does a decent enough job in most cases.
Yes, sorry, that’s one of the currently undocumented requirements of the new cloud localization tables. While you could create your own locale ids for the embedded tables, and we recommended using language-locale pairings like es-es, pt-br, etc. in the DevHub documentation, the new cloud tables only accept language codes (es, pt, fr, de).