亲爱的人,请再帮忙 [英] Please help again, kind people

查看:73
本文介绍了亲爱的人,请再帮忙的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,

好沮丧我做了两天的研究,但我不知道如何定位常量字符串.你能帮忙吗?我的事情是:我可以声明一个本地常量字符串,但是不能从其他类访问它.我无法在方法之前声明常量字符串,因为我需要该方法接受诸如en-GB,fr-FR之类的参数来指定资源文件.请帮忙.提前谢谢.

我在以下类之一中有此代码:private const string Header ="Phone Number";
私有字符串Footer =名称";
我想对其进行本地化,所以我有一个本地化类:

Hi all,

So frustrated. I did two days'' research, and I do not know how to localize a constant string. Could you help? My thing is: I can declare a local constant string, but it can not be accessed from other class. I cannot declare the constant string before the method, because I need the method to accept the parameters such as en-GB,fr-FR to specify the resource files. Please help. Thanks in advance.

I have a this code in one of the classes: private const string Header = "Phone Number";
private string Footer = "Name";
I want to localize it, so I have a Localization class:

namespace People
{
    public static class Localization
    {
        public static string Name = null;// For name, it all works, because Name is private string
        public static string Phone_Number = null; // For Phone_Number, it doesn''t, because Phone_Number is a constant string

        public static void CultureInput(String culture)
        {
            CultureInfo ci = new CultureInfo(culture);
            ResourceManager resourceMgr = ResourceManager.CreateFileBasedResourceManager(...);
            Name = resourceMgr.GetString("Name", ci);
            Phone_Number = resourceMgr.GetString("Phone_Number ", ci); 
            }
        }
}


当我尝试替换时:private const string Header = Localization.Phone_Number;
它给我一个错误:必须为标头分配一个常量.


[Edited]代码包装在"pre"标签中[/Edited]


When I try to replace: private const string Header = Localization.Phone_Number;
It gives me an error: Header must be assigned a constant.


Code is wrapped in "pre" tag[/Edited]

推荐答案

请勿使用常量字符串进行本地化,使用静态字符串属性从资源中提取本地化的字符串值.
Don''t use a constant string for localization, use a static string property that pulls your localized string values from resources.


根据定义,您不能本地化常量. (一个 constant 是如此恒定,不是吗?:-))

在本地化之前,您需要全球化该项目.基本上,这意味着使项目功能与UI文化无关 .

首先,您需要摆脱所有立即常量(在代码中硬编码的常量),尤其是字符串.作为中间步骤,您可以将它们变成在某些(特殊)静态类中显式定义的常量.在某些项目中,可能存在一些永远不应该被本地化的常数(但并非总是如此).在这种情况下,请清楚标记代码的这一部分:请勿本地化".

当您看到要本地化的字符串时,将它们全部移到资源中.假设您使用.resx资源.创建一个资源文件,添加资源名称和值.现在,打开自动生成的C#文件.在解决方案资源管理器中显示的项目结构中,它将作为资源节点的子节点放置.在此文件中,找到具有静态属性的静态类;属性的名称将与资源文件中的名称相同或相似.现在,只需在代码中使用这些名称而不是常量即可.结果,所有立即常数都应该消失,并且所有受本地化限制的常数仅在资源中找到.

实际上,全球化还有很多,但是上述步骤是最重要的.您还需要确保当所有呈现的字符串的长度更改时,您的UI设计可以表现良好.您还应注意根据文化对各种数据进行正确且与文化无关的处理,例如日期时间格式,货币,数字表示等.在本地化期间,您将需要决定如何使用所有键盘热键并测试它们的一致性.

全球化完成了,是时候进行本地化了.对于本地化,您永远不要修改或修改基本的全球化代码. 主要的全球化程序集在本地化期间保持不变.这是本地化的关键思想.本地化资源被添加到解决方案中,而不是替代任何东西.该应用程序应该只能切换线程的区域性和UI文化.

创建与您的全球化资源结构匹配的卫星程序集.您的构建应根据区域性的命名约定将它们放置在单独的目录中.当应用程序的线程(例如主UI线程)的区域性切换到其他线程时,全球化的应用程序会自动选择要使用的资源集.资源程序集(卫星程序集)通过各自资源目录中的区域性名称(例如fr-FR)找到;如果找不到这样的目录,则在找不到本地化资源的情况下,回调机制会查找最接近的可用实现语言,直到主要全球化程序集中使用的语言.
有关更多信息,请参见:
http://msdn.microsoft.com/en-us/library/21a15yht%28v = VS.100%29.aspx [ ^ ].



这是对常量的一些澄清,以响应下面的讨论:

By definition, you cannot localize a constant. (A constant is so constant, isn''t it? :-))

Before localization, you need to globalize the project. Basically, it means making the project functionality agnostic to the UI culture.

First, you need to get rid of all immediate constants (those hard-coded in your code), especially strings. For an intermediate step, you can turn them into constants explicitly defined in some (special) static class. In some projects there can be some constants that should never be localized anyway (but not always); in this case, mark this part of code clearly: "do not localize".

When you see what strings to localize, move them all to the resources. Let''s assume you use .resx resources. Create a resource file, add resource names and values. Now, open the auto-generated C# file; in project structure presented in Solution Explorer, it will be placed as a child node of the resource node. In this file, locate a static class with static properties; the name of the properties will be the same or resembling your names in the resource file. Now, simply use these names instead of constants in your code. As a result, all immediate constants should go, and all of the constants subject to localization are found in resources only.

Actually, there are more to globalization, but the step described above is the most important. You also need to make sure that your UI design can behave nicely when the lengths of all rendered strings change. You also should take care of correct and culture-independent processing of all kinds of data depending on culture, such as date-time formats, currency, presentation of numbers and the like. During localization, you will need to decide what to do with all the keyboard hot keys and test them for consistency.

Globalization is done, time to go to localization. For localization, you should never re-touch or modify your base globalized code. The main globalized assemblies remains the same during localization. The is the key idea of localization. Localized resource are added to solution, not replacing anything. The application should only be able to switch thread''s culture and UI culture.

Create satellite assemblies matching the structure of your globalized resources. Your build should place them in separate directories according to naming conventions for the cultures. When a culture of the application''s thread (let''s say, a main UI thread) is switches to a different one, the globalized application automatically selects the set of resources to be used. The resource assemblies (satellite assemblies) are found by a culture name (like fr-FR) in respective resource directory; if such directory is not found, the callback mechanism finds the nearest available implemented culture all the way down to the culture used in main globalized assemblies, in case no localized resource can be found.

For further information, see:
http://msdn.microsoft.com/en-us/library/21a15yht%28v=VS.100%29.aspx[^].



This is some clarification about constants, in response to discussion found below:

const string endPointAddressFormat = "https://www.myDomain.tld/myService&username={0}"; //explicit constant

//also constant by its semantic, but a function call requires a static field
static string endPointAddress = string.Format(endPointAddressFormat, "me");

const string exceptionFormat = @"{0}: {1}"; //another explicit constant

string message = "Does not work!"; //message is a variable, "Does not work!" is immediate constant -- VERY BAD PRACTICE
string betterMessage = string.Format(exceptionFormat, myException.GetType().Name, myException.Message); //MUCH better

//but moving exceptionFormat to resource would be the best



即使不应该对即时常量进行本地化,它也是不好的.他们将维护变成了噩梦.它们仅在开发期间是可接受且方便的.显式常量呢?这取决于.许多应移至配置数据文件或资源,但有些就可以了.

—SA



Immediate constants is bad even if it should not be localized. They turn maintenance into nightmare. They are acceptable and convenient only during development. How about explicit constants? It depends. Many should be moved to configuration data files or resources, but some are just fine.

—SA


这篇关于亲爱的人,请再帮忙的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆