Hello, having written a localization system or two in my day I am watching this package with much interest! The smart string system and metadata is really interesting. I personally haven’t used it in a production so forgive me if I missed this functionality in the docs.
As anyone knows, as you develop a game, keys are added to the table that are no longer being used. Either they were temp/test or the label was deleted. I would love to have a tool in the localization system that helps remove or flag these table entries in some way. So that the keys can be evaluated and removed prior to being localized. Keeping these old strings around can add up in terms of translation costs and increasing disk/ram requirements.
I appreciate that doing a usage search has always been a weak point of Unity. It requires doing an asset search through all assets (prefabs, scriptable object, and scenes). I realize it is a bit tricky, but it isn’t impossible. I feel it could really be a helpful and save development time/costs. In terms of scripting usage I feel that an IDE code search on top of this isn’t too onerous. It is really the Unity asset side that is not immediately searchable.
Do other people think this would be useful? Are there any plans to add a “Find Unused Keys” to the localization system?
Hi,
Interesting suggestion.
I have added a task to our board to look into this further in the future. It certainly is possible, as you say we would need to scan through all the assets which would be a little slow but maybe we can find some ways to speed this up. Perhaps do a step during the build to check as scenes and assets are being serialized.
Pardon the necroing, but as someone who works on a product in Unity that’s been going for 8 years now this feature would be very welcome. Our current localisation system doesn’t allow for this and that’s really led to a lot of clutter.
We’re probably going to be switching systems, for other reasons and knowing the one we’d be moving too has support (planned) for this would be a huge plus.
The general idea is to iterate through each scene and examine each GameObjects components. We use a SerializedObject to iterate through the values of each component looking for LocalizedStrings. When we find one we record it in a HashSet. Once we have scanned the project we then compare it against the tables to see what’s missing.
This does not currently handle prefabs but would be simple to expand on, just search prefabs and use the same code.
In this example, we just print out the results however you could instead remove the missing entries from the table. If so I would first record the missing entries in a list and then use that list to remove the entries.
Ill move this to one of our next sprints since its already started
Hello @karl_jones !
Thank you for the suggestion. It is good, but the search is very flat, i.e. it ignores prefabs referenced from the scenes.
Would be good to have a tool to search across the whole project for usages of LocalizedStrings, including LocalizeStringEvents referenced from all the assets included into a build (scenes in build settings, Streaming assets and Resources, assets marked as Addressables). Would be great to have this tool out of the box. It is okay if the processing takes a while, as this will only be used occasionally. Without this tool localization tables grow in size without any control.
No news at the moment I’m afraid. As for roadmap it’s something we have but it’s not in any official state. We do plan to put something together later in the year, hopefully in time for Unite.
We have gone through a UI/Ux review and have some plans for improvements, initially planned for 1.5.x.
We don’t have plans to remove the addressables dependency, it’s key to a lot of our internals so removing it would require us writing our own addressable system which we would like to avoid
We do have support for loading from other sources with the the ITableProvider and ITablePostProcessor. We will likely go further down this line to make it easier to supplement the data.
We are also more integrated with the UI Toolkit team now so expect to see better integration and tooling in the future.
