If you enable the āSkip Source Checkā option under the āCompile Textā section for your localization target, then that will skip the validation check when building the LocRes files and allow āstaleā text to be used at runtime.
PO files will still export with an empty translation though, and the translation dashboard would show the entry as untranslated (with a stale translation).
Thanks Jamie.
Sadly, Iāve not been able to get this to work.
Iāve checked the āSkip Source Checkā option under the āCompile Textā section, however when I change any text, it removed the localised text as well. I have tested this in a packaged game.
To confirm, I didnāt gather or compile the localisation. I simply changed a bit of text for a widget that was already localised. Once I loaded the packaged game, that text reverted to English and was missing the āstaleā localisation.
Is there anything else I need to do for this to work correctly?
Once I gather+compiled it worked for text in widgets. Thanks Jamie!
However, text in a dialogue plugin Iām using (FText variable inside a Data Asset) doesnāt work. Any changes I make to the dialogue text removes the native translations. Any idea why this is not working?
@Jamie_Dale I did have some trouble with the Skip Source Text flag, which wouldnāt work properly in my builds (translated text with changed source string was still missing, even if I ticked Skip Source Text, regathered, recompiled, cooked and built). I investigated the issue and found that the flag correctly includes or omits stale text when building the LocRes file, but thereās another culprit at work:
When chunking the LocRes, FLocalizationChunkDataGenerator::GenerateChunkDataFiles calls FTextLocalizationResourceGenerator::GenerateLocRes with hardcoded EGenerateLocResFlags::None. I think this step works with the data from the previously compiled LocRes (which already includes or doesnāt include stale strings, as desired by the user), so if Iām correct, the simple change to hardcoded EGenerateLocResFlags::AllowStaleTranslations would be all it takes to repair this.
Itās actually using the manifest data rather than the LocRes data (as the LocRes doesnāt have the source location), but youāre right that it should respect that flag (as set in the config). Iāll make a note to see what can be done there.