openstreetmap
Consider less mysterious error message on too large bounding box
Description
Current message show to user who made overly large bbox seems quite mysterious to a new user.
Is it technically possible to replace
with
Server returned status code 413
appearing on clicking message
by something such as
Your edit covers too large area, it is better to split edit in parts where editing places far away from each other.
?
(result of https://github.com/openstreetmap/openstreetmap-website/issues/4805#issuecomment-2182603310 testing)
Screenshots
As far as I know, iD doesn’t customize any error message returned by the API. For example, it doesn’t attempt to localize the error message into the user’s preferred language. But presenting the error message is really a last resort anyways. By the time the user sees this error, there’s little they can do about it. If they’re lucky, the offending change is somewhere near the top of the undo stack, so they can undo their changes one at a time until the changeset saves. Or they can download the osmChange file locally and break it up using JOSM. This is unrealistic for the sort of user who doesn’t understand the error message.
If the goal is to make the user experience friendlier, then iD would need to prevent the user from expanding the changeset bbox before they make the change. This is one of the ideas proposed in #8590. Since the actual limit depends on the user account’s age and the thresholds are dynamically configurable on the server side, iD would need an upfront signal from the API about these limits, such as in the /capabilities response, which iD requests at launch.
However, my understanding is that these limits were implemented as a defense against vandalism, not to enforce good etiquette, as proposed in #8590. If we’re confident that these limits actually target vandals and that mappers in good faith are unlikely to hit this error, then I don’t see a stronger need to improve the user experience for this error than for any of the other errors the API can return.
In fact, I would consider a non-specific error message as a good catch-all case for anything user-facing error that's the result of a vandalism block being hit. Let's not guide potential bad actors here.
In order to properly display translatable error messages, we would need a reliable way to match errors from the OSM API to actual error cases/messages.
What we could do is to add a link to a wiki page which would help users to find out what the different error codes and messages from the API mean.
and hard to implement as there is no definitive list of errors that API can return, and if we have nice support for some and miss it for others it gets even more confusing to users when they run into unsupported one
also, this was not encountered in wild but in testing
and I have no obvious idea what to show to user to make it much less confusing to justify effort on entire new mechanism to catch and translate those errors