fix(i18n): the chosen language never reached the service on the readings that matter - #37
Merged
Conversation
…ngs that matter `lang` is declared `in: query` on every operation that accepts it, POST included, but the client only built a query string for GET and left `lang` in the JSON body on POST. The service ignores it there SILENTLY: a 200 comes back in English, so nothing surfaced the failure in a log, an error, or the admin. That made the Branding reading-language setting and the site-locale fallback no-ops on 120 of 175 operations, including 13 of the 17 featured readings: natal chart, kundli, panchang, mangal dosha, KP chart, synastry, Guna Milan, compatibility, numerology, life path, tarot, biorhythm. The four GET heroes (horoscope, moon phase, angel number, crystals by zodiac) translated correctly and masked it. Reported by a customer on a Spanish site. Verified both directions against production before and after: the same request returns English with `lang` in the body and Spanish with `?lang=` on the URL. Tests assert on the URL and body the client actually builds, because that is the seam the bug lived in. A test checking only "was lang injected into the payload" passed throughout. Also vendors @roxyapi/ui 0.22.0, and corrects the readme, which promised a `lang` attribute on every shortcode. Only some of the long tail accept one; the featured readings drop it silently, so the site language and the Branding setting are the documented path.
…cement not absence The first version asserted an English site sends no lang at all. CI proved otherwise: Language::resolve() falls back to the get_locale() prefix and en is a supported code, so it returns 'en' and the URL carries lang=en. That is pre-existing GET behaviour, so the POST path matching it is correct. The assertion now covers what actually matters, that even the default language rides the query string and never the body, plus an unsupported locale (ja) which resolves to nothing and must leave the URL clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
langis declaredin: queryon every operation that accepts it, POST included, but the client only built a query string for GET and leftlangin the JSON body on POST. The service ignores it there silently — a 200 comes back in English, so nothing surfaced the failure in a log, an error, or the admin.Blast radius: the Branding reading-language setting and the site-locale fallback were no-ops on 120 of 175 operations, including 13 of the 17 featured readings (natal chart, kundli, panchang, mangal dosha, KP chart, synastry, Guna Milan, compatibility, numerology, life path, tarot, biorhythm). The four GET heroes translated correctly and masked it.
Verified against production both directions, same request body:
POST /astrology/natal-chartwith"lang":"es"in the bodyPOST /astrology/natal-chart?lang=esAlso in this PR
@roxyapi/ui0.22.0 (was 0.21.1).readme.txt, which promised alangattribute on every shortcode. Only part of the long tail accepts one; the featured readings drop it silently viashortcode_atts(). The site language and the Branding setting are the documented path.readme.txtchangelog and upgrade notice for 1.7.2.Tests
Four tests in
tests/phpunit/test-post-language-query.php, asserting on the URL and body the client actually builds — that is the seam the bug lived in, and a test checking only "was lang injected into the payload" passed throughout.Verification note
phpcs, phpstan (level 8), prettier, lint:js, lint:css,
generate:check,check-distignore,build:allandcheck:blocksall pass locally. phpunit and plugin-check could not run locally because wp-env cannot start in that environment, so CI is the gate for those two.