If I do a search with an invalid locale, I get an empty result set with no explanation of what happened. This makes it difficult to use the API especially where locales are added and removed from SUMO periodically. It would be better for SUMO to return an HTTP 400 error for invalid locales making it easier for the client to handle it accordingly.

This doesn't technically block bug #1133769 in that I can probably go forward without this, but it should for a correct implementation since the Input side will need to handle this situation correctly.

Grabbing this one to look into.

Mike said we need to check settings.SUMO_LANGUAGES and settings.NON_SUPPORTED_LOCALES. Something like this pseudo-code: if locale not in settings.SUMO_LANGUAGES: return Http400 if locale in settings.NON_SUPPORTED_LOCALES: return Http400

I'm sorry, I was unclear on irc. If you are just going to throw an error for NON_SUPPORTED_LOCALES, you don't need to check it. All the locales in NON_SUPPORTED_LOCALES are *not* in SUMO_LANGUAGES, so that second `if` you have will never be relevant. I only meant to say that you might want to not throw errors for the NON_SUPPORTED_LOCALES, and instead use their fallback behavior (for example, br -> fr or sv-SE -> sv). If you don't want to do the fallback, you can just raise Http400 anyways. I only mentioned it because I wasn't sure how Input would want to treat those locales.

Oh, I see. Let's think beyond the Input case. What's the correct thing for this API endpoint to do? Should it convert the locale to the fallback locale for NON_SUPPORTED_LOCALES? Should it ignore them altogether?

If I set the locale to 'ach' and do a search, presumably I am trying do a search with ach keywords. If we redirect those searches to English (as the NON_SUPPORTED_LOCALES mapping directs), the search quality probably won't be very good. But then, maybe the search quality will be good enough. We use NSL to send people to a language that is likely better than nothing. Maybe a search in the wrong language is better than nothing. On the other hand, I think that the API should be stricter about validation that the normal UI. The API should do what we say, not what we mean. The API should also provide enough data to do the nice thing too. In this case I think that means providing an API endpoint that lists the fallback languages that clients may use if they like. So for this API, I think languages in the NSL mapping should return a 400 error. It may also be nice to indicate in the error if the language is unknown, or if it is known but not supported.

That sounds good to me!

In a PR: https://github.com/mozilla/kitsune/pull/2510

PR 2510 landed in https://github.com/mozilla/kitsune/commit/1e746aae0b02d5135efb0475cfc21756701a5cb4 Fixes in PR: https://github.com/mozilla/kitsune/pull/2511

PR 2511 landed in https://github.com/mozilla/kitsune/commit/c5b6d588a3c71381da9475e19c695d7e99a09859

This got pushed out just now by Mike. Closing it out.