I am under the impression from your article that we should never be converting FText to String if we want to keep the localization
So how is Localization supported at all currently in terms of drawing it on the HUD using Slate?
How do I draw Localized text to the screen?
Thanks!
Related Answerhub post
**EDIT: Answered**
My questions on this matter have been answer here:
https://answers.unrealengine.com/questions/58914/stextblock-does-not-support-localization.html
and here
https://answers.unrealengine.com/questions/58921/how-can-i-draw-localized-text-to-the-screen-hud-sl.html
+1 on 's issue. We are stuck on this and we are contractually obliged to localize Solus or we cannot release. We are unable to proceed with the localization as it stands now, and more info on the matter would be awesome.
I just happened back on this thread. I wasn’t getting any emails about new posts!
It looks like we’ve already addressed the majority of your issues/questions, please re-post if I’m over looking something other than the current lack of audio localization support.
I do want to respond to your concern regarding Slate using FString instead of FText internally.
So as of last week we’ve submitted changes to all of the text widgets to use FText internally (aka accept an FText though the public interface). Which gives us some really exciting potential for new features as well as increased performance (as FText are dramatically faster to compare if you’re only interested in checking if two are ‘identical’)! That being said, if you scratch past the surface some you’ll see we still convert that FText into an FString at some point. We do this because FText doesn’t expose the option to iterate over the text’s characters, for good reason I should add. Converting to an FText to an FString is safe is specific situations, text rendering is one of those, but even then we don’t want to do that conversion until we’re forced too, which is why we do it behind the Slate widget’s interface.
In short, don’t worry. Even though there is a conversion from FText to FString inside the text widgets everything is safe for localization and the internationalization concerns are still being handled appropriately. The only major thing missing atm is the need for a font shaping pass before we do the rendering. Once we have font shaping we’ll have proper support for languages like Arabic and Thai.
[]
The only major thing missing atm is the need for a font shaping pass before we do the rendering. Once we have font shaping we’ll have proper support for languages like Arabic and Thai.
[/]
So this thread is really fluffy and there doesn’t seem to be any actual docs on how to actually do localization.
Some of us are programmers and have different systems in mind. Let’s have an article on the actual technical details. You know, other than “use this data type and it will magically work. Oh those other steps like actually entering in the text for the different languages? That documentation will come later.”
This article isn’t about localizing your game but creating a game “ready for localization”, which in UE4 really just means “use FText”.
While we don’t have documentation posted yet, it is in the works. I can probably post a preview of the documentation here on the forums soon (this week). The preview would just be lacking the iteration and review provided by our documentation team here at Epic, but should still be very helpful.
There are other posts on the forums with information regarding how to gather for loc and what to translate. Localization is Very Important you’ll want to look towards the bottom/mid for the details.
[=supermario6532;166037]
Will you be using to do the shaping?
[/]
Sorry just saw your question!
We would probably use ICU’s layout shaping library as we’ve already committed to ICU for other features, but perhaps not. ICU’s layout library was developed separate from ICU core modules and may not be of the same quality.
[]
We would probably use ICU’s layout shaping library as we’ve already committed to ICU for other features, but perhaps not. ICU’s layout library was developed separate from ICU core modules and may not be of the same quality.
[/]
The ICU LayoutEngine is deprecated and unmaintained. You really should consider using . It is open source, BSD licensed and is being actively maintained by many companies (Google, Mozilla, Qt).
Even ICU recommends using over the ICU LayoutEngine. See first paragraph of the following:
[]
Obviously we haven’t done much research into the topic yet.
[/]
Well I hope you guys start soon. Bi-directional multiple language multi-line text editing is sure to be a can of worms.
Not sure what you plan to do about font fallback but Google’s Noto Font probably should be considered as a baseline as they aim to cover all scripts encoded in Unicode.
Can anyone explain why the key and namespace parameters are needed? Also, I assume I can define different namespaces for my classes and then be able to use the same key, ie namespace “foo” has key of “bar” and namespace “foo2” can also have a key of “bar”?
While we don’t have documentation posted yet, it is in the works. I can probably post a preview of the documentation here on the forums soon (this week). The preview would just be lacking the iteration and review provided by our documentation team here at Epic, but should still be very helpful.
[/]
Is there an update on getting a preview out? It would be super useful
[]
Obviously we haven’t done much research into the topic yet.
[/]
Re-using parts of Google’s gfx::RenderTextHarfbuzz API could help speed up adding support for Arabic, Hebrew, etc to Unreal as it is BSD licensed. Google uses this API to render complex text in the title bar and address bar chrome. It is probably better than starting from scratch or trying to unwind Blink’s (Chrome’s HTML renderer) /ICU code.
It uses ICU for text analysis and itemization (Bidi), uses for shaping and takes font fallback into consideration.
We are also currently working on an in-editor UI to manage all these settings. It should boil all the technical details down to pressing one of three buttons (Import, Export, Gather).
[=Sarge;177197]
Sorry for the lack of preview, but here it is!
Better late than never.
We are also currently working on an in-editor UI to manage all these settings. It should boil all the technical details down to pressing one of three buttons (Import, Export, Gather).
[/]
Nice to see! Would it be possible to update the example config text with an example for GatherTextFromMetadata? The other commands are covered, but it is absent.
