better i18n Accept-Language parsing to properly support examples (+ as standalone function) #1850
Conversation
there is now a function to replicate the default behaviour of a translation context (as returning null simply uses the first element in languages) + the cases that were advertised in the examples (like rewriting en_GB to en_US if only that is available) actually work now and are unittested. Validation for checking if there are ambigious languages in the allowed languages is still not implemented, but documented how it should be done to avoid issues.
web/vibe/web/i18n.d
Outdated
| /// ditto | ||
| public string determineLanguageByHeader(Tuple...)(HTTPServerRequest req, Tuple allowed_languages) @safe pure | ||
| { | ||
| return determineLanguageByHeader(req.headers.get("Accept-Language", null), [allowed_languages]); |
| if (lcode == alang && !lextra.length) | ||
| return lang; | ||
| // request en* == serve en_* && be first occurence | ||
| if (lcode == alang && lextra.length && !fallback.length) |
There was a problem hiding this comment.
There is one fallback case missing here: determineLanguageByHeader("en_US,enCA", ["en_GB"]) == "en_GB"). This should ideally still apply, though: determineLanguageByHeader("en_US,enCA", ["en_GB", "en"]) == "en").
There was a problem hiding this comment.
those tests already work, assuming the allowed_languages argument is valid (most generic languages should be to the right of the specific ones)
There was a problem hiding this comment.
Nevermind, I misread this as !lextra.length and it's actually fine like it is.
web/vibe/web/i18n.d
Outdated
| /// ditto | ||
| public string determineLanguageByHeader(Tuple...)(string accept_language, Tuple allowed_languages) @safe pure | ||
| { | ||
| return determineLanguageByHeader(accept_language, [allowed_languages]); |
There was a problem hiding this comment.
[allowed_languages] -> std.range.only(allowed_languages) to avoid GC allocations.
|
I only changed the behaviour of the documented unittest (example on the website) to show that you should do this instead of returning null because it gives the user the best user experience if the programmer overrides the provider to support cookies, etc. Before it would default to the first language in the array (en_US) if if wasn't in the session which would mean that potential matches of the Accept-Language header were lost. |
there is now a function to replicate the default behaviour of a translation context (as returning null simply uses the first element in languages) + the cases that were advertised in the examples (like rewriting en_GB to en_US if only that is available) actually work now and are unittested.
Validation for checking if there are ambigious languages in the allowed languages is still not implemented, but documented how it should be done to avoid issues.
I couldn't find the examples (http://vibed.org/docs#web-localization) in the repository so I didn't change the documentation there that now you can also use
en-USor simplyen(generic international fallback english) as language tags, but I added it to thetranslationContextdocumentation.