localization using resx files generates MissingManifestResourceException

It is my first effort with localization and the more I read about it the more confused I become. To be honest, I am just looking for an answer at this point. So here is the error I am getting:

Unhandled Exception:System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "MeetnGreetSf.Resources.AppResources.resources" was correctly embedded or linked into assembly "MeetnGreetSf" at compile time, or that all the satellite assemblies required are loadable and fully signed. occurred

And here is the class:

public class TranslateHelper
{
    readonly CultureInfo ci;
    private string ResourceId = "MeetnGreetSf.Resources.AppResources";
    private ResourceManager resmgr;
    private CultureInfo cui = new CultureInfo("es-ES");
    public TranslateHelper()
    {
        //ResourceId += "." + cui.Name;
        resmgr = new ResourceManager(ResourceId, typeof(AppResource).GetTypeInfo().Assembly);


    }

    public string Translate(string Name)
    {
        var translation = resmgr.GetString(Name, ci);
        return translation;
    }

}

I think I am close for some reason it is appending .resources to the file instead of .resx?

Thanks in advance for any help.

Forgot to include how the translate class is being used.

public Colors()
    {
        colorInfo = new ObservableCollection<ColorType>();
        t = new TranslateHelper();
        this.GenerateColors();




    }

    private void GenerateColors()
    {
        colorInfo.Add(new ColorType(t.Translate("Aqua"), Color.Aqua));
        colorInfo.Add(new ColorType(t.Translate("Black"), Color.Black));
        colorInfo.Add(new ColorType(t.Translate("Blue"), Color.Blue));
        colorInfo.Add(new ColorType(t.Translate("Gray"), Color.Gray));
        colorInfo.Add(new ColorType(t.Translate("Green"), Color.Green));
        colorInfo.Add(new ColorType(t.Translate("Lime"), Color.Lime));
        colorInfo.Add(new ColorType(t.Translate("Maroon"), Color.Maroon));
        colorInfo.Add(new ColorType(t.Translate("Navy"), Color.Navy));
        colorInfo.Add(new ColorType(t.Translate("Olive"), Color.Olive));
        colorInfo.Add(new ColorType(t.Translate("Purple"), Color.Purple));
        colorInfo.Add(new ColorType(t.Translate("Red"), Color.Red));
        colorInfo.Add(new ColorType(t.Translate("Silver"), Color.Silver));
        colorInfo.Add(new ColorType(t.Translate("Teal"), Color.Teal));
        colorInfo.Add(new ColorType(t.Translate("White"), Color.White));
        colorInfo.Add(new ColorType(t.Translate("Yellow"), Color.Yellow));
    }
}

Solution

Note that I'm the author of a commercial localization tool for Visual Studio (in the interest of full disclosure). You should investigate "System.Threading.Thread.CurrentThread.CurrentUICulture" which is normally what all translation in .NET revolves around (for handling localized resources). The mechanics of how you deal with it however can vary depending on the type of project. The way you're doing it now isn't normally required. It's normally much easier than that (no dedicated classes are necessary). Here's the basic process for a simple console app for instance (again, things can vary depending on your project type).

Create a new console app called "TestApp"
Open the project's properties (right-click it in Solution Explorer for instance and choose "Properties"), and click the "Resources" tab in the properties window. Now click the button seen in the middle of the screen that says "This project does not contain a default resource file. Click here to create one". This will add "Resources.resx" to your solution (under the "Properties" folder in Solution Explorer) and it will be automatically opened in the ".resx" editor.
Add a single string called "MyString" in the ".resx" editor. Assign it "This is my default string" (or whatever).
In your code, where you want to use the string, add a "using TestApp.Properties" statement (read on). You can now access the string via the static property "Resources.MyString". This is declared in "Resources.Designer.cs" which is a "code-behind" file automatically created by VS in step 2 above (i.e., it's a child of "Resources.resx" in Solution Explorer). VS looks after this file for you (adding a new static property to the "TestApp.Properties" namespace for each string you add in 3 above). Note that these strings are referred to as "strongly typed resources".
Add a new ".resx" file to your project and call it "Resources.es.resx". This will contain strings in Spanish. Once created, drag it in Solution Explorer to the "Properties" folder (so it's now in the same folder as "Resources.resx" - all localized ".resx" files must be in the same folder as "Resources.resx").
Double click "Resources.es.resx" and add "MyString" to it. Set its text to "This is my Spanish string".
When you want to change the language in your code to pick up the Spanish version of your string, simply set the "System.Threading.Thread.CurrentThread.CurrentUICulture" property in your code to "es". Now whenever you reference "Resources.MyString", the Spanish version of that string will be returned instead (automatically). IOW, it follows whatever "System.Threading.Thread.CurrentThread.CurrentUICulture" is currently set to. You'ld therefore normally change the latter property based on your app's requirements (say, when a user clicks their desired language from your GUI), and all your strongly-typed resources (usually strings only) will automatically adopt the new language.
How does this work? The passage below is an excerpt from something I once sent to a customer of mine. It should be enough to get you started (note that references to "YourApp" below will change to "TestApp" for the above example):

"You should investigate "Strongly Typed" resources instead of the way you're handling things. Also investigate satellite assemblies and the "System.Threading.Thread.CurrentThread.CurrentUICulture" property (there's also the "CurrentCulture" property you should look at but that doesn't impact your resources, which are always controlled by the "CurrentUICulture" property). Note that the "CurrentUICulture" property is set to the system's current language normally (when your app starts). When you access any resource in your program, such as "Resources.MyString" (this is an example of a strongly-typed resource which you'll need to review), the system will look for "MyString" based on the "CurrentUICulture" property. If that property is currently set to the system default (it normally will be unless you change it in code), then you'll get the version of "MyString" back from your app's main assembly (the default language resources are stored there). If you change "CurrentUICulture" in code to "es" however (for Spanish), then the system will look for "MyString" in the file "es\YourApp.resources.dll" (off your program's root folder). If it doesn't find it there (the folder may not exist if you don't support Spanish), or more realistically, "MyString" simply has no translation in that (Spanish) DLL, then it will fallback to your app's main assembly, so you'll get the default language string again. Again, this is the short-story, but it covers the basic details. It's traditionally known as the "hub and spoke" model in MSFT's documentation (though other terms are sometimes used), and it relies on the "fallback" process mentioned earlier. For instance, if you set "System.Threading.Thread.CurrentThread.CurrentUICulture" to "es-AR" which is Spanish as spoken in Argentina, then the program will look for "MyString" in "es-AR\YourApp.resources.dll". If not found there (you don't support "es-AR" for instance, so there is no such folder, or the string simply isn't there), then it will "fallback" to the "es" folder instead (known as the neutral culture, in this case just plain Spanish which the system assumes is the next best thing). If not found there (in "es\YourApp.resources.dll"), then again, the system will fallback to the default language strings embedded in your main assembly. Research all of this and you'll find that handling your strings is a breeze compared to how you're now doing it. Everything is handled for you automatically including the fallback situation (just by adjusting the "System.Threading.Thread.CurrentThread.CurrentUICulture" property - all references to any strongly typed resources such as "Resources.MyString" will then appear in whatever language that property is currently set to). I hope that helps.