Address validator emits street in European order, reversing US addresses

[fuelist]

Repo: sybrew/The-SEO-Framework-Extension-Manager
File: lib/js/tsfem-form.js (and its minified companion lib/js/tsfem-form.min.js)
Affects: Any extension that uses [data-geo-api-component=action] fields with geo-api-component: ['route', 'street_number'] — notably the Local extension's address field.

Summary
After clicking Validate on a Local address field, the street field is rewritten with the street name before the street number (Main St 123). For US addresses the convention is the opposite (123 Main St). The reversed value is what gets saved into Local's packed_data and flows into every downstream consumer — JSON-LD PostalAddress.streetAddress, Google Business Profile NAP checks, Rich Results test, sitemap hreflang alternates.

Steps to reproduce
Go to SEO → Extensions → Local and add a location entry.
In the street field, type a valid US address: 123 Main St.
Fill city / state / postal code, click Validate.
Confirm the Google address suggestion in the modal.
Expected behavior
Street field contains 123 Main St. JSON-LD on the front end renders:

"address": { "@type": "PostalAddress", "streetAddress": "123 Main St" }
Actual behavior
Street field contains Main St 123. JSON-LD renders "streetAddress": "Main St 123", which Google Rich Results flags as an address inconsistency against the business's Google Business Profile.

Root cause
fillAddress() in lib/js/tsfem-form.js reassembles route and street_number from the Geocoding API response in a fixed order:

// tsfem-form.js:509
element.value = ${routeCombine['route']} ${routeCombine['street_number']};
That order is correct for nl-NL / de-DE / fr-FR style addresses but wrong for en-US / en-CA / en-GB, where the street number precedes the route.

The mapping array in extensions/local/trunk/inc/classes/fields.class.php:428 ('geo-api-component' => [ 'route', 'street_number' ]) drives which components are collected, not the display order — swapping its elements has no effect on the output.

Proposed fix (minimal)
Swap the two interpolations:

• element.value = ${routeCombine['route']} ${routeCombine['street_number']};

• element.value = ${routeCombine['street_number']} ${routeCombine['route']};
  A locale-aware version (detect navigator.language or expose a filter) would be preferable long-term, but the single-order change matches the majority of TSFEM's US install base and restores parity with Google Business Profile / Apple Maps / Bing Places, all of which store US addresses number-first.

Environment
TSF Extension Manager: current trunk
TSF core: any
Browser: reproduces in Chrome, Firefox, Safari (pure JS path)
Google Maps Platform Geocoding API response schema: stable since 2014
Additional notes
No server-side component reassembly exists, so the client is the sole source of truth for the saved string.
FAQ extension and Articles extension are unaffected.
A related, lower-severity issue: the regex in k() (the "address looks valid" sniffer) accepts both orders, which may have obscured this bug during QA — valid-looking input passes the pre-validation check regardless of which order it's in.

[sybrew]

Thanks for the report!

The combination of addresses is a fallback. I'll need to confirm whether this works as a fallback or if it is too eager to use the "route + number" format. If the fallback is indeed eager, we may want to add a locale map with preferred order.

Still, if the fallback fill doesn't get invoked, this is how Google would provide us with the data. Then, we cannot easily anticipate whether it's correct. If this is the case, manual intervention may be necessary; we should highlight that in the interface.

[fuelist]

I forgot to mention that this issue is occurring across dozens of sites we manage and not limited to a single site.