The search found the phrase; the highlight points somewhere else
A search result can identify the right record and still underline the wrong part of its title. Rewriting the title or weakening the search query may conceal the symptom while leaving the boundary error untouched.
This fictional investigation concerns an administrative search interface. Its source strings, result IDs and acceptance outcomes are invented. The mechanism depends on an inspected service contract, not an assumption that all search providers report positions the same way.
Preserve the source and query
Record R-31 has the exact title Café — bevestiging. The query is bevestiging. The service returns R-31 and identifies the matched range as start byte 10, end byte 21, using UTF-8 and an exclusive end position. Its contract states that the range applies to the exact returned text, without normalization or replacement.
The first ten UTF-8 bytes represent Café — , and the next eleven represent bevestiging. The result is therefore internally consistent. The accent and dash require more UTF-8 bytes than their corresponding JavaScript string positions.
The browser instead passes 10 and 21 directly to the string slice operation. In the inspected JavaScript fixture, that produces estiging. The full title remains correct; only the highlighted substring is wrong.
Establish the units at both ends
JavaScript string length is measured in UTF-16 code units. In this title, the prefix occupies seven such units, so the intended JavaScript range is 7 to 18. The numbers 10 and 21 are not corrupt; they describe a different representation.
The investigator verifies the record ID, exact returned text, query and service-declared range. The failure occurs when byte coordinates are treated as string coordinates. It is not an incorrect translation, a different document revision or a need to remove the accent.
An ASCII-only control happened to work because the relevant byte and string positions coincide there. That explains why an earlier simple demonstration failed to reveal the problem.
Translate the range without changing the content
The repair keeps the service's exact UTF-8 text representation. It checks that the offsets are ordered and within the byte array, then validates the prefix and selected range as complete UTF-8 sequences. The selected range is decoded and its JavaScript positions are derived from the decoded prefix and match.
TextEncoder provides UTF-8 encoding for JavaScript strings. A TextDecoder configured for fatal errors rejects malformed sequences rather than silently substituting replacement characters. An implementation must also verify that it is applying the range to the same text revision and representation that the service specified.
If a range cuts through an encoded character or otherwise violates the contract, the interface does not guess a new phrase. In this project's approved behaviour, it shows the full unchanged result without a highlight and records a bounded diagnostic for investigation. Ordinary result access remains available if its identity and permissions are valid.
Read the corrected result
The fictional replay decodes bytes 10 through 20 as bevestiging and maps them to string positions 7 through 17. The visible match now covers that complete word. The title still reads Café — bevestiging, the query is unchanged and the result link still opens R-31.
Copying the full title returns the original text. Opening the record shows the same title. No normalization, spelling change or truncated source is introduced as part of the repair.
The ASCII control Kop: bevestiging continues to highlight the intended word. A second title, é bevestiging, uses a three-byte prefix but a two-unit JavaScript prefix; its correct match is also retained. These controls show that the adapter follows the declared representation rather than applying a fixed three-position correction.
A deliberately malformed range beginning inside the two-byte é is rejected. An out-of-range end is rejected as well. Neither becomes a plausible-looking highlight, and neither changes the stored record.
Keep the boundary documented
The acceptance record retains the contract's encoding, offset unit, exclusive-end rule, exact source strings and observed ranges. The next maintainer must know which representation the numbers describe before replacing the search client or presentation component.
The demonstrated repair concerns match positioning. It does not establish search relevance, correct translation, permission to expose every result or complete accessibility of the interface. Those remain separate questions.
The integration service examines these contracts where systems meet. The bilingual publishing service can then keep the actual language and content relationships clear, without confusing a technical coordinate error with a wording problem.