This leverages 4-bytes of padding in FDisplayStringEntry to store an ID (an int32 index generated via FTextLocalizationManager::GetLocalizationTargetPathId) that is used to tag each display string with the localization target that it belongs to, without increasing the size of DisplayStringLookupTable.
There is an additional LUT mapping each localization target ID to its text IDs to act as an accelerator for HandleLocalizationTargetsUnmounted, however this LUT only tracks text IDs associated with localization data loaded via HandleLocalizationTargetsMounted to minimize the memory impact of this additional tracking. Without this LUT HandleLocalizationTargetsUnmounted would need to spin the entire live table each time, which is not acceptable from a performance standpoint.
Now that HandleLocalizationTargetsUnmounted is implemented it's also been hooked into GFP deactivation, to mirror how HandleLocalizationTargetsMounted was hooked into GFP activation.
#rb anton.dunchev
[CL 32499628 by jamie dale in 5.4 branch]
This allows them to separate their mounting and content loading into two phases, such as allowing a GFP to mount the plugin when "registered" and defer mounting the localization data until "activating".
Note: Anything that was calling one of the MountExplicitlyLoadedPlugin functions to load a plugin, will now need to also call MountExplicitlyLoadedPluginLocalizationData if it wants to also mount the localization data.
#rb anton.dunchev, Leon.Huang
[CL 32496881 by jamie dale in 5.4 branch]
Introduced opt in localization for plugins. Plugins can be set to never have localization config files generated, auto-generated or have the localization pipeline use the user generated localization config files.
- All existing plugins with localization targets will be retrofitted to have a LocalizationConfigGenerationPolicy of Never to match current behavior.
- Introduced the LocalizationConfigGenerationPolicy enum to plugin descriptors and LocalizationTargetDescriptors. This controls whether plugin localization targets use user generated localization config files, auto-generated localization config files or if the plugin is never to have localization config files and thus not localized.
- Introduced a step in the Localize UAT command to auto-generate localization config files with default settings for plugins that opt into the auto-generation feature.
- Added a clean up step in the Localize uAT command to delete all auto-generated files and folders from a run of the command.
- Added a -PreserveAutoGeneratedResources flag for the Localize UAT command to preserve the auto-generated files and directories for debugging.
-Updated both the C# and C++ version of the LocalizationTargetDescriptor to contain the new LocalizationConfigGenerationPolicy and have them read and written from the plugin descriptor files.
- Updated the NewPluginLocalizationTarget command under the LocalizationTargetEditor UAT command to accept a LocalizationConfigGenerationPolicy as a command line argument for all plugin localization targets to be created.
If the parameter is not specified, the parameter defaults to the Auto LocalizationConfigGenerationPolicy for all the plugins specified.
#rb: Jamie.Dale
#jira: UE-194880, UE-194879
#test Used the NewPluginLocalizationTarget sub-command to create plugins with an auto localization target. Used the Localize UAT command to perform a gather for such a plugin. Config files were indeed generated, the plugin was gathered and the loc data stored in PluginName/Content/Localization and then the config files were deleted. No fuss, no muss
[CL 30172150 by leon huang in ue5-main branch]
Original CL Desc
-----------------------------------------------------------------
New VerseScope "InternalUser" and renamed "User" to "PublicUser"
- new enumerator for VerseScope named "InternalUser"
- renamed existing VerseScope "User" to "PublicUser" - this is possible without breaking existing projects since the VerseScope is not written out to the uplugin file when it is set to "User"
#rb andrew.scheidecker
#rnx
[CL 29419291 by bob tellez in ue5-main branch]
[FYI] Markus.Breyer
Original CL Desc
-----------------------------------------------------------------
New VerseScope "InternalUser" and renamed "User" to "PublicUser"
- new enumerator for VerseScope named "InternalUser"
- renamed existing VerseScope "User" to "PublicUser" - this is possible without breaking existing projects since the VerseScope is not written out to the uplugin file when it is set to "User"
#rb andrew.scheidecker
#rnx
[CL 29418991 by bob tellez in ue5-main branch]
- new enumerator for VerseScope named "InternalUser"
- renamed existing VerseScope "User" to "PublicUser" - this is possible without breaking existing projects since the VerseScope is not written out to the uplugin file when it is set to "User"
#rb andrew.scheidecker
#rnx
[CL 29416324 by markus breyer in ue5-main branch]
