Bug Localisations failing to load, but only in builds

Heya, I know googling for this topic produces a lot of results - but nothing seems to be working for me.

I have four different localisation tables, based upon different scenes where they are used. The first/login screen works just fine; including all the languages we support, fallbacks, etc. - beautiful. The second shows the "key not found" messages, but only in builds.

I changed the "editor playmode" loading of addressables to be from the built bundles, not the asset database, and same behaviour there too (works in the editor, not in builds). I tried re-setting the reference values in case they were messed up during an upgrade; I ran the Addressable Analyzer (no issues found); I even tried some unrelated tips from other threads (changing the asset group path to custom/local.Buld etc.). I tried all the tips in the pinned thread on this forum, including cleaning the addressables and rebuilding. Nothing seems to be working.

Viewing the addressable groups, the working groups appear to be configured identically to the non-functioning group.

I'm happy to diagnose further, but I'm not sure where to start. Everything *seems* to be correct. Is there some debug code I could throw in to help narrow down the problem?

 

Yep for sure - I built them in the editor (you can set editor playmode to use built bundles only, not the asset database directly) and this works fine for all my groups.

I can also tell that the asset bundles were built properly for build-mode (not editor mode) because one group works, but the other does not.

 

No errors, other than the visual "no key for ID found" message.

 

Nothing exciting in there! https://gist.github.com/SnugglePilot/2cc1ac2dd41797b2358d9c2a17c90813

 

I am on 1.3.2, yes. I had the same behaviour with 1.3.1 as well, however.

 

Sure thing -

The LoginFlow_en group in the (en) stringtable is working fine in builds and the editor.
The Server Select_en group in the (en) stringtable is the one working in editor, not working in builds.

I'm just noticing in this screenshot that the "labels" column is different for the (en-CA) groups, which is odd.

 

Here are the top level settings, if they are helpful -

 

New data - in the editor, if I open up the Localization Scene Controls and change the language - the Server Select keys now fail to load. No matter which language I pick, it "stays broken." I'm not certain what is causing the localization to not trigger properly in the editor in this case, but I can confirm the Server Select_en is not working as intended even in the editor.

Edit: here is a video showing the behaviour, if it helps: https://drive.google.com/file/d/1_Rfjepts97sRj8m0QQiZ9mL9dPGzUALP/view?usp=sharing

 

Each of those are glyph-missing warnings, telling us that our font isn't capable of showing the Pseudo stuff in its entirety. They don't appear for the "normal" languages.

 

Hey, I'm experiencing some similar issue.

Upgrading from 0.11.1 to 1.3.2, using Unity 2020.3.20f1.
All platforms and Builds (Windows Desktop Standalone x64, iOS and Windows UWP x64 Desktop and the Editor) are running fine, except for our HoloLens Build (Windows UWP ARM).

In our very first scene, LocalizeStringEvents that are enabled and have a LocalizedString set from the Start are showing the "No translation found for..." error text. Curiously other LocalizeStringEvent in the same scene that have their Reference set later are working and even the same keys failing beforehand are working fine in a subsequent scene.

Unfortunately I'm unable to create a repo case, because changing small thinks, like removing private LocalizedString fields from a component or changing the Script Excecution order for LocalizeStringEvent to "-60" fixes it.

However I added a StackTrace log to LocalizedStringDatabase.ProcessUntranslatedText to get some more info on how and where the lookup fails. Here's the StackTrace:

It's kind of weird that the GetTableEntryOperation succeeds (otherwise there would a different error message) but the subsequent usage of that operation results in a failed entry lookup.

 

I found at least one way to reproduce the results I'm seeing here, using the Google Sheets integration.

1. Start with a gsheet integration and some random lines in the loc table here and there.
2. In Unity, add a new key (eg, "HEADER") and enter the value in the table editor
3. Test/everything should work fine
4. In GSheets, make new key with the same name ("HEADER"). Since you didn't "push" the change after step 2, this will be a new line in the sheet.
5. In Unity, "pull" the changes from gsheets.

I believe this operation is re-assigning the metadata-ID (the local changes are lost in the pull operation). However the string name is still the same, so the inspector is showing as a valid field.

When playmode runs, it fails to look up the (non-existent) value of the meta-ID, instead of parsing the ID number from the provided string in the inspector.

My solution to fix my affected fields was to just destroy the object that had the bad metadata and rebuild it (just remove the loc component and re-add).