Is it possible to create new locales or update an existing one in Net 6?

[JosepBalague]

Hi folks,

I need create a new locale with new Abbreviated Month Names. I don't want to wrap outputs. The starting point of my tests is https://github.com/dotnet/runtime/issues/23802 (closed without resolution).

I downloaded Locale Builder (according to the comments of @tarekgh at https://github.com/dotnet/runtime/issues/23802#issuecomment-335852001). Afterwards I created a new culture:

1. Based on ca-AD,
2. Set New LocaleName = ca-AD Yes, same name as based on because: a) I don't understand because I can't modify a current locale. b) installer of step 4 fails when I use ca-test-AD for example.
3. Set new values for Abbreviated Month Names:

4. Build locale installer (ca-AD.msi)
5. Save project as ca-AD.ldml ca-AD.zip

As extra steps I have installed ca-AD.msi (with a message about overwrite locale) and rebooted PC.

Code testing:

`using System.Globalization;

var abbreviated_Month = new CultureInfo("ca-AD").DateTimeFormat.AbbreviatedMonthNames;

foreach (var item in abbreviated_Month) { Console.WriteLine(item); }

Console.ReadKey();`

Output that fails:

Desired output: gen feb mar abr mai jun jul ago set oct nov dec

Where is failing? When CultureAndRegionInfoBuilder will be available in Net core? There is not references in https://themesof.net/?q=CultureAndRegionInfoBuilder

Thanks.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-globalization See info in area-owners.md if you want to be subscribed.

Issue Details

---

Hi folks, I need create a new locale with new Abbreviated Month Names. I don't want to wrap outputs. The starting point of my tests is https://github.com/dotnet/runtime/issues/23802 (closed without resolution). I downloaded Locale Builder (according to the comments of @tarekgh at https://github.com/dotnet/runtime/issues/23802#issuecomment-335852001). Afterwards I created a new culture: 1. Based on ca-AD, 2. Set New LocaleName = ca-AD Yes, same name as based on because: a) I don't understand because I can't modify a current locale. b) installer of step 4 fails when I use ca-test-AD for example. 3. Set new values for Abbreviated Month Names:    4. Build locale installer (ca-AD.msi) 5. Save project as ca-AD.ldml [ca-AD.zip](https://github.com/dotnet/runtime/files/9606280/ca-AD.zip) As extra steps I have installed ca-AD.msi (with a message about overwrite locale) and rebooted PC. Code testing: `using System.Globalization; var abbreviated_Month = new CultureInfo("ca-AD").DateTimeFormat.AbbreviatedMonthNames; foreach (var item in abbreviated_Month) { Console.WriteLine(item); } Console.ReadKey();` Output that fails:  Desired output: gen feb mar abr mai jun jul ago set oct nov dec Where is failing? When CultureAndRegionInfoBuilder will be available in Net core? There is not references in https://themesof.net/?q=CultureAndRegionInfoBuilder Thanks.

Author:	jmroyb
Assignees:	-
Labels:	`area-System.Globalization`, `untriaged`
Milestone:	-

[Clockwork-Muse]

I need create a new locale with new Abbreviated Month Names. I don't want to wrap outputs.

... ignoring the specific report here, why do you want to do this? Generally locales should be pulled in from the OS without your program knowing anything/caring about the contents. About the only time you'd want to do something like this is for back-compat with an API returning differently localized data, but in such a case you should probably create a specific CultureInfo/DateTimeFormatInfo inside your application (and pass it to the relevant parsing/formatting methods).

[tarekgh]

@jmroyb starting from .NET 5.0 and we fully depend on ICU library. So, creating custom locale is not going to work anymore as it is a legacy NLS thing. You can switch to the old NLS mode if you want to get that behavior. For ICU, I don't think there is a safe way to add custom locales without building your own copy of ICU after adding your custom locale data. Then you can use app-local ICU to use whatever version of ICU you built.

The other idea is to overwrite the month names programmatically by overwriting the property DateTimeFormatInfo.AbbreviatedMonthNames for the desired culture.

I am closing the issue but feel free to send any more question we can help with. Also, it will be good to answer @Clockwork-Muse question as it is a good question to understand what your scenario is requiring you to do so.

[JosepBalague]

@tarekgh: The specification is to incorporate days and months names of dialects and local languages of ca. As I don't know C/C++ at the moment I overwrite the AbbreviatedMonthNames as you advise, although the method will be huge and difficult to maintain when it is extended.

@Clockwork-Muse: Your suggestion to create the CultureInfo/DateTimeFormatInfo within the app, in a library, seems correct to me: I'm evaluating how to use the xml generated by LocaleBuilder (the LDML File) to feed the months and days of CultureInfo/DateTimeFormatInfo in app. LDML is very simple to manage with LocaleBuilder.

@tarekgh: "For ICU, I don't think there is a safe way to add custom locales without building your own copy" It would be interesting to have a mechanism similar to LocaleBuilder that generates this dll for an app...

Thanks both for your help

[Clockwork-Muse]

It would be interesting to have a mechanism similar to LocaleBuilder that generates this dll for an app

The point is that you shouldn't (need to) do this; the locales are provided by the OS (and to an extent tweakable by the user), and your program doesn't worry about the contents.

The specification is to incorporate days and months names of dialects and local languages of ca.

Generally, applications shouldn't know anything about what the local formatting is. The question really is more "Is there a reason you can't/aren't using the built-in localization data the OS provides?". Because there are multiple reasons to not bundle such data with your application, if you can avoid it. Especially since you may not have a guarantee that the user is actually using that locale.

I'm evaluating how to use the xml generated by LocaleBuilder (the LDML File) to feed the months and days of CultureInfo/DateTimeFormatInfo in app

Don't. The point of my suggestion was predicated on the assumption that you're shimming an API that's returning localized data with a small set of known values, and there wouldn't be a payoff/reason to read (custom) localization files. The real solution is to yell at the API provider to stop localizing data values.

[JosepBalague]

Clockwork-Muse: Yes I agree with "the locales are provided by the OS". As a member of a linguistic minorities, I must look for other mechanisms to have locales not provided by the OS.

[tarekgh]

As a member of a linguistic minorities, I must look for other mechanisms to have locales not provided by the OS.

You can still request adding such locales. https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/boards/12.