Introduce way to disable localization support

[marek-safar]

The localization support for dotnet/runtime comes with a noticeable cost for workloads which are size sensitive and would be fine with English only.

The primary costs come from

• linker not being able to remove resource entries which are not needed
• ResourceManager implementation which is redundant for a single locale

There should be a way to switch to English mode only perhaps using some extra linker logic which converts .resources back to strings.

/cc @danmosemsft @vitek-karas @eerhardt

[danmoseley]

ProjectN went further, I think, and replaced exception strings with ID'S (?). Not sure how desirable that is given often some are visible to users.

[vitek-karas]

We actually went somewhat back on that decision and the shared library (I think in .NET Native 2.0) included full exception messages as the UX was pretty bad with just the IDs. I think a better way would be to try to teach linker to trim resource strings if they're not used anywhere (if we can reliably detect that - which might be pretty hard).

[MichalStrehovsky]

Project N only went back because when we introduced replacing exception messages with resource strings, we didn't have an option to turn this off and some developers wanted to turn it off.

It's a pretty significant saving and frankly if the app makes the exceptions user-facing, turning "Arg_DecBitCtor" into "Decimal constructor requires an array or span of four valid decimal bytes." doesn't help anyone but the developer. We shipped a CSV with the mapping. I think it would be a valuable option to expose. The CoreRT compiler can do it and saves 433 kB on Hello World when this is enabled (or at least it did when this option was introduced).

For the "let's replace resources with inline strings instead" approach, we might want to wait until there's internal support for UTF-8 string literals - resource strings are stored as UTF-8, but string literals are UTF-16, so we would be getting rid of resource manager, but doubling the string data itself - we can do better than that.

[marek-safar]

@danmosemsft I don't think there is an appetite for removing the string altogether, this might be interesting super optimization but I don't think it'd be used in wild.

Using string literals as the keys for location is probably the most elegant solution but I fear the model of using IDs for localization for decades is something I'll have a hard time to convince others to switch from.

[eerhardt]

Would this support only be for CoreLib/BCL or would it also apply to 3rd party libraries?

[marek-safar]

Ideally for everything but BCL + our core SDKs need to be in the first wave

[danmoseley]

teach linker to trim resource strings if they're not used anywhere

That has the considerable appeal of not affecting the user experience. So I do hope we can at least do that part. But as an aside, for my education, is corelib itself typically trimmable much? Or too central/heavily used/interconnected and most is retained?

[danmoseley]

if the app makes the exceptions user-facing, turning "Arg_DecBitCtor" into "Decimal constructor requires an array or span of four valid decimal bytes." doesn't help anyone but the developer.

Right, but there may be plenty of apps that anticipate the ones their users will see are reasonable like Could not find file '{0}'. .

[marek-safar]

their users will see are reasonable like

For most apps the user-facing aspect of exception messages does not matter but the developers care a lot about actionable messages in their logs.