Add some globalization recommendations for best practices.

[Clockwork-Muse]

Summary

This issue is the documentation side of attempting to deal with issues submitted to the runtime about globalization data errors.

Most of the original text from the original runtime PR was already available in various parts of the existing globalization documentation; so far this PR has only adjusted the best-practices documentation.

Do we still fill we need a small "initial troubleshooting" doc?

cc @jkotas @tarekgh @ericstj

---

Internal previews

📄 File	🔗 Preview link
docs/core/extensions/best-practices-for-developing-world-ready-apps.md	Best practices for developing world-ready applications
docs/core/extensions/globalization-icu.md	"Globalization and ICU"

[Clockwork-Muse]

Status checker is complaining about 2 remaining absolute links, but neither link is part of this repo. What's the way I should handle it? Still make it relative, assuming that those links would normally be part of the same root regardless?

[IEvangelist]

Status checker is complaining about 2 remaining absolute links, but neither link is part of this repo. What's the way I should handle it? Still make it relative, assuming that those links would normally be part of the same root regardless?

Anything that has the learn.microsoft.com host should be relative link instead.

[IEvangelist]

These are good additions, thank you! I have some nits and suggestions for improvement, after that I think we can .

[Clockwork-Muse]

@jkotas @IEvangelist -
I have a section that reads:

"The data for a culture isn't what it should be!"

The ICU libraries use the Unicode Common Locale Data Repository (CLDR) as a datasource. This data is not maintained by the runtime SDK, nor (outside of legacy Windows applications) by the host OS. If you believe there is an error in the data, please follow the CLDR directions on submitting a ticket.

Some of the issues that get reported on the main runtime repo are about this sort of thing. I feel like I maybe want to point people at the CLDR for this sort of thing, but I'm not quite sure where. I can add it to the runtime bug template (or a ███ could auto-reply), or as a footnote to one of the globalization files here. Thoughts?

Note

This content was automatically updated to filter out profanity. If you feel as though this was done in error, please file an issue with the details.

[jkotas]

Some of the issues that get reported on the main runtime repo are about this sort of thing. I feel like I maybe want to point people at the CLDR for this sort of thing, but I'm not quite sure where. I can add it to the runtime bug template (or a ███ could auto-reply), or as a footnote to one of the globalization files here. Thoughts?

Linking to CLDR as the data source in the docs is good idea. I would avoid duplicating instruction for how to file tickets against CLDR in .NET docs. The instructions for that are not that hard to find in the CLDR page. I think it is a good idea to make people slow down and think a bit more before they file CLDR issue to avoid creating noise in the CLDR issue tracker.

I do not think we need to automate this. It is good enough to have a response like
"This globalization issue is by design. Please check for more information." that a human uses to close the issue. (Some of our feature teams have a catalog of standard responses like this that they use to close frequently filled by-design issues.)