Module update breaking localization

Unity Engine
,
1

We have been facing an addressable/localization issue for the past months affecting us at build time. We think it might be a bug in one of these 2 libraries, but only triggered by our tool chain.

Unfortunately after a few days trying we are not yet able to create a simple reproducible scenario outside of our environment. We’ve found a work-around but we are not entirely satisfied with it.

The following information might be enough for someone with knowledge of these 2 components to know what is going on.

Context:

Our project is dependent on external modules, with their own versioning and release cycles. Our build tool chain contains a dependency management tool that predates UPM but works more or less in the same way, except that the libraries are installed under a specific folder under Assets.

We have a Game using com.unity.localization in the game itself and also in a module. So we have 2 sets of localisation tables and groups in 2 different Unity projects. The groups for each language in the game project reference the tables from the module (they have 2 entries in the Serialize Entries field, one for the game translation table and another for the module translation table).

Issue:

We are seeing an issue when we upgrade the module. The references to the module tables in all the language groups get lost, even though the UUIDs of the tables don’t change. The path of the module does change because we use the version number as part of the path. So upgrading the module breaks the module translations. This doesn’t happen when we add the module for the first time, only when we upgrade it.

To update the module our own package manager will at launch delete the previous version of the module, and import a new one. It calls AssetDatabase.Refresh(); and AssetDatabase.SaveAssets() after deletion and again after re-adding the module.

This is what we see in git:

Assets/AddressableAssetsData/AssetGroups/Localization-Assets-Shared.asset

  loses references of the tables coming from the module

Assets/AddressableAssetsData/AssetGroups/Localization-Locales.asset

  Loses references of the locales that are only present in the module

Assets/AddressableAssetsData/AssetGroups/Localization-String-Tables-XXXXXX (XXXXX).asset

   Lose references to all the localization for that language for the localizations from the module

It’s as if the localization tables from the modules had been removed but not re-added.

Work-around

The solution is to re-import the folder that contains the module tables and groups but we don’t understand why it fails to import automatically and unlinks the references. We noticed the assets PostProcessing code in Addressables that detects deleted and newly added files but it’s hard to debug why importing fails (but reimporting succeeds).

We wish to fix this issue properly.

Is there anyone with knowledge of the addressable / localization modules that could from the description above:

  1. point us to where to look at either in the setup or in the areas to look at

  2. give us a good idea on how to troubleshoot this further. We could add some logging to the addressable/localization modules but it’s not an ideal process

2

There’s been issues with the on post process all assets callbacks getting called in the wrong order. localization is being called before addressables which can cause configuration to become corrupted. We are working on a fix for this at the moment.

3

ok that makes sense. Is there a place to track this issue?

4

Yes here

This wont be possible to just fix in the package. We need to make changes to the Editor first to support controlling the execution order. Ill put details in the bug when those changes are available.

5

Given that the localization depends on the addressable module already, couldn’t the localization post processsor be notified by the adressable post processsor instead? This could be rolled out now without depending on the editor to improve.

6

That was one of the fixes we considered but would require changes to both packages which we want to avoid. The new fix works across more use cases and does not depend on addressables making changes. Its possible this may not fix your issue though. This was designed to fix an issue when opening a project for the first time and no library directory existed. Your issue may be different. If you need something now then it is possible to embed both packages so that you can make changes to the code. So you could make this change locally to see if that fixes your problem.
You would need to make AddressablesAssetPostProcessor public and add an event to it. Then hook into that and call the LocalizationAssetPostProcessor.