Switching Localization assets for a project

Unity Engine
, ,
1

I have what might be a unique use case, and am curious for any advice on how to accomplish my goal. I’m trying to minimize using any hacky methods that could be brittle to changes in the future – and am fine to generate some custom tooling to create extra validation or QA to make sure this works OK:

I am using a single repository and a single Unity project to support at least 2 different apps (i.e. different bundle IDs, different app names, different project settings) for iOS and Android. The separate apps have unique requirements, but share a lot of common features – in terms of various tradeoffs, the single repository is worth the effort.

Depending on the active app, I want to switch to a particular set of string tables and set of active locales. The easiest method I have found to do this, is to store separate subfolders for localization:

Localization/
|-- Project-A/
|-- Project-B/
Assets/
|-- Localization/

Then, a custom Editor script will replace the contents of Assets/Localization with Localization/Project-A or Project-B when the app is switched.

After I do this, I have some errors when loading the localization tables or project settings – which are reliably fixed by closing and re-opening Unity.

Is there a way to effectively reload everything without closing and re-opening Unity?

Currently, this is my test code that swaps the folder contents:

AssetDatabase.StartAssetEditing();
Directory.Delete(fullDestinationPath, true);
CopyDirectory(fullSourcePath, fullDestinationPath);
AssetDatabase.StopAssetEditing();
AssetDatabase.Refresh();
AssetDatabase.SaveAssets();
EditorApplication.RepaintProjectWindow();

I would appreciate any tips!

2

If you would do the thing everyone else are making their solutions and ways to work for, you would have significantly easier time.
You should have two separate projects for your two separate apps and potentially a third one for the things in common, developing the common part and including it in both projects.

What you’re doing is not supported on any level for any reason and you most likely will do this hacking all the way losing energy, resources and introducing unknown and maybe even hard to discover bugs and error in both applications.

With many years of experience in software, I would never do this. It isn’t worth it.

1 Like
3

I’d like to support what Lurking-Ninja said.

Though if you are determined to keep it all in one project then extracting the shared code & assets into a git sub repo could be a way. Also make each of your apps into a separate branch in git. To work on one simply checkout whatever you need. Branches should only contain what’s different from the base. It’s still not ideal but I assume it would be much less brittle than your self-made copy dirs solution. With git at least you’ll always have a way back.

Oh and from experience I’d advise to always close Unity before committing and switching branches. Some things are only “written” to files at shutdown.

4

Thank you both for sharing your perspective. The details of the single git repo for multiple Unity projects aren’t really relevant to the issue I’m describing, but for what it’s worth – it’s worked well for our specific use case, and the editor tooling to swap settings (icons, bundle IDs, app control flow) are all very lightweight and easy to use.

My question is specifically about the com.unity.localization package and using the package to localize the metadata of the app – for example, how to programmatically swap the short name of the app when I’m changing my build settings.

So far it seems like the most robust method is to swap the strings table out completely (e.g. two versions of a ProjectMetada string table and localization files, and swap between them).

When I re-open Unity, everything looks good. And if one project has 11 languages and the other project only has 3 languages, that doesn’t seem to be an issue for Localization to refresh the available locales based on the files in the project.

I realize I’m out on a strange peninsula with this kind of workflow, and trying to understand if there’s any risk to deleting and rewriting localization files like this whenever I switch builds. If things will continue to load in a predictable way as I’m seeing now - great! But I can’t tell where there might be gremlins.

@karl_jones Any tips on if it’s safe to delete and rewrite localization files with Unity open, and how to properly refresh the asset database?

Instead of relying on the localization package, it would be relatively straightforward to write some build scripts to set the short name, display name, and permission text – but there are some very nice bonuses for our use case if we can “safely” swap the localization files in the way I’m describing (like changing the available locales and centralizing the localized strings).

5

Ah I understand, sadly I lack the experience with Unitys localization system to help in detail.

Maybe we can get a mod to move this over to the dedicated localization forum? I guess your chances for a more detailed answer would be higher there: Unity Engine - Unity Discussions

6

Oh oops! Yes, I definitely should have posted there – thank you.

7

It’s possible although I would echo what’s already been said, it’s not advisable. Having mixed string tables in the same project may be tricky to pick the bits you need for each project so may result in more files than you need in a build.
You could use a build script that sets the app name data in the localization settings, you just need to make sure it comes before the localizations own build script.

It should be ok to delete some localization files, what is it that needs to be reloaded? There is no universal reload other than restarting the editor, it really depends on what needs the update, it could be something is cached internally and needs clearing.

8

@karl_jones I’ll try to be concise; please let me know if this helps clarify. Grateful for your help.

I have all my localization files stored under /Assets/Localization, and by “delete and reload” I am referring to “swapping” all of the files from Project A to Project B (outlined below). This would let me, for example, change the short name, and change the available locales for the project.

Only one set of files is in the project at once – the other set is loaded from a folder in my git repo but outside the /Assets/ folder.

When I run my editor script to swap the files, and then check out the state of the localization tables under Window > Asset Management > Localization Tables – everything looks great, every time. Sometimes the state of “Localization” under Project Settings > Localization is a black window, but restarting Unity makes it refresh and look just fine.

I wasn’t sure if there’s a function call to rebuild or reload anything, or if – for this workflow I’ve concocted – closing and re-opening Unity is the most reliable way to go about this.

Project A
|–English (en).asset
|–Czech (cs).asset
|–Spanish (sp).asset
|–Strings_en.asset
|–Strings_cs.asset
|–Strings_sp.asset
…9 other languages

Project B
|–English (en).asset
|–Spanish (sp).asset
|–Strings_en.asset
|–Strings_sp.asset

The keys in the “Strings” string table are the same for both projects.

9

If its working then I guess its fine although I would keep an eye on the AddressableAssets folder as this is linked to the localization assets and will need to be updated each time, it should happen during the asset import/deletion.

Its losing the localization settings. You can fix this by assigning the new localization settings asset to LocalizationEditorSettings.ActiveLocalizationSettings.
So after you update the files do AssetDatabase.Load with the settings file and then assign it to the ActiveLocalizationSettings.

10

@karl_jones Thank you – that took care of it!

AddressableAssets seems to update nicely. When I swap from Project A (12 locales) to Project B (2 locales), the removed locales stick around as empty Addresssables Groups (and persist after restart and after build – haven’t tested a full asset reimport) but that doesn’t seem to cause any issues.

Before your reply, I realized I was not intentionally swapping the Localization Settings.asset, and letting it update after the asset import/deletion. Now I’ve included that file as part of what gets swapped between the projects. I don’t observe any functional differences, but I assume there will be less changes in the git history when I’m intentionally moving the Localization Settings.asset around because previously the order of the GUIDs/references to the locale assets could change with each asset import/deletion (but the GUIDs/references themselves to the locales are not being modified or broken).

1 Like