Localize apphost error page

[richlander]

There was a request on our host improvements post to localize our host error messages (specifically relating to the download the runtime UX). That sounds like a good idea. We should consider it.

@elinor-fung @vitek-karas

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There was a request on our host improvements post to localize our host error messages (specifically relating to the download the runtime UX). That sounds like a good idea. We should consider it.

@elinor-fung @vitek-karas

Author:	richlander
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

@elinor-fung did investigation on this topic and wrote some ideas here: https://github.com/dotnet/runtime/blob/main/docs/design/features/localization-options.md

[deeprobin]

I have often heard that we want to keep the host relatively small (in size). With the localization option, I think the executable becomes significantly larger.

Is this planned only for the "normal" host or also for the singlefilehost?

[vitek-karas]

Right now there's not specific plan - but the customer ask is actually mostly about the apphost, so the one which is very size sensitive. I don't know what the solution should be... maybe we will need a way in the SDK to determine the language up front, so that if you build the app for Spanish only, then it will only carry Spanish error messages and nothing else.

That said, the errors in the apphost itself are only very few - most of the logic and thus errors are in the hostfxr and hostpolicy components which are shared. So for framework dependent apps, it could make sense to include all languages and just pick the right one at runtime. But then self-contained apps are unnecessarily larger... and so on.

We could also consider localizing just the UI for now, as that's where this ask comes from most frequently. So Windows-only and just the text which is shown in the dialog box.

[richlander]

That thinking makes sense to me.

I am wondering if we want to start with the (shared) dotnet host localization topic first. That would help developers and is still worthwhile.

We might approach the apphost localization topic at the same time as updating the UI. Our approach there might influence the technical localization plan.

I am wondering if we end up with a bare bones experience and then a fancy one and then let people choose. I have this feeling that it is going to be very hard to provide a fancy experience that works for all scenarios.

[agocke]

Multiplying hosts is likely to be pretty expensive, partially because once we scale past one or two we'll have to build dedicated infrastructure to handle the building and publishing (not to mention testing).

[richlander]

Agreed on that. We need to spend some more time thinking about how to deliver a better experience.