Option one is easier in the real code, but I fear there are reasons like globalization or something like that, that makes option two the better one.
Could someone please tell me?
Neither of those will work with localization. Generating an FText using FromString only converts the string as-is to the FText format, it doesn’t allow for any keys or culture replacement.
Using the first option is probably “better” just from data size, but they are almost functionally identical.
Is there a reason you’re using std::str instead of FString?
To create an FText that will work with localization, you’ll want to use the LOCTEXT macro:
The difference being that with LOCTEXT you need to have defined the loctext namespace prior to using the macro; and be sure to #undef the loctext namespace when you are done:
It’s the Key that is used for localization; the provided content string is used for the default culture, and then when you generate text content values for other cultures they’re used to replace the default content string based on the key value within the given namespace.
As of 4.15 or 4.16 you also have the option of using a TextTable and pulling the FText values from the csv.
Is there a reason you’re using std::str instead of FString?
Kind of. The reason for my question is, that I am very unsure about the whole text thingy here in UE4.
In Qt for example, I just use QString and I know I can use it for backend and frontend and i18n and I can put cyrillic letters into it or use it for right-to-left writing or use it with threads, every thing goes.
Here I have FName for identifiers, FString for internal strings and FText for displayed strings.
So, if FString is not good for strings which have to be displayed, then I think it has to do with the globalization, right? Not sure, I am just guessing here.
That is the reason I did not use FString here. I hoped, that std::string would have the properties needed that FString needs to be as good as FText, but like I said, I am guessing like crazy, that was the reason for this whole question.
I am currently not doing anything with globalization but I’d like to be prepared for it.
I really don’t like to have “FText::FromString” everywhere.
So I’d like to know, how do I do it easy and right?
“That is the reason I did not use FString here. I hoped, that std::string would have the properties needed that FString needs to be as good as FText”
It’s not one format being “as good as” the other, FText is designed for localization, FString is not. FText is a larger data format, FString is mutable, FName has faster comparison. It’s all about the right tool for the job.
There are no properties of std::string that make it more or less viable for localization within Unreal than FString; neither work. Only FText works for localization, and in order to work it has to be created as an FText. Using FText::FromString creates a cultural invariant FText, meaning it will never be translated.
In order to be localizeable, the FText values are associated with a key. When you translate the game you build other language strings and associate them with the same FText keys. When a user chooses to use the game with another language, the original (default culture) strings are replaced with the appropriate language strings using the keys.
In order to create FText that is localizable, use the macros I described above, or build your FText strings into FText data tables.
Briefly: by default you might have the phrase “The Cat” associated with the key “CatKey”. When creating a French translation you would associate “Le Chat” with “CatKey”; in Spanish you’d associate “El Gato” with “CatKey”.