Interpolation and concatenation too

[wizofaus]

The default thread UI culture is used for string interpolation and concatention too, and this isn't straightforward to change. For any sort of backend server it arguably makes far more sense just to ensure each thread is set to use InvariantCulture by default.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: dead2df6-1ec5-b55c-89aa-d05a7a75a0eb
• Version Independent ID: fe538551-dcfc-c244-3f16-864d3f6c2a6e
• Content: Best Practices for Using Strings in .NET
• Content Source: docs/standard/base-types/best-practices-strings.md
• Product: dotnet
• GitHub Login: @rpetrusha
• Microsoft Alias: ronpet

[rpetrusha]

For string interpolation, specifying a culture other than the current culture just involves a few additional steps, @wizofaus, which are documented in the string interpolation articles for C# and Visual Basic. It requires that you assign the interpolated string to a FormattableString object, then call its ToString method with the culture whose conventions you want to use.

I'm going to close this issue, since the Best Practices topic doesn't discuss composite format strings, and since culture-specific formatting with interpolated strings is appropriately documented. If you disagree, however, please feel free to respond.

[wizofaus]

I do disagree, because most of the cases I see these days where numbers/dates get formatted incorrectly on machines running in non-en-US locales are with string interpolation and concatenation.
Worse, the FxCop style anaylzers can't pick these cases up (I'm sure there must be other tools that do).
That the article doesn't mention interpolation or concatenation ("auto"/implied ".ToString()") at all strikes me as an oversight worth addressing.

[rpetrusha]

Thanks for responding, @wizofaus, and providing additional justification. You've made a compelling case, and (I have to confess) I was a bit hasty. In reviewing the article, I didn't notice that formatting was discussed at all (and that the content is very dated, since it was written shortly after the release of .NET Framework 2.0) and only noticed the content that focused on string comparison. I'll reopen this issue and schedule some time to address it.

Again, thanks for your persistence, @wizofaus.