@karl_jones I’m running into this same issue but I don’t have an asmdef file. I’m on Unity 2020.3.15f1, Localization package 1.0.0-pre.10.
I can create the localization components on the UI and add them to my TextMeshPro gameobjects
Created the strings table and referenced the string I want
Created a Global variables group with a global variable that’s picked up by the component and updates appropriately
But I can’t access the global variables group through code since it complains that Localization isn’t a namespace within Unity Engine. Is there another place that I need to be referencing the package? This is the first time I’ve run into this kind of issue even with using the Analytics package and other non-standard ones.
Full error message:
The type or namespace name ‘Localization’ does not exist in the namespace ‘UnityEngine’ (are you missing an assembly reference?) [Assembly-CSharp]csharp(CS0234)
Code is just trying to access LocalizationSettings object:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Analytics;
using UnityEngine.UI;
using UnityEngine.Localization;
public static class GameData {
public class Settings {
private bool soundEnabled = true;
private bool musicEnabled = true;
private bool notificationEnabled = true;
public Settings() {
var source = LocalizationSettings
.StringDatabase
.SmartFormatter
.GetSourceExtension<GlobalVariablesSource>();
}
}
}
To test, I tried loading a sample from the package manager into the project. The moment I did so the errors resolved themselves. Seems a bit strange the package was installed but somehow my own scripts couldn’t reference the namespace but when a sample was loaded it could.
Is there some hidden build file or similar inside of Unity for how it resolves imports? The package manager showed it installed…
Either way, if anyone else runs into this try just importing a sample into the project to see if that resolves the reference issue.
LocalizationSettings is in the namespace UnityEngine.Localization.Settings. I think you just needed to add an extra using at the top.
Not sure why adding a sample fixed it.
Although it does sound like something else is going on.
Hello, I’m running into the same issue. I can’t access the UnityEngine.Localization namespace after installing the Localization package and I don’t know how to reference the localization asmdef. Currently I had not run into this issue with other namespaces form other installed packages. The Unity.Localization.dll is in the project Library > ScriptAssemlies. How should I fix this?
Hello Karl! And thanks for reaching out. On the day I installed the Localization package I was trying to use the UnityEngine.Localization namespace but it could not be found, even though everything was installed correctly. I even tried to close and reopen my Unity project but that did not work either. Today after restarting my computer the issue was gone and now I can normally use the Localization namespace. Maybe turning the computer off and then back on may fix the issue for other people.
I just observed an error similar to this in Daggerfall Unity. The included code was:
using System;
using System.Collections.Generic;
//using UnityEditor;
//using UnityEditor.Localization;
using UnityEngine.Localization.Settings;
using UnityEngine.Localization.Tables;
With error message “cs0234 namespace localization does not exist in UnityEditor”
I added a sample and that did resolve the issue. At which point I started removing and manipulating until I reached this statement “namespace UnityEditor.Localization{}”. Simply adding that allowed the build to continue.
using System;
using System.Collections.Generic;
using UnityEditor;
using UnityEditor.Localization;
using UnityEngine.Localization.Settings;
using UnityEngine.Localization.Tables;
namespace UnityEditor.Localization{}
Following that principle, this statement would probably resolve the poster’s issue “namespace UnityEngine.Localization{}”
“Resolve” is a pretty hard term, work around, or fake would be more appropriate.
That seems very strange. Can you not just remove the line ‘using UnityEditor.Localization’?
If you don’t need the using statement then remove it or you get errors like above.
I had a question for you Karl. The only analogue I can think of is that “using UnityEditor.Localization;” would be similar to “#include ” in that it’s some kind of include. Unlike a C++, however, it seems that a code reference is required. I could use “#include ” without ever calling a function like “std::string” and that wouldn’t generate an error.
In this case it seems as if using the include “using UnityEditor.Localization;” requires a function of the namespace to exist somewhere within code so that a corresponding “namespace UnityEditor.Localization{}” is required. In the examples, this wouldn’t be the case. It seems like we just need the root when a function is built, something like “namespace UnityEditor.Localization.Work{}” where “Work” references “UnityEditory.Location” and thus becomes a sub-function.
Just keep in mind that I am not a coder and don’t really know how any of it works. I’m pretty good at sleuthing out bugs that prevent a program from compiling, but that’s just the application of other people’s solutions.
Edit:
I was seeing “namespace UnityEditor.Localization.Samples” and thought that meant “Samples” was user defined but I can see in the documents that that is, in-fact, a global namespace. It looks like code should normally be grouped within one of these defined namespaces? That should prevent the error. ASMDEFs aren’t used in Daggerfall Unity, so maybe having an ASMDEF would change the behaviour slightly?
My guess is that placing the code within a global namespace is what triggers the include to be “linked” or “loaded”. Pure speculation, though.
There is localization editor code under this namespace but it’s not being included in your code, likely due to the asmdef differences, so it doesn’t find the code and reports the missing namespace. If you did ‘using some.namespace’ it would also produce an error if the namespace did not exist anywhere. Removing the using statement is the correct approach.