We’ve started looking into the localisation for our game. So far I’ve managed to setup the config file correctly and run the GatherText commandlet to gather strings from source and our assets (although that did take most of a day, the documentation could definitely be a lot better for this).
But when gathering strings from assets I’m getting unexpected results that I could do with some help on.
Firstly
I have FText variables in blueprints that are not being picked up.
For example if we had a class like so:
UCLASS(Blueprintable)
class UObjective : public UObject
{
GENERATED_UCLASS_BODY()
public:
UPROPERTY(BlueprintReadOnly, EditAnywhere, Category="Objective")
FText ObjectiveDescription;
UPROPERTY(BlueprintReadOnly, EditAnywhere, Category="Objective")
bool bIsVisible;
}
Then the “ContinueButtonBorder” text is picked up. The same is with all our widget animations. I don’t see why this would need to be picked up?
Thirdly
In our .po we have this text being picked out:
#. [...]Widgets/WI_StartTurnScreen.WI_StartTurnScreen:PrepareForPlayer.K2Node_CallFunction_35175.EdGraphPin_94125.DefaultTextValue
#:[...]/Widgets/WI_StartTurnScreen.WI_StartTurnScreen:PrepareForPlayer.K2Node_CallFunction_35175.EdGraphPin_94125.DefaultTextValue
msgid "- Do the important thing"
msgstr "- Do the important thing"
This is referring to a TextBlock used in the widget graph called MainObjectiveLabel. This used to be the default text value but this is no longer the case:
I’m taking a look at each of these and resolving them in turn. Thanks for the details!
In the third case, the path suggests that it’s actually getting that name from the default value of a pin on a node in a graph. Do you have a graph or function or macro called PrepareForPlayer?
I understand the documentation is obtuse. Fortunately, I’m close to delivering a feature that makes the localization workflow immensely more friendly and UI-based, rather than manually editing config files and executing commandlets from commandline. At that point, documentation will be rewritten for the new workflow.
Thanks for taking a look at these. You comment did help me find the culprit of the PrepareForPlayer, so thank you.
As for your other changes; 4.7 will be the last engine version we get before locking down. What are the chances that your changes will be included in 4.7? Specifically the fixes for the issues mentioned as opposed to your UI and workflow changes.
I can’t promise it’ll make it in to 4.7, but I can certainly provide you with changelist numbers and you can probably (very easily) spot integrate the changes and fixes. If it does make it in to 4.7, I’ll post here about it.
Part 2 I have a fix for shelved, ready to be submitted soon.
Part 1 however, I haven’t been able to reproduce using that exact scenario. It’s possible that this was a bug that’s already been fixed. Does that exact scenario fail for you?
Using the same code as above (obviously making the class Blueprintable) I made a blueprint with some text in it. Ran the GatherText commandlet on the QAGame and the text was not picked out.
We’re using 4.6.1 so maybe it has been fixed already?
And you ran this script through your project’s editor by using the arguments " -run=GatherText -config =./Config/Localization/Game.ini" or some such and found no entry for “Place the Bomb” in the manifest?
I’ve managed to find the source of the issue although I’m not sure how to fix it and it’s to do with subfolders.
Our Gather text step 1 looks like:
;Gather text from assets in content.
[GatherTextStep1]
CommandletClass=GatherTextFromAssets
IncludePaths=./Content/Abilities/*
IncludePaths=./Content/Scripts/*
IncludePaths=./Content/UI/*
ExcludePaths=*/Content/UI/DebugWidgets/*
PackageExtensions=*.umap
PackageExtensions=*.uasset
But this is only picking up assets that are directly under Scripts and not in any subfolders in Scripts. I’ve also tried IncludePaths=./Content/Scripts/ but that also didn’t work.
That seems rather odd. GatherTextFromAssets doesn’t actually iterate over directories. It looks at packages and, if their file path matches an IncludePath, adds them to a list of packages to be loaded for later processing. As such, any packages existing in subdirectories should be accepted by merit of matching the include path wildcard for the parent directory.
Out of curiosity, is it possible that these assets have been relocated and have redirectors that need fixing up? If so, this might reveal an issue with gather text from assets that have been relocated and have outstanding redirectors in place.
I must apologise, that last comment turned out to be false positive.
My objective blueprints are still not being picked up. They are picked up if I move or copy them to directly under the scripts folder. However, other assets that are in sub folders and in the same subfolders as the objective blueprints are being picked up. So it’s not a subfolder problem. The output does not indicate any warning or errors related to these objective blueprints.
Is there a way I can debug this to try and find out exactly what is happening? I tried running this through visual studio but couldn’t work out how?
You should be able to run this through Visual Studio using the Debug Editor Win64 configuration. The same arguments are usable on the commandline (-log, -run, -config, etc.).
Alternatively, if you have a small project that reproduces the issue and can zip it up, I can debug that. 4.6.1, right?
It looks like the asset is failing one of the tests in GatherTextFromAssetsCommandlet.cpp.
Specifically the GetFileVersionUE4() check around line 889:
// Early out check if the package has been flagged as needing localization gathering
if( PackageSummary.PackageFlags & PKG_RequiresLocalizationGather || PackageSummary.GetFileVersionUE4() < VER_UE4_PACKAGE_REQUIRES_LOCALIZATION_GATHER_FLAGGING )
{
PackageFileNamesToLoad.Add( PackageFile );
}
We won’t be taking 4.7, so 4.6.1 will be our last take of the engine. We can still take selected changelists though. So please do let me know when you’ve checked in your fix for Part 2 and when we solve this ongoing issue, if it requires another change.
The former condition just checks if a package has been flagged as containing some kind of data of interest to gathering for localization. The latter condition is an old fail-safe so that packages that were created (and not yet resaved) before we added the flagging could still be processed anyways, just in case.
That still strikes me as very unusual - it changes based on what directory you place the file in, which shouldn’t affect whether the flag. The flag is set when a localizable FText object is serialized into a package.
It’s going to be difficult to track this down short of having a zipped up project with the reproducible issue. Without that, my best tips are to try loading and saving a single UObjective asset in the editor and see why the flag is getting set from FText’s serialization methods. If it is, then why it isn’t set when the package actually serializes to file on disk or when loaded from file on disk.
Thanks for the CL# 2449360. That seemed to work fine.
Your reply about packages that were not resaved also got me thinking. I did a recompile of all our blueprints and suddenly everything was being picked up as it should be.
The reason moving or copying was making it be picked up was because doing either of those things was causing either a resave or it was just a new asset, hence the flags were setup correctly.
