How to localize enum values in the class

Question

0.00/5 (No votes)

See more:

Hello Friends,
I have facing one issue in my code. I will explain below of my scenarios :-
I have enum values like
public enum myValues
{
0 - Imported
1 - Exported
}

In my code I have compared the enum values with my 'input' value.

if (input.Contains(myValues.Imported))
{
//My IF Loop got processing in my code logic.....
}

Issue observed:
While I compared in English languvage in myValues consists of either Imported or Exported and its working fine and it enters to if loop and my logic got processing.

But When I change the language it doesn't works. For instance, I have changed the OS language from English to Italian. My input values comes importato ('Imported' in Italian language) or esportato ('Exported' in Italian language). In that case we have compared the enum values only Imported and Exported so the if loop got false and it moves to else case.

I request you all please give me suggestion how to handle the localization for Enum values.

I hope you understand better on my scenario.

Please help me!!!! Thanks in advance......

What I have tried:

I have tried using culture to compared which language currently is being worked. But I could not able to achieve it.

Posted 25-May-16 16:56pm

vasanthkumarmk

Updated 26-May-16 1:13am

Add a Solution

Comments

F-ES Sitecore 26-May-16 7:39am

The problem is that you are abusing enums. Use normal classes instead such that you can vary the text based on localisation, enums are not intended to be used the way you are using them, the text is simply a mnemonic for the integer value, it isn't a key\value pair.

3 solutions

Solution 3

I think there are two issues here:

1. the "global" issue of "localisation," which is a strategy you need to implement on an application-wide basis. typically, this will involve storing language-dependent strings as resources, and then, depending on the user's system-wide "culture settings," making sure the appropriate strings (or other items, like culture dependent decimal-point separators, etc.) are used [^].

2. the issue of validating a given string maps to a specific Enumeration value in an 'Enum:

C#

public enum TestEnum
{
    NoValue = 0,
    one,two,three
}

public TestEnum StringToTestEnum(string input, bool ignoreCase = false)
{
    TestEnum result;
    TestEnum.TryParse(input, ignoreCase, out result);
    return result;
}

Here the use of a special Enumeration value "NoValue" allows you to distinguish that no conversion is possible with a given string.

I think you need to make some strategic decisions about the number of languages your application may need to support in the future, and if non-Roman character sets will be used. There are many well-written resources on the web, and here, on CodeProject, dealing with language localisation issues, like: [^], [^], [^].

imho, dealing with how to make your code accept variable names, etc., in only two languages, for only certain objects in your application is a waste of time.

However, there are ways to differentially compile your code base, including use of #Define/#Undef/#If modifiers, using MEF: [^] to load code at run-time based on variables, etc. You can use ConditionalAttributes on Classes, and on methods whose return Type is 'void: [^].

Posted 26-May-16 1:13am

BillWoodruff

Solution 2

First of all, your comparison needs serious improvement. It's really bad to do any string comparisons, especially repeatedly. This should give you much better idea:

C#

static myValues? ParseMyValues(string input) {
    try {
        return (myValues)System.Enum.Parse(typeof(myValues), input);
    } catch { return null; }
}

I used nullable type by using '?', because parsing can fail. It will be successful if input is equal to one of the valid names of the enumeration values, which are the static fields of your enumeration type, exactly as they are declared, case-sensitive. In all other cases an exception will be thrown, which I suggested to catch and represent this failure to parse as null. Now you can compare enumeration values with enumeration values of the same class, processing null as invalid input separately.

Be extra careful with enumeration types having members with identical underlying integer values. In my simple example, they won't spoil the execution, but you should better be aware of the problem, which is described and solved in my article Enumeration Types do not Enumerate! Working around .NET and Language Limitations.

Now, what to do if you want to localize the solution? First of all, you should not localize and program identifiers. Well-known localization methods are based on resources. "Imported" should remain "Imported". If you want "Importato", it should be "importato" only into to resources and entered by the users. So, how to do the comparison?

One idea is suggested by Solution 1, with attribute, but this solution is not inline with the globalization/localization technology. In my other article from the enumeration series, I also use attribute, but in more advanced way; and one of the attributes redirects the representation values to a resource defined by the attribute. You can find the comprehensive explanation and source code in this article: Human-readable Enumeration Meta-data.

—SA

Posted 25-May-16 17:39pm

Sergey Alexandrovich Kryukov

Updated 25-May-16 17:51pm

v3

Comments

vasanthkumarmk 26-May-16 1:52am

Ok thanks, But in terms of localization how to achieve this?

Sergey Alexandrovich Kryukov 26-May-16 10:37am

You are welcome.
Two questions for you:
1) are you well familiar with .NET standard globalization technique based on satellite assemblies?
2) did you read my article I referenced at the end.
1+2 will give you a complete solution.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2016-05-25T17:04:00

Solution 1

You can't. Those names are to be used only inside your code.

You'd have to supply some attribute to each value, such as DescriptionAttribute[^]. You can find examples of how to localize the Description here[^].

Posted 25-May-16 17:04pm

Dave Kreskowiak

Comments

Sergey Alexandrovich Kryukov 25-May-16 23:56pm

Your idea is generally correct, but "those names are to be used only inside your code" doesn't sound clear or accurate. Probably, I understood it incorrectly, probably this is not what you really mean. Say, the word "Import" can be used as both enumeration value and input. What name "can be used only inside your code" than? Don't bother to explain; I think it's just awkward wording. Anyway, I up-voted the answer after all.

Oh, and addressing to Google for the problem of localization of Description is hardly very productive. I used to see so-o many really bad solution. It's not so good to put the inquirer to the risk of using some of them.

A while ago, I analyzed the problem in depth and put forward pretty robust solution; please see Solution 2.

—SA