-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Obsolete ResourceManagerWithCultureStringLocalizer
and WithCulture
interface member
#3324
Comments
Or we can move |
@ryanbrandenburg can we mark them as |
Yeah, marking them as Obsolete would probably be step one, but this is just a suggestion on my part at this point. We'll have to talk it over with @mkArtakMSFT and probably @DamianEdwards to decide if they want this and what the plan would be first. |
Sound good .. hope you check my earlier points in the issue that I referenced with them too .. |
Another issue in |
@ryanbrandenburg any updates on this? |
@mkArtakMSFT any update on this? Can we mark the types as |
ResourceManagerWithCultureStringLocalizer
and WithCulture
interface memberResourceManagerWithCultureStringLocalizer
and WithCulture
interface member
The ResourceManagerWithCultureStringLocalizer and WithCulture interface member are often sources of confusion for users of Localization, especially if they want to create their own
IStringLocalizer
implementation. These items give the user the impression that we expect anIStringLocalizer
instance to be "per-language, per-resource", when actually they should only be "per-resource", with the language searched for determined by theCultureInfo.CurrentUICulture
at execution time.Neither of these has any usage that I was able to find with a cursory search, and it's difficult for me to imagine when they would be the correct option, so let's just get rid of them in 3.0.
The text was updated successfully, but these errors were encountered: