I agree with that 
I’d rather not know what dark magic processes the text property as long as it just works. There is this very specific case for which I need a more dynamic system than the macro in c++, this is a procedurally generated list of input mappings. Whenever a mapping is not present in a string table the log generates an error such as “Action_Jump” / “Action_Jump_Description” / “Axis_MoveForward” / “Axis_MoveForward_Inverse” / “Axis_MoveForward_Inverse_Description” is not present. Here the middle part is the input mapping name taken from the configured mappings and displayed in a procedurally generated list. I wouldn’t want the widget designer to have to add and configure a 100+ keybind environment on just one panel. This leaves me with little option but to figure out how to work with the FText dark magic?
To be clear I do get the right results with FText::FindText usually, sometimes the result is empty. I had to screw around a bit to make sure the string tables are loaded as well. The issues is that sometimes it gives an empty result and I want to make absolutely sure it is not interfering with any “standard way” of localizing in the engine. I have a different issue just from reading text properties which is most likely not related but I need to be sure one does not cause a bug in the engine to the other anyhow. I disabled FText::FindText for now so I can debug if the issue in the post below is unrelated. meanwhile I need to find a solution to be able to localize a dynamic string the correct way in c++
[UE5.1.1, Bug report] Widget does not set text unless asset is reloaded. - #13 by Roy_Wierer.Seda145
I’m going to test a bit with NSLOCTEXT on that input system because that doesn’t require the namespace variable of that more generic localize utility i showed anyway. Still curious if FText::FindText is any good at all. I rather be able to store my namespaces in a static constant like “UCoreUtils::LocaleNSHID” than writing it all over the place.