Why is ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ the native name of the U.S.?
When I use this code:
var ri = new RegionInfo("us");
var nativeName = ri.NativeName; // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
why is nativeName
then the string "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ"
(in Cherokee)?
If I change to new RegionInfo("US")
(only difference, capital US
), I get instead "United States"
.
I do know the preferred usage of RegionInfo
is to give a specific culture info string such as:
new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")
and so on, and that works. But why is Cherokee preferred over English only if I use lower-case us
?
(Seen on Windows 10 (version 1803 "April 2018 Update"), .NET Framework 4.7.2.)
Update: This is not consistent, even on the same machine. For example I tried opening PowerShell very many times, each time pasting [System.Globalization.RegionInfo]'US'
into it. It seems like for a long period, all instances of PowerShell are consistently giving the same result. But then after a while, the instances of PowerShell then give the opposite result. Here is a screenshot of two of the windows, one consistently having one NativeName
, and the other one consistently having the opposite one. So there must be some non-deterministic determination going on (no difference in casing):
c# .net globalization casing regioninfo
|
show 7 more comments
When I use this code:
var ri = new RegionInfo("us");
var nativeName = ri.NativeName; // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
why is nativeName
then the string "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ"
(in Cherokee)?
If I change to new RegionInfo("US")
(only difference, capital US
), I get instead "United States"
.
I do know the preferred usage of RegionInfo
is to give a specific culture info string such as:
new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")
and so on, and that works. But why is Cherokee preferred over English only if I use lower-case us
?
(Seen on Windows 10 (version 1803 "April 2018 Update"), .NET Framework 4.7.2.)
Update: This is not consistent, even on the same machine. For example I tried opening PowerShell very many times, each time pasting [System.Globalization.RegionInfo]'US'
into it. It seems like for a long period, all instances of PowerShell are consistently giving the same result. But then after a while, the instances of PowerShell then give the opposite result. Here is a screenshot of two of the windows, one consistently having one NativeName
, and the other one consistently having the opposite one. So there must be some non-deterministic determination going on (no difference in casing):
c# .net globalization casing regioninfo
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
4
Even withUS
I getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad
– Panagiotis Kanavos
Nov 13 '18 at 16:35
9
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
From the docs: We recommend that you use the culture name ... Therefore, creating theRegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.
– DavidG
Nov 13 '18 at 16:44
2
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57
|
show 7 more comments
When I use this code:
var ri = new RegionInfo("us");
var nativeName = ri.NativeName; // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
why is nativeName
then the string "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ"
(in Cherokee)?
If I change to new RegionInfo("US")
(only difference, capital US
), I get instead "United States"
.
I do know the preferred usage of RegionInfo
is to give a specific culture info string such as:
new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")
and so on, and that works. But why is Cherokee preferred over English only if I use lower-case us
?
(Seen on Windows 10 (version 1803 "April 2018 Update"), .NET Framework 4.7.2.)
Update: This is not consistent, even on the same machine. For example I tried opening PowerShell very many times, each time pasting [System.Globalization.RegionInfo]'US'
into it. It seems like for a long period, all instances of PowerShell are consistently giving the same result. But then after a while, the instances of PowerShell then give the opposite result. Here is a screenshot of two of the windows, one consistently having one NativeName
, and the other one consistently having the opposite one. So there must be some non-deterministic determination going on (no difference in casing):
c# .net globalization casing regioninfo
When I use this code:
var ri = new RegionInfo("us");
var nativeName = ri.NativeName; // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
why is nativeName
then the string "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ"
(in Cherokee)?
If I change to new RegionInfo("US")
(only difference, capital US
), I get instead "United States"
.
I do know the preferred usage of RegionInfo
is to give a specific culture info string such as:
new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")
and so on, and that works. But why is Cherokee preferred over English only if I use lower-case us
?
(Seen on Windows 10 (version 1803 "April 2018 Update"), .NET Framework 4.7.2.)
Update: This is not consistent, even on the same machine. For example I tried opening PowerShell very many times, each time pasting [System.Globalization.RegionInfo]'US'
into it. It seems like for a long period, all instances of PowerShell are consistently giving the same result. But then after a while, the instances of PowerShell then give the opposite result. Here is a screenshot of two of the windows, one consistently having one NativeName
, and the other one consistently having the opposite one. So there must be some non-deterministic determination going on (no difference in casing):
c# .net globalization casing regioninfo
c# .net globalization casing regioninfo
edited Nov 13 '18 at 21:10
Jeppe Stig Nielsen
asked Nov 13 '18 at 16:31
Jeppe Stig NielsenJeppe Stig Nielsen
43.2k672130
43.2k672130
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
4
Even withUS
I getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad
– Panagiotis Kanavos
Nov 13 '18 at 16:35
9
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
From the docs: We recommend that you use the culture name ... Therefore, creating theRegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.
– DavidG
Nov 13 '18 at 16:44
2
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57
|
show 7 more comments
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
4
Even withUS
I getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad
– Panagiotis Kanavos
Nov 13 '18 at 16:35
9
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
From the docs: We recommend that you use the culture name ... Therefore, creating theRegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.
– DavidG
Nov 13 '18 at 16:44
2
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
4
4
Even with
US
I get ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad– Panagiotis Kanavos
Nov 13 '18 at 16:35
Even with
US
I get ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad– Panagiotis Kanavos
Nov 13 '18 at 16:35
9
9
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
From the docs: We recommend that you use the culture name ... Therefore, creating the
RegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.– DavidG
Nov 13 '18 at 16:44
From the docs: We recommend that you use the culture name ... Therefore, creating the
RegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.– DavidG
Nov 13 '18 at 16:44
2
2
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57
|
show 7 more comments
1 Answer
1
active
oldest
votes
The first thing to note is that the constructor for RegionInfo
finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.
Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.
For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey
, it's a case-sensitive search. So if you specify "US"
, it will find it, but not "us"
.
Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)
) for the region you gave, but it does so in a case-insensitive way.
I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US
before it gets to en-US
.
Why is it not consistent?
One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US"
and Cherokee when using "us"
, like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US"
and "us"
. So maybe it has something to do with the exact runtime version targetted, I can't say for sure.
One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.
You can test this. We know that using "US"
vs. "us"
will yield different results, but try this in the same program:
var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;
Then swap them and run it again:
var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;
Both results will always be equal because the first culture is cached and used for the next.
It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.
Conclusion
All that said, the docs actually say:
We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.
So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.
If you want to guarantee English, then either:
- Do as Microsoft recommends and specify the language with the region: "en-US", or
- Use the
EnglishName
orDisplayName
properties (which are English even when theNativeName
is Cherokee).
1
The reason why some people getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and someUnited States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will printUnited States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.
– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it allNote: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for bothus
andUS
on FW3.5, and only Cherokee for bothus
andUS
with FW4.0 and up.
– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
|
show 4 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53285491%2fwhy-is-%25e1%258f%258c%25e1%258f%258a-%25e1%258e%25a2%25e1%258f%25b3%25e1%258e%25be%25e1%258e%25b5%25e1%258f%258d%25e1%258f%2594%25e1%258f%2585-%25e1%258f%258d%25e1%258e%25a6%25e1%258f%259a%25e1%258e%25a9-the-native-name-of-the-u-s%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The first thing to note is that the constructor for RegionInfo
finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.
Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.
For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey
, it's a case-sensitive search. So if you specify "US"
, it will find it, but not "us"
.
Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)
) for the region you gave, but it does so in a case-insensitive way.
I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US
before it gets to en-US
.
Why is it not consistent?
One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US"
and Cherokee when using "us"
, like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US"
and "us"
. So maybe it has something to do with the exact runtime version targetted, I can't say for sure.
One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.
You can test this. We know that using "US"
vs. "us"
will yield different results, but try this in the same program:
var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;
Then swap them and run it again:
var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;
Both results will always be equal because the first culture is cached and used for the next.
It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.
Conclusion
All that said, the docs actually say:
We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.
So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.
If you want to guarantee English, then either:
- Do as Microsoft recommends and specify the language with the region: "en-US", or
- Use the
EnglishName
orDisplayName
properties (which are English even when theNativeName
is Cherokee).
1
The reason why some people getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and someUnited States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will printUnited States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.
– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it allNote: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for bothus
andUS
on FW3.5, and only Cherokee for bothus
andUS
with FW4.0 and up.
– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
|
show 4 more comments
The first thing to note is that the constructor for RegionInfo
finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.
Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.
For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey
, it's a case-sensitive search. So if you specify "US"
, it will find it, but not "us"
.
Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)
) for the region you gave, but it does so in a case-insensitive way.
I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US
before it gets to en-US
.
Why is it not consistent?
One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US"
and Cherokee when using "us"
, like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US"
and "us"
. So maybe it has something to do with the exact runtime version targetted, I can't say for sure.
One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.
You can test this. We know that using "US"
vs. "us"
will yield different results, but try this in the same program:
var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;
Then swap them and run it again:
var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;
Both results will always be equal because the first culture is cached and used for the next.
It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.
Conclusion
All that said, the docs actually say:
We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.
So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.
If you want to guarantee English, then either:
- Do as Microsoft recommends and specify the language with the region: "en-US", or
- Use the
EnglishName
orDisplayName
properties (which are English even when theNativeName
is Cherokee).
1
The reason why some people getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and someUnited States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will printUnited States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.
– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it allNote: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for bothus
andUS
on FW3.5, and only Cherokee for bothus
andUS
with FW4.0 and up.
– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
|
show 4 more comments
The first thing to note is that the constructor for RegionInfo
finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.
Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.
For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey
, it's a case-sensitive search. So if you specify "US"
, it will find it, but not "us"
.
Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)
) for the region you gave, but it does so in a case-insensitive way.
I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US
before it gets to en-US
.
Why is it not consistent?
One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US"
and Cherokee when using "us"
, like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US"
and "us"
. So maybe it has something to do with the exact runtime version targetted, I can't say for sure.
One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.
You can test this. We know that using "US"
vs. "us"
will yield different results, but try this in the same program:
var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;
Then swap them and run it again:
var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;
Both results will always be equal because the first culture is cached and used for the next.
It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.
Conclusion
All that said, the docs actually say:
We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.
So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.
If you want to guarantee English, then either:
- Do as Microsoft recommends and specify the language with the region: "en-US", or
- Use the
EnglishName
orDisplayName
properties (which are English even when theNativeName
is Cherokee).
The first thing to note is that the constructor for RegionInfo
finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.
Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.
For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey
, it's a case-sensitive search. So if you specify "US"
, it will find it, but not "us"
.
Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)
) for the region you gave, but it does so in a case-insensitive way.
I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US
before it gets to en-US
.
Why is it not consistent?
One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US"
and Cherokee when using "us"
, like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US"
and "us"
. So maybe it has something to do with the exact runtime version targetted, I can't say for sure.
One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.
You can test this. We know that using "US"
vs. "us"
will yield different results, but try this in the same program:
var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;
Then swap them and run it again:
var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;
Both results will always be equal because the first culture is cached and used for the next.
It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.
Conclusion
All that said, the docs actually say:
We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.
So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.
If you want to guarantee English, then either:
- Do as Microsoft recommends and specify the language with the region: "en-US", or
- Use the
EnglishName
orDisplayName
properties (which are English even when theNativeName
is Cherokee).
edited Nov 14 '18 at 14:18
answered Nov 13 '18 at 16:53
Gabriel LuciGabriel Luci
10.8k11424
10.8k11424
1
The reason why some people getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and someUnited States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will printUnited States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.
– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it allNote: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for bothus
andUS
on FW3.5, and only Cherokee for bothus
andUS
with FW4.0 and up.
– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
|
show 4 more comments
1
The reason why some people getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and someUnited States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will printUnited States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.
– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it allNote: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for bothus
andUS
on FW3.5, and only Cherokee for bothus
andUS
with FW4.0 and up.
– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
1
1
The reason why some people get
ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and some United States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will print United States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.– FCin
Nov 13 '18 at 17:36
The reason why some people get
ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
and some United States
is most probably, because they target different .NET Framework versions. If you compile OP code against .NET Framework 3.5 or lower it will print United States
. "chr-Cher-US" was probably added in later versions of .NET Framework and that's why "en-US" is found first in dictionary.– FCin
Nov 13 '18 at 17:36
This comment in the RegionInfo constructor says it all
Note: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
This comment in the RegionInfo constructor says it all
Note: We prefer that a region be created with a full culture name (ie: en-US) because otherwise the native strings won't be right.
– bastos.sergio
Nov 13 '18 at 17:52
1
1
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for both
us
and US
on FW3.5, and only Cherokee for both us
and US
with FW4.0 and up.– GSerg
Nov 13 '18 at 18:32
@FCin It is apparently very device dependent. On my machine I'm reliably getting only "United States" for both
us
and US
on FW3.5, and only Cherokee for both us
and US
with FW4.0 and up.– GSerg
Nov 13 '18 at 18:32
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@GSerg Why do you say it's device dependent? Changing the framework version would make it framework version dependent.
– Amy
Nov 13 '18 at 18:36
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
@Amy Because I'm getting one result with e.g. FW4.5 and other people are getting a different result also with FW4.5. I'm not saying it is necessarily device dependent (as in, hardware), but it is evidently not limited to just .NET version.
– GSerg
Nov 13 '18 at 18:37
|
show 4 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53285491%2fwhy-is-%25e1%258f%258c%25e1%258f%258a-%25e1%258e%25a2%25e1%258f%25b3%25e1%258e%25be%25e1%258e%25b5%25e1%258f%258d%25e1%258f%2594%25e1%258f%2585-%25e1%258f%258d%25e1%258e%25a6%25e1%258f%259a%25e1%258e%25a9-the-native-name-of-the-u-s%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Could be a bug. The documentation says "Case is not significant." Of course, it also says, "You should provide the name of a specific culture rather than just a country/region name in the name parameter."
– Heretic Monkey
Nov 13 '18 at 16:35
4
Even with
US
I getᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ
in Linqpad– Panagiotis Kanavos
Nov 13 '18 at 16:35
9
To be fair, the Cherokee were in the US before it was the US :).
– Heretic Monkey
Nov 13 '18 at 16:37
From the docs: We recommend that you use the culture name ... Therefore, creating the
RegionInfo
object with only a country/region name of US is not specific enough to distinguish the appropriate string.– DavidG
Nov 13 '18 at 16:44
2
@DavidG: Those documents don't suggest anything like the behavior being undefined, unpredictable or unsupported when a two-letter code is provided. They're just advising developers to provide the culture name for best results and handwaving it otherwise. If this behavior is intentional or otherwise not a bug, there must be a reason for it...
– BoltClock♦
Nov 13 '18 at 16:57