Unfortunately another request to the server's unavoidable (unless I'm missing something). But it's a lightweight HEAD request, anyway.

Would it be better if we change install_check_localization_server() so it will continue to check if it gets a request in the 400 range? That implies that the translation site is fine, but the uri we used is not.

or at least add a flag so we can stop it from setting $online = FALSE in this one use case.

Function install_check_localization_server() is actually quite smart. It avoids any additional checks, if a previous one already failed. If the request to the server (without path) doesn't work at all, don't waste time with subsequent requests to the same server (timeout is only 5 seconds, but that would sum up). The most common case for failure will be that there's either no internet connection at all (local offline install), or some PHP problem (not able to do external requests).

Whether it's a 404 actually gets relevant in our last check - for the version specific translation file.
I couldn't think of a better logic for these checks or their order. @hosef or do you have something smarter in mind?

Remember, it's just a single (cheap) additional HEAD request, anyway.

I'm not really sure. I took a look at the function and it just feels like a simple 200 = good, all other codes = bad is way too simple for what could actually happen.

This PR is probably fine as is because we control the site being requested here, so we control the response codes. I've been working on writing some API clients recently, and it just feels bad that we are not properly handling the other response codes.

I admit, http handling's quite simple here: 200=good anything_else=bad. But I think, in this case this approach is fine.

We're not interested whether anything moved (3xx) or whether something's temporarily broken (5xx) or the file just isn't there (404). We quickly inform about problems if necessary, hide those we can silently fix (fallback file), and suggest an immediate solution via UI if not. To not make the install process cumbersome because of problems outside this (not yet) install.

All of the "not 200" mean, that we can't get the translation file right now. So why bother?

So why bother?

So we don't have to check the fallback uri before checking the uri we actually want.

Unfortunately another request to the server's unavoidable (unless I'm missing something).

The thing you are missing is proper response code handling. The server tells us why it didn't work and we are just ignoring it.

It works the way it is. We would just need to add more checks to that function to avoid making 2 requests.

The thing you are missing is proper response code handling.

Am I? 😜

What I could imagine, is a second param for install_check_localization_server() like $ignore_cache (default false) - that would allow to check the fallback after the regular translation file - one request less. If we got that far (we're online, the server's reachable), most likely the "regular" file should be accessible, too (unless the file hasn't been generated, yet).
But that additional param feels a bit odd and makes that utility function logic harder to understand. I might be wrong, though.
The actual reason, why the translation file isn't there isn't actually relevant IMO. We can't have it - try the fallback.

@hosef are you still interested in this PR? Any thoughts?