Languages and current-page context

Answering in the visitor's language#

Reesponder is instructed to answer in the visitor's language while using verified business Knowledge. You can test a normal customer question in another language without creating a separate website or translating every manual entry first.

There is no customer-facing language picker or fixed language list in the portal. The ability to respond in a language does not guarantee that every specialist term or policy translation is perfect. Check important multilingual examples with someone who can verify both the wording and the underlying business facts.

How the current page helps#

The installed widget sends the website path and query string when the conversation starts and with subsequent messages. Reesponder can prioritise collected Knowledge from the matching page, alongside other website and shared sources.

For example, a visitor asking “Does this come in another size?” on a product page gives the assistant a useful location. The product's relevant details must still exist in Knowledge. A page path is not a live screenshot or an instruction to inspect everything displayed in the visitor's browser.

What page context does not provide#

The assistant does not automatically read a customer's signed-in order, cart, payment information or hidden account data simply because the widget is on that page. Nor does the path guarantee that a dynamic product change has already been collected by a crawl.

If the question depends on a current value, use a suitable connected Action or a deliberately configured customer-context integration. If the page's business text has changed, publish it and re-crawl. Avoid putting secrets or unnecessary personal information in URL query strings: the path sent with a support conversation can include them.

Integration-provided customer context#

Customer context consists of fields your integration deliberately supplies and Reesponder is configured to accept. It is not inferred authentication. Browser-provided values are untrusted; a visitor can alter browser data and must not gain access to a protected operation by supplying an email address or customer ID there.

Server-provided context uses a separate credential and trust boundary. Keep that credential server-side. Use the relevant integration documentation for the exact fields and identity requirements rather than treating a manual Knowledge entry as a customer record.

Test the right surface#

Use a private five-question test to check ordinary language and source coverage. Then test the installed widget on the exact page you want to verify. The private preview does not reproduce the live page or customer-context integration.

Ask an ambiguous page-specific question, follow it with a clear detail and compare the result to the source reader. If the answer cannot identify a missing fact, improve the source or ask a more useful clarifying question. In Conversations, review the stored path and actual exchange; language aggregates in Analytics describe observed support patterns, not a certification of translation quality.

Worked example: an unknown live availability value#

A visitor on a room page asks in French whether it is available next Saturday. The collected page explains the room type, but it does not contain live booking availability. Knowing the page and understanding French does not supply that value. A configured, authorised availability lookup is the appropriate source if your business supports one.

Check that the answer distinguishes the room description from a booking result. If no lookup exists, the useful next step is the real booking or contact route, with its known limits. A manual fact saying “rooms are usually available” would not fix the missing date-specific information and could encourage an unsupported promise.

Record what your context test actually proves#

Record the page, question, relevant source text and answer. For a multilingual check, record the condition that the reviewer verified. For a private lookup, record whether the authorised customer received only their permitted result and whether another customer was refused. These are separate checks and should not be collapsed into “context works”.

Repeat after a substantial routing or source change. If the page content is missing, refresh or supplement the correct Knowledge source before judging relevance. If an SPA's visible content changes without the expected location context, investigate that lifecycle with the integration maintainer rather than trying to repair it with a general instruction to guess the current product.

Compare two pages with a deliberately ambiguous question#

Choose two published pages with different, verified details. For example, one product is available in small and medium, while a second is available only in large. Confirm that both pages have usable text in their website Knowledge source before testing the widget. Otherwise the comparison is testing missing information as much as page relevance.

On the first page, ask “Which sizes can I choose?” without naming the product. Read the answer, then move to the second page and repeat the question in a fresh conversation. Use a follow-up naming the product if the answer is ambiguous. This separates whether the assistant identified the subject from whether it had the correct size facts. A clarifying question can be appropriate when the available information does not identify one product reliably.

Next, test your site's real navigation behaviour. If it changes pages without a full reload, confirm that the installed widget sends the relevant current path for subsequent messages. A path update does not supply a fresh product inventory or cart. For those values, verify the separate live-data integration. Keep this test focused on subject relevance, and record actual answers rather than assuming that a current path guarantees the intended response.

Review meaning, not just fluency#

Prepare a small set of questions that includes an amount, a deadline, an exception and a link. Ask them in the languages that matter to your customers. Compare the replies with the original business facts and have a capable reviewer check specialist or consequential wording. Smooth phrasing is not enough if “within fourteen days” becomes “after fourteen days” or a delivery estimate becomes a guarantee.

Use full questions that a customer would actually ask. A one-word language name does not test how the assistant handles a return condition or a product restriction. Include a mixed-language question if that reflects your audience, and check whether the reply remains understandable without changing the policy. Formatting of dates and amounts can vary; the underlying date, currency and conditions must remain clear.

When you find a problem, identify whether it came from unclear source text or the interpretation in that reply. Rewrite ambiguous business wording in the source so its meaning is explicit, then test again. Do not add an unsupported language guarantee to Answering guidance. For an important case the assistant cannot explain reliably, give the customer a truthful route to a person who can help.

Keep page context useful without making URLs a data store#

Use stable public paths for products, policies and support topics. They give reviewers a practical way to understand where a question began and relate it to collected content. Avoid placing private information in those paths or query strings. A URL containing an email address, account token or private document identifier can travel with the support conversation as current-page context.

Review the URLs generated by account, checkout and reset pages before adding the widget there. Where a workflow uses a confidential token in its URL, remove unnecessary token exposure in the website's own design and assess whether the widget belongs on that page. Do not solve the issue by copying the token into a manual source or browser context field. Customer-context integration should supply only the fields needed for the intended support use.

Distinguish relevance from permission during this review. An email label supplied by a browser might help describe a request, but it cannot prove who owns an order. Test an authorised customer and a different customer against any private lookup, and verify that the server-side integration enforces the boundary. A multilingual reply, a familiar page path and a claimed customer identifier must not substitute for that check.