search

turquoiseowl / i18n

Smart internationalization for ASP.NET
Other
556 stars 156 forks source link

278 configurable headercheck #285

Closed Jandev closed 7 years ago

Jandev commented 7 years ago

Created delegate to let the developers decide what functionality should be implemented when parsing the user request languages. Necessary if you want to skip the "Accept-Language"-header.

This should resolve #278

turquoiseowl commented 7 years ago

Looks very good! Thanks for the contribution.

Jandev commented 7 years ago

Thanks! Is there an interval you use for creating new Nuget packages, or is it random?

I'm asking so we know when to expect the functionality in a public package.

turquoiseowl commented 7 years ago

I'll push a new package over the weekend.

jeancroy commented 7 years ago

I just wanted to share that history item Support for ignoring Accept-Language request header Points to this PR. However how to implement said feature is not trivial nor documented.

The problem lie in the fact that said delegate return an array of LanguageItem, a data structure specialized for dealing with Accept-Language request header and the relative scoring of each item.

First I tried to return an empty array. Unfortunately that result in index out of bound exception later.

i18n.HttpContextExtensions.GetRequestUserLanguagesImplementation =
    (context) => new LanguageItem[] {  };

Then I tried to return the default language. Unfortunately this involve faking ranks & magic numbers.

i18n.HttpContextExtensions.GetRequestUserLanguagesImplementation = 
  (context) => 
     new[] { new LanguageItem(LocalizedApplication.Current.DefaultLanguageTag, 1.0f, 0) };

This seems better however there's a comment that explicitly warn against using this