Nit: let's move this "Updating failed" to a messages.default field. So that the code the two branches (offline_error or not) uses the same pattern.

Right, I meant to and then forgot :)

I'm thinking whether "Your network connection is offline" would be more polite. Telling someone "You are " is a bit blunt 🙂

Technically, a network connection isn't offline, the device is, right? Does it make more sense to make it "Your device is offline" or "The device is offline"?

If we're aiming for more politeness while not sacrificing any accuracy, we could also do one of those:

• You're not connected to the internet.
• We’re having trouble connecting — please check your network connection.
• No internet connection detected.
• Your device appears to be offline.
• Unable to connect. Please check your internet connection.

Thanks, I can see how it would seem blunt (although this message shouldn't surface to the user, in practice). I had also started with something like "device is offline", but I thought it would sound confusing or artificial for most users; similarly, "network is down / not connected to the network" could be a little technical-sounding. But I like some of the suggestions there. My favourite ones:

• You're not connected to the internet.
• Your device appears to be offline.
• Unable to connect. Please check your internet connection.

I'd make this error more specific, mentioning there was something wrong with a network request: "Network request failed." The problem is that when the error is displayed in an error notice, there is no context from which the user could know that it was a network error that happened.

@jsnajdr doesn't this happen when the error is not a connection issue? With that in mind, is it possible "network request failed" could hint to the wrong problem, and the user would think it's a network connection issue?

doesn't this happen when the error is not a connection issue?

Correct. But I think the suggestion still holds, because strictly speaking it was a request that failed, for whatever reason (not just the connection).

I think we can try "network request failed", no strong opinion here. What I think is also worth doing (but I wanted to keep it in a separate PR) is adding a layer that "sniffs" the error message for likely connection errors. That would mean that this fallback message would be shown even less frequently.

When fetch fails with the constant generic error, like Failed to fetch in Chrome, it's either a problem with network or inability of the server to read a HTTP request and return a HTTP response (even a 5xx one). In my enumeration of possible errors in #67141 (comment), it's error 3 (DNS) and the following ones.

I think it's not wrong to call them "network errors". They are not necessarily problems with your network connection, but network errors they are.

While I agree with you both, I still think that the nuance between "network error, but not a connection error" and "network connection error" can still be confusing to the user and we should try to make it clearer for non-technical people who don't necessarily make a difference.

What about "Could not get a valid response from the server."?

Nice, I'm good with that 👍 It's broad enough to include all kinds of errors that can prevent you from getting a response from the server.

Did you consider using is-network-error to recognize "informative errors" from generic ones and then throwing the informative one as the message field of the fetch_error?

I'm not even 100% sure how good an idea that would be, because the informative errors are i) rare; ii) very technical; iii) not localized.

Did you consider using is-network-error

Ah, I just said the same in the other comment thread. :) Well, implementation-wise, I don't know if I would actually require that package, or just inline that switch block, but that's a detail.

I'm not even 100% sure how good an idea that would be, because the informative errors are i) rare; ii) very technical; iii) not localized.

I don't think we need to actually present the non-connection errors to the user, as long as we already have those two classes of errors (network and non). The error should be logged in the console for anyone who can debug it.

I'd prefer to use the is-network-error package explicitly, if we decide to do this kind of check. What I like about it that it supports also legacy messages for old versions of Chrome and Safari, something I'd never figure out myself. And the package is truly minimalistic.

I wonder if we can move "You were offline." to a separate string that we concat with the existing "publishing/updating/scheduling failed" string. That way translators will have less to translate. WDYT?

Concatenating two separately translated strings isn't recommended, as far as I can remember. Based on the language, you may receive an odd complete translation.

I agree in general if we were separating a single sentence, but perhaps it should be fine if they are 2 separate sentences?

@swissspidy or @SergeyBiryukov might have a more definitive answer. I don't remember any exceptions to the rule, but they usually have a couple 😄

Exactly, I intentionally inlined all possible sentences, the same way that we need to define all possible CPT labels one by one.

Thanks. If there's a rule, sacrificing some extra work to add a few extra strings sounds like it's worth it. I'm just mindful about the translation efforts since every core string change requires hundreds of people's attention.

If you wanna concatenate two sentences "Publishing failed." and "You are offline", that should be OK. But it's only 4 extra strings here which is also fine.

Alternatives would be to have a generic text only (e.g. "Action failed because you are probably offline"), or WP adding support for custom labels per post status.

I was unsure about the capitalization of "Internet" but I guess there's data behind it, as close to a tie as that might be 😅 .

On the other hand, Core uses lower-case "internet". Although the sample is very small, there are just two messages that use the word:

• "Keeping your site updated is important for security. It also makes the internet a safer place for you and your readers."
• "The internet address of your network will be %s." (when configuring the network feature)

Capital I is used only when talking about Internet Explorer.

I also checked the WP Glossary, and both are found throughout. :) Capitalised is how I personally write it, but I can go either way here. @jsnajdr, are you invested in the non-capitalised form?

I'm not invested at all, was just curious about which convention is actually used in WordPress. 🙂 The Gutenberg repo also leans heavily towards lowercase, although it's all comments and docs, there's zero usage in code.