A page shows a raw key, an empty label, or text in the wrong language, and the ticket starts bouncing between the frontend and the backend team. i18n Detective settles it on the spot: select the text and see which dictionary, micro-frontend, or API endpoint produced it, with the key and URL ready to paste into the ticket.
What it does
Translation bugs are cheap to spot and expensive to route. The string on the screen could come from a dictionary bundled into one of five micro-frontends, from a JSON file loaded over the network, or from a field in an API response, and whoever files the bug usually has to guess. Guessed tickets come back with "wrong team" a week later.
i18n Detective removes the guessing. While you browse, it keeps track of the dictionaries and API responses the page loads for itself. Select a suspicious string, or Alt+click an element you cannot select, and a panel names the source: FRONTEND with the dictionary, the key, and its state, or BACKEND with the method, the endpoint, and the field path. One more click copies a report with everything the assignee needs.
Beyond single strings, it audits the whole page for raw keys and broken dictionary entries, and it can check how well the site's other languages are covered without you switching the language by hand.
Features
Source verdict
FRONTEND with the dictionary, key, and state (empty, untranslated, missing), or BACKEND with the method, endpoint, and field path. When both match, DOM evidence picks the likely one.
Page audit
One click scans the page for raw keys on screen, empty or untranslated dictionary entries, and dictionaries loaded in the wrong locale. Problems get highlighted in red where they sit.
Language coverage
Fetches the site's dictionaries for its other locales and counts missing, empty, and untranslated keys per language, so gaps surface before users report them.
Framework detection
Reads live instances of vue-i18n, i18next, react-i18next, react-intl, next-intl, and next-i18next, plus dictionaries fetched as JSON and strings embedded in server-rendered state.
Micro-frontend aware
On composed pages it tells which application owns the text, follows portaled modals back to their app, and scans every mounted root, including shadow DOM.
Ticket-ready report
The copy button produces a compact plain-text report: verdict, text, key, dictionary or endpoint URL, page address, and date. Paste it into the ticket as is.
How it works
The extension watches quietly while the page does its usual work, then answers when you ask. Nothing is sent anywhere; the analysis runs inside the tab.
Starts at {price} per month still matches the rendered text with a real number in it. Placeholders in the styles of vue-i18n, i18next, and Laravel are recognized.
Coverage
Detection works across the common ways sites deliver translations, from classic JSON files to strings baked into the server-rendered page.
FAQ
Who is it for?
QA engineers and localization managers who file translation bugs, and the developers who receive them. Anyone who has watched a "missing translation" ticket bounce between two teams knows the routing problem this solves.
Does it send page data anywhere?
No. Captured dictionaries and API responses live in the tab and are gone when you close it. The extension has no backend and no analytics. Details are in the privacy policy.
Why does it need access to all sites?
Because the sites you debug are your own staging and production domains, and the extension cannot know them in advance. If you prefer a tighter setup, whitelist mode keeps it dormant everywhere except the sites you list.
Which frameworks does it support?
vue-i18n and Nuxt, i18next with react-i18next and next-i18next, react-intl, and next-intl. Sites without any i18n library also work when they fetch dictionary JSON over the network or embed translated strings in server-rendered state.
The verdict says NOT FOUND. What now?
The panel lists everything captured in the tab, so you can see what is missing. Usual causes: the dictionary loaded before you opened the section (reload the page with the extension active), the string is hardcoded in the markup, or the site is monolingual and has no dictionaries at all. The panel tells these cases apart.
What does the language coverage check actually request?
The same dictionary files the site already uses, with a different locale substituted in the URL. Requests are sent without cookies, capped in number, and happen only when you press the button.
No servers, no analytics. Captured dictionaries and API responses stay inside the tab. Read the privacy policy
Free. The Chrome Web Store listing is in review; the install link will appear here as soon as it goes live.