Must-read tips

After you build a feature with Build automation from scratch, a few things are worth doing before you hand it off. This page collects those common questions.

Adapt to other languages

An automation is usually developed and test-run in one interface language. Button, menu, and prompt text change with the language. If the device later uses another language, a real run may no longer find those controls.

There are two common ways to cover more languages. Pick the one that fits your situation.

Option 1: Adapt in advance

Best when you already know a small set of languages to cover and want a stable run before go-live. You switch the interface language yourself, then tell the agent to adapt to the language now on screen.

Do not ask the agent to hunt through Settings and switch the language. Language settings are usually buried, and the location differs by site and app. The agent generally does not know where the language is set. Left to search, it may guess, tap the wrong place, and waste both time and compute.

What to do

1. Finish the feature in one language and confirm it runs.
2. Open the device bound to this chat (browser, Android, or iPhone) and change the display language yourself to the next language you need.
3. Return to the chat and say:

I changed the interface language. Please adapt the feature to the language currently on screen.

4. The agent then sees an interface that is already in the new language and adapts to the current wording, instead of searching for language settings first. Repeat steps 2 and 3 for each additional language.

You click the language entry. The agent only looks at the current screen and updates the feature. That saves time and compute.

Option 2: Adapt after a failed run (error correction)

Best when many languages are involved, or when device languages in production are unpredictable. During development, adapt to one language only. You do not need to switch every language by hand beforehand.

When a real task runs on a device in another language and fails because the UI text no longer matches, enter error-correction mode and let the agent complete support for that language from the screen at the failure site. Later runs in the same language usually pass without another round of setup.

What to do

1. Finish the feature in one language, confirm it runs, then hand it off and run real tasks as usual.
2. When a task fails because of a different interface language, open error correction (or return to the related chat) and ask the agent to adapt using the interface already open on the current device, for example:

The task failed because of a different interface language. Please adapt the feature to the language currently on screen.

3. The agent sees the real screen from the failure and adapts to the current wording. It does not need to search language settings, and you do not need to switch languages in advance.
4. For any new language that has not been adapted yet, wait for a failed run and correct once the same way.

In short: keep development working in one language; add new languages on demand with “task fails → error-correction adapt,” instead of switching languages one by one up front.