CultureAndRegionInfoBuilder is sealed and, therefore, cannot be inher-
The CultureXmlReader and CultureXmlWriter classes that read and
write LDML files are both internal and sealed; therefore, they cannot be inherited from and cannot even be accessed.
The NLP file format is binary and proprietary.
To work around these limitations, you must implement a layer on top of the cus- tom culture architecture. The essential idea is to create a CultureAndRegion- InfoBuilderEx class that encapsulates the CultureAndRegionInfoBuilder class. The new class would be a duplicate of the CultureAndRegionInfoBuilder class and would redirect all properties and methods from the “fake” CultureAnd- RegionInfoBuilderEx class to the CultureAndRegionInfoBuilder class. The Register method would save the additional CultureInfoEx information to a pri- vate area in an LDML file (e.g., “bn-BD.ldml”), and this file would be installed in the Windows Globalization folder. The Unregister method would delete/rename the additional file. The Save method would write the additional information to the LDML file, and the CreateFromLdml method would load the additional information from the LDML file. Finally, the CultureInfoEx constructor would check to see if the culture is a custom culture and, if so, would load the additional information from the associated additional information file.
Custom Cultures and .NET Framework Language Packs
The .NET Framework draws the resources it needs from both the operating system and the framework’s resources. In particular resources, such as exception messages, PrintPreviewDialog, CultureInfo.DisplayName, and RegionInfo.Display- Name are all drawn from the .NET Framework Language Pack that matches the |CultureInfo.CurrentUICulture. Of course, for supplemental custom cultures, no such language pack exists, so the resources fall back to English. You can do very little about this. Whereas it is technically possible to create your own .NET Frame- work Language Pack for your own language, there is no value in doing so because you cannot sign the assembly with the same key used to sign the .NET Framework