Name the municipality behind a CEP that does not existHEADv0.2.0main

A CEP that fails at the checkout is almost never a random number. It is
a shopper who knows perfectly well which town they live in and got a
digit wrong, most often by reaching for the -000 that 957 municipalities
never received. The API now names the municipality such a number would
have belonged to, in the body of its own 404, so the message can say
"that would be in Areal/RJ, which has CEPs from 25845-001 to 25849-899"
instead of leaving the shopper at a dead end with nothing to act on.

It stays an error. Nothing from it is written into a checkout field, on
either checkout and in either lookup mode: a CEP that does not exist has
no address, and filling one in from the municipality behind it means a
parcel delivered to the wrong town and a chargeback behind that. The one
module that reads the 404 body hands its callers a finished sentence and
never the data itself, so there is no shape in which it could leak into
a field later. The two CEPs quoted are the lowest and the highest that
really exist there, never a list and never a suggestion, because the
range is sparse enough that a number out of the middle of it would most
likely not exist either.

The widget correctly throws its 404 away without reading it, so the body
is fetched once more, on the miss path only and once per CEP. In proxy
mode PHP passes the municipality through with the 404 and caches it with
the miss, which is what keeps the two modes indistinguishable from the
browser. Anything missing or misshapen falls back to the message the
plugin has always shown.

1 files changed, 10 insertions, 0 deletions

diff --git a/includes/class-cepis-woo-messages.php b/includes/class-cepis-woo-messages.php
index 201fe4e..93d3279 100644
--- a/includes/class-cepis-woo-messages.php
+++ b/includes/class-cepis-woo-messages.php
@@ -16,6 +16,12 @@ defined( 'ABSPATH' ) || exit;
  *
  * Keys are the widget's status kinds and error codes. Anything not listed
  * keeps the widget's own wording.
+ *
+ * `not_found_range` and `not_found_city` are the exception: they are not
+ * status kinds the widget knows, but templates the plugin's own JavaScript
+ * fills in when the API says which municipality a missing CEP would have
+ * belonged to. They live in the same table so that one filter, one text domain
+ * and one `.po` file cover everything the shopper is told.
  */
 final class Cepis_Woo_Messages {
 
@@ -33,6 +39,10 @@ final class Cepis_Woo_Messages {
 			'loading'          => __( 'Looking the address up…', 'cepis-woocommerce' ),
 			'found'            => __( 'Address found.', 'cepis-woocommerce' ),
 			'not_found'        => __( 'CEP not found. Check the number or fill the address in by hand.', 'cepis-woocommerce' ),
+			/* translators: 1: municipality, e.g. Areal. 2: state code, e.g. RJ. 3: lowest CEP that exists there, e.g. 25845-001. 4: highest CEP that exists there, e.g. 25849-899. */
+			'not_found_range'  => __( 'CEP not found. This number would be in %1$s/%2$s, which has CEPs from %3$s to %4$s. Check the number.', 'cepis-woocommerce' ),
+			/* translators: 1: municipality, e.g. Areal. 2: state code, e.g. RJ. */
+			'not_found_city'   => __( 'CEP not found. This number would be in %1$s/%2$s. Check the number.', 'cepis-woocommerce' ),
 			'invalid'          => __( 'Invalid CEP. Type all 8 digits.', 'cepis-woocommerce' ),
 			'rate_limited'     => __( 'Too many lookups in a short time. Wait a few seconds and try again.', 'cepis-woocommerce' ),
 			'server'           => __( 'The CEP service is unavailable. Fill the address in by hand.', 'cepis-woocommerce' ),