What you are seeing
The code scans, but the page appears in the wrong language: a different language from the one the material beside the code uses, or from the language the visitor expects. Language selection usually comes from the link, the site settings, or the visitor's browser, and a QR code can carry a link that pins the wrong language. The fix is to find which layer chose the language and to make the code carry the right one.
Likely causes
1.
Link points at the wrong language version — A link copied from a page in one language carries that language with it, even when the code is printed beside text in another language. Test: compare the encoded URL with the address of the correct language version.
2.
Site picks language from the visitor browser — A site that auto-detects language from the browser can serve a language the visitor did not expect, especially on a shared or borrowed phone. Test: open the same URL in a browser set to the expected language.
3.
Redirect drops the language part of the address — A redirect can strip the language segment from the address and land visitors on the default language. Test: follow the redirect chain and watch the language segment.
4.
Language switcher not stored for QR visitors — A visitor who picks a language on the site may lose the choice if the site stores it in a way that does not survive the QR journey. Test: pick the language on the site, then follow the QR journey again.
5.
Content not translated for that page — The page itself may exist only in one language, so every visitor sees that language regardless of the link. Test: check whether a translated version of the page exists.
Step-by-step fix
1. Decode the payload and write down the exact URL it contains.
2. Open the correct language version of the page and copy its exact address.
3. Compare the two addresses and note where the language part differs.
4. Follow the redirect chain and check that it preserves the language segment.
5. Point the code at the correct language address and regenerate it if needed.
6. Retest on two phones, including one with a different browser language.
Putting this into practice
In practice, the wrong-language mistake comes from copying a link while viewing the page in the wrong language. The link quietly carries that language into every printed copy. Copy links from the language version the code will serve, and check the proof in that language before printing. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Copying a link while viewing the page in the wrong language and printing it beside text in another language.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that shows the wrong language will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that shows the wrong language.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The encoded URL points at the intended language version
- Redirects preserve the language segment
- The page appears in the intended language on two phones
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [QR batch validator](/qr-batch-validator)
- [QR typosquat checker](/qr-typosquat-checker)
- [QR safety checker](/qr-safety-checker)
- [UTM builder](/utm-builder)
- [blog](/blog)
