Macedonian search across a catalogue written in English

A translation proxy makes the page Macedonian. It does not make the database Macedonian. Search still runs against the stored English text, so a customer typing what they can see in front of them gets nothing back.

What the bridge does

It captures the translated text and stores it where the search index can reach it, so the index contains the words customers actually type. The visible site does not change. What changes is that searching it starts working.

• Incremental indexing driven by a per-product flag, so a routine import reindexes only what changed rather than the whole catalogue.
• The full rebuild rewritten as a batched loop, because the stock rebuild does not survive a catalogue this size in a single pass.
• Individual products reindexed as they are published, so a new item is findable immediately.
• Every administrative endpoint capability-checked and nonce-verified, which is unglamorous and the reason this is safe to leave installed.

The part that took longest

The bridge populates itself by having the server request its own pages through the translation layer. Behind a CDN with a firewall in front of it, those requests arrive looking like an unidentified bot hitting the origin repeatedly, and get challenged. The server’s own addresses have to be allowlisted explicitly, both IPv4 and IPv6, since missing one produces a failure that is intermittent rather than total and therefore much harder to read.

A related repair

Result ordering broke as a side effect. The search plugin returns a fixed list of matching IDs in relevance order, which bypasses the store’s own sorting entirely, so sorting by price silently did nothing on any search results page. Fixing it meant re-sorting the returned set against the product price lookup table, and setting the default explicitly, because the first page load arrives with no sort parameter at all.