A Text Render Component currently has a simple FString as its content.
/**
* Renders text in the world with given font. Contains usual font related attributes such as Scale, Alignment, Color etc.
*/
UCLASS(HeaderGroup=Component, ClassGroup=Rendering, hidecategories=(Object,LOD,Physics,TextureStreaming,Activation,"Components|Activation",Collision), editinlinenew, meta=(BlueprintSpawnableComponent = ""), MinimalAPI)
class UTextRenderComponent : public UPrimitiveComponent
{
GENERATED_UCLASS_BODY()
/** Text content, can be multi line using
as line separator */
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category=Text)
FString Text;
So how do we localize Text that is to be rendered using TextRenderComponent?
All of the text in Solus is rendered this way, so I do need a way to make it localized!
Thanks!
Rama
PS: I classified this as a bug because I dont know how to to support all of UE4’s awesome localization features in a Text Render Component. Is this already being addressed?
In your codebase, you’d want the localise the strings before they get to the TextRenderComponent, then at run time retrieve their string value when you want to render them. Is there something complicating this that I’ve missed?
The complicated part is that I am not the one doing any of this, it is all being done in blueprints !
and further
We’ve all been specifically, very specifically warned, not to convert an FTEXT back to a string!
So that means that FString is never an equivalent for localized FText
which means the UTextRenderComponent has fundamentally the wrong base level data type.
#Link to Being Told To Never Do FText->FString
So based on that very strong warning,
there is no way to use UTextRenderComponent to fully support Localizaiton
#Full Quote
I bet you’re thinking ‘Wow! That seems really simple; there’s gotta be a catch. Localization is supposed to be hard.’ Well, there aren’t really any catches but some people will be tempted to cheat around this rule by converting between Text and String values.
Unfortunately, this is where you can run into problems. If you convert a String to a Text, that Text will be treated as culture invariant, aka it will not be translated. So it’s super important that you enter your display text in Text values initially. Converting a Text to a String is also not advised. Text values abstract away access to the direct String which allows for some great features such as live language toggling and provide you with guaranteed localization safe operations.
#For Emphasis
" So it’s super important that you enter your display text in Text values initially. "
That means UTextRenderComponent has the wrong base data type. It should be an FText.
I supposed I could do a pull request to fix this, if Epic can confirm this is not already in the works
Ah yes - I see what you mean. In this particular instance the text render component does indeed take a string and does not support text. I suspect this part of the engine hasn’t been updated yet, so what I would do is perhaps modify the text render component (at least temporarily) to include a function to take FText, which contains a string anyway. Hopefully someone at Epic can jump in and point out any caveats there may be with that.
If you’re not modifying the engine, then you’ll need to convert to a string at least until Epic catch up and update the TextRenderComponent to work with both FString and FText.
I’m sorry to say that the TextRenderComponent was not designed with localization in mind. It was done a Free Friday project by one of our programmers and hasn’t gotten any additional love since then.
The short of it is that TextRenderComponent should take an FText. We should possibly remove the FString option entirely.
I’ll see about getting this addressed as I get the impression this component is actually being used quite heavily even though it isn’t ready for actual prime time.
“'ll see about getting this addressed as I get the impression this component is actually being used quite heavily even though it isn’t ready for actual prime time.”
While this may be an acceptable work around for the time being, using the engine’s integrated localization solutions should be preferred. FText effectively does this for you behind the scenes. You gain many benefits from using FText so I would tread carefully in regards to disposing of it.
To make your work around a little better, I would use Text variables instead of string ones. By using Text variables you don’t need to perform any of the additional language logic or explicitly input extra fields per language.
So it would just be your struct with a single Text variable for CONTINUE which you then convert to a String and pass to the text render component. All the language swapping is done for you by the FText automagically.
