What's the intended behavior of IStringLocalizer in regards to format strings?

[aspnet-hello]

From @hiiru on Monday, March 20, 2017 2:44:38 PM

Background:
The reason of this question is a difference between Localization's IStringLocalizer and Mvc.Localization's IViewLocalizer which I noticed last week, or rather in their official implementations (ResourceManagerStringLocalizer and ViewLocalizer).
Initially I created a PR in Localization (aspnet/Mvc#5962) since I think of this as a bug, during review @dougbu @pranavkm pointed out that intended behavior isn't clear. Before deciding on a way to change this, since it would break the currently shipped behavior, it should be clarified here in the Localization repo so the right approach can be chosen.

The ResourceManagerStringLocalizer behaves like this:
this[name] -> returns raw string
this[name, arguments] -> returns string.format of raw string and arguments

The ViewLocalizer like this:
this[name] -> returns string.format of raw string with empty arguments
this[name, arguments] -> returns string.format of raw string and arguments
Actually a LocalizedHtmlString, however during response rendering it's changed to the described behavior when WriteTo is called.

There is also a code example of this here: https://github.com/hiiru/LocalizationBugExample

Before creating this issue I looked at the tests, comments and documentation of Localization, however I didn't find anything that explicitly describes the behavior.
Also I didn't see any test for the this[name, arguments] signature at all (based on dev branch), nor is any test related to formatted strings.

In my opinion, I think the IStringLocalizer implies the current behavior of ResourceManagerStringLocalizer due to the minor comment difference between both this[] comments.
Also I wouldn't expect a string.format when I don't provide arguments.

Question:
What is the intended behavior of IStringLocalizer's this[name]?
Should this return a raw string or a formatted string?

Copied from original issue: aspnet/Localization#346

[aspnet-hello]

From @dougbu on Monday, March 20, 2017 4:05:55 PM

@DamianEdwards says "no, I don't want to type". He also mentioned this sounds like "just a bug" when described this way. @DamianEdwards prefers to fix ViewLocalizer and to provide a flag or option somewhere to control it. He left it as an implementation detail whether we change the default behaviour or not.

In other words, he asked Triage to do the Right Thing:tm:.

[aspnet-hello]

From @hiiru on Tuesday, March 21, 2017 1:09:12 PM

Ok, I'll update my PR so that the behavior is managed by a flag/option, any further detail we can discuss inside the PR in Mvc.

Since this doesn't directly involve Localization anymore, I close this issue here.

[aspnet-hello]

From @dougbu on Tuesday, March 21, 2017 1:21:32 PM

Reopening because Triage members have not weight in on this issue or the milestone where it might be addressed.

[mkArtakMSFT]

Closing this issue as there was no community involvement for quite a while now.

[anisite]

Hi, I have this issue with .net core 3.0, why don't simply add a condition to skip the string.format when no arguments?

[mkArtakMSFT]

Hi @anisite.

It looks like you are posting on a closed issue!
We're very likely to lose track of your bug/feedback/question unless you:

1. Open a new issue
2. Explain very clearly what you need help with
3. If you think you have found a bug, include detailed repro steps so that we can investigate the problem