使用 resx 文件进行本地化会生成 MissingManifestResourceException

Question

这是我第一次尝试本地化，我对它了解得越多就越困惑。老实说，我现在只是在寻找答案。所以这是我得到的错误：

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

这里是 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;
    }

}

我想由于某种原因我很接近它正在将 .resources 附加到文件而不是 .resx？

在此先感谢您的帮助。

忘记说明翻译 class 的使用方式。

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));
    }
}

Answer 1

请注意，我是 Visual Studio 商业本地化工具的作者（为了全面披露）。您应该调查 "System.Threading.Thread.CurrentThread.CurrentUICulture"，这通常是 .NET 中所有翻译所围绕的内容（用于处理本地化资源）。然而，你如何处理它的机制可能因项目类型而异。通常不需要您现在执行此操作的方式。它通常比那容易得多（不需要专门的 类 ）。例如，这是一个简单的控制台应用程序的基本过程（同样，事情可能因您的项目类型而异）。

1. 创建一个名为 "TestApp"
的新控制台应用程序
2. 打开项目的属性（例如在解决方案资源管理器中右键单击它并选择 "Properties"），然后单击属性 window 中的 "Resources" 选项卡。现在单击屏幕中间显示 "This project does not contain a default resource file. Click here to create one" 的按钮。这会将 "Resources.resx" 添加到您的解决方案（在解决方案资源管理器中的 "Properties" 文件夹下），它会在“.resx”编辑器中自动打开。
3. 在“.resx”编辑器中添加一个名为 "MyString" 的字符串。分配它 "This is my default string" （或其他）。
4. 在您要使用字符串的代码中，添加 "using TestApp.Properties" 语句（继续阅读）。您现在可以通过静态 属性 "Resources.MyString" 访问字符串。这是在 "Resources.Designer.cs" 中声明的，它是 VS 在上面的步骤 2 中自动创建的 "code-behind" 文件（即，它是解决方案资源管理器中 "Resources.resx" 的子文件）。 VS 会为您处理此文件（为您在上面的 3 中添加的每个字符串向 "TestApp.Properties" 命名空间添加一个新的静态 属性）。请注意，这些字符串被称为 "strongly typed resources".
5. 向您的项目添加一个新的“.resx”文件并将其命名为"Resources.es.resx"。这将包含西班牙语的字符串。创建后，将其在解决方案资源管理器中拖动到 "Properties" 文件夹（因此它现在与 "Resources.resx" 位于同一文件夹中 - 所有本地化的“.resx”文件必须与 "Resources.resx" 位于同一文件夹中).
6. 双击"Resources.es.resx"并添加"MyString"。将其文本设置为 "This is my Spanish string".
7. 如果您想更改代码中的语言以获取字符串的西班牙语版本，只需将代码中的 "System.Threading.Thread.CurrentThread.CurrentUICulture" 属性 设置为 "es"。现在，无论何时您引用 "Resources.MyString"，都会（自动）返回该字符串的西班牙语版本。 IOW，它遵循 "System.Threading.Thread.CurrentThread.CurrentUICulture" 当前设置的任何内容。因此，您通常会根据应用程序的要求（例如，当用户从您的 GUI 中单击他们想要的语言）更改后者 属性，并且您所有的强类型资源（通常只有字符串）将自动采用新的语言。
8. 这是如何工作的？下面这段话摘自我曾经发给我的一位客户的东西。它应该足以让您入门（请注意，对于上面的示例，下面对 "YourApp" 的引用将更改为 "TestApp"）：

"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.