Language issue in UWP build and in Microsoft Store listing: GI data interpreted as language folder

We've just released an experience on the Microsoft Store and were surprised that Afrikaans turned up as a supported language in the dashboard, and, despite removing it from the list of languages on the web page before submitting, is now reported as a supported language on the store front page. Some digging with the help of Microsoft support turned up that apparently, the package itself contains the information that Afrikaans (af) is supported (just to be clear: it's not ;-)).

Further digging indicates that during the process to create an app package for the store from Visual Studio, some part of the scripts invoked seems to go through the Unity-exported Data directory, finds a folder with the name af in Data/GI/level1/af, i.e. part of the Unity GI data, and thus reports that Afrikaans is part of this build (the same also happens for "be" and "ca"). The warnings which show up in the Visual Studio output look like this:

Warning 0xdef00522 - Resources found for language(s) 'af,be,ca' but no resources found for default language(s): ''. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899

I've now changed the XML file Package.appxmanifest to use only one language (en-US - via the <Resources> XML node), and this at least has led to only this language being reported in the dashboard (haven't submitted yet).

However, while I certainly appreciate the sheer absurdity of this behavior - can I somehow exclude the Data directory from this automatic language scanning, or whatever it is, in the future? How?

Thanks!

PS: Another irritating warning which shows up (quite a few times) is this, which sees to indicate that the system thinks that this particular file is only applicable to Afrikaans (it is in the af directory).

Warning 0xdef01051 - No default or neutral resource given for 'Files/Data/GI/level1/af32e391fbf1db29c4f341991f494d94.ecm'. The application may throw an exception for certain user configurations when retrieving the resources.

 

Using .NET, here are the relevant screenshots:



Thanks for looking into this! Maybe this auto-language-detection feature can be disabled somehow? Or is this usually not an issue?

 

@Tautvydas-Zilys thanks. I've submitted, case 976639.

 

Actually, I just saw that the relevant files indeed cannot be opened at runtime, I get lots of

Failed opening GI file at relative path: 'be/beac1221265d28af35fe835dbee8ee35.vis'.

in the UnityPlayer.log (this is an UWP app). This is bad :-( - if you find a workaround or anything, please let me know.

 

I've just looked into the generated packages (.appxupload etc.), and in fact, the af/ folder and everything in it is completely missing from the build.

I feel bad for even having tried this, but making a copy of "af" and naming it "en" removes the warnings in Visual Studio - but at runtime, the "af" files are still not found. The "en" folder is part of the build, but I assume that since Unity doesn't go through the Windows localization resource logic - and why would it - it doesn't find them.

So what I need to figure out now is how to keep the "language-specific" folders in the default (EN) build...

 

Alright, I found a workaround. Part of the build is a call to makepri.exe which creates the Package Resource Index (PRI) files which more or less contain a directory of files in the build. Makepri, by default, looks for language-named folders and splits the build along the languages it finds - which moves the language-specific files into resource packs.

Luckily, this behavior can be configured, as is described here - makepri can be instructed to just place everything in one big resource file instead of splitting up. This is achieved by editing the .csproj file, and adding the following two lines to the configuration section for Master|x64:

Code (XML):

1. <AppxBundleAutoResourcePackageQualifiers>DXFeatureLevel</AppxBundleAutoResourcePackageQualifiers>
2. <AppxDefaultResourceQualifiers>Language=en-us;de-de;es-es</AppxDefaultResourceQualifiers>

The first line disables auto-language qualifiers (since "Language" is MISSING from the list). Since languages are now no longer auto-detected, they must be explicitly listed (second line). Note that the warnings discussed above still show up in the console; but the final appx/appxbundle/appxupload contains all files.

I've not found a way to do what I originally wanted - specifying that certain folders should not be considered language-specific - but this works for me.

Perhaps the auto-language scanning option should be disabled by default in Unity-exported projects? This is always going to be an issue if the GI directories contain folders which are ISO language codes as well.

 

Thanks plmx. I'm having the same problem.

Bunch of "No default or neutral resource given for 'Files/Data/GI/level1/aff1941303100cebcf8c1c93293de3e6.rgb'. The application may throw an exception for certain user configurations when retrieving the resources."

As well as the language problem with a folder named af (located in Temp\StagingArea\Data\GI\level1).
Resources found for language(s) 'af' but no resources found for default language(s): ''. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899

I've reported this issue years ago. Not sure if it was fixed or those folders names are randomly generated and I just got lucky - but never seen them again until now. The app will not pass review unless you add that specific language - had that problem once and my app was rejected.


Edit: Well, sure enough those folder names are randomly generated. Deleted them, redid lights, rebuilt and no more language problems (for now).

However those "No default or neutral resource given for 'Files/Data/GI/level1/......." warnings are still there.

 

@magg Have you tried my workaround? After applying the changes to the .csproj file, warnings still turn up in the console, but the resulting package contains all files.

I also noticed that re-generating lighting seems to change some folder names, but this is a tedious process and, at least for me, there was always one offensive folder.

 

Thanks, that's great to hear!

 

Thanks plmx
Your workaround works; only additional thing I had to do is edit Package.appxmanifest, change Language in Resources as
<Resource Language="en-us" />