How to automate screenshots for multilingual Web Apps

However, managing support content in multiple languages brings a layer of complexity that extends far beyond translation. Each new language you support effectively multiplies the volume of articles, screenshots, and updates — significantly increasing the operational effort required to maintain your help center. It quickly becomes clear that automation is not just helpful — but essential, and the only sustainable way to generate thousands of images across multiple languages.

In this post, we’ll describe a couple of different technical approaches that can be used to help pave the way for multilingual screenshot automation, and share how tools like LaunchBrightly can help simplify the process as the audience your documentation needs to support grows.

Rendering different languages for screenshot automation

A good place to start when thinking about automating multilingual screenshots of your product is by understanding how your application handles rendering content in different languages.

Language-aware applications

We’ve found that the cleanest and most scalable way to automate product screenshots across multiple languages is when an application is set up to automatically detect browser-level language preferences — specifically via the accept-language HTTP header. This tells the application to render content in a specific language — just like it would for a real user browsing in French, Spanish, or any other supported language.

Each time you visit a website, your browser quietly sends some helpful information to the web server to tailor your experience. One of the most important signals is the accept-language header, which communicates your preferred languages in ranked order. If the site supports one of those languages, it will typically serve content in that language automatically — without requiring you to manually select it. If not, it will simply default to its primary (or only) language. And many web applications work in much the same way!

While most SaaS products present language settings as a fixed list for the user to choose from — or fall back to a default system-wide language — they often also support browser-level language detection behind the scenes. This isn’t always visible in the UI, but it’s functional. If the browser sends an accept-language value like “fr-FR”, for example, the application will automatically render content in French (provided, of course, the app supports that language) — even if you never touched the app’s language settings. This implicit support makes it possible to drive language selection purely through browser configuration — which is ideal for automation workflows like multilingual screenshot generation.

Why we recommend the accept-language approach for automation

Using the accept-language method offers a streamlined and scalable approach to automation. Instead of capturing individual screenshots for each different language, you can create a single script or automation recipe for each of the product screenshots you would like to automate — and automatically vary the accept-language parameter to generate unique localized versions of the screenshot for each supported language. With this approach one automation recipe can produce accurate screenshots in every supported language — significantly reducing complexity and effort by eliminating the need to maintain separate demo environments for each language, or duplicating automation recipes to generate screenshots for each language. In short, it simplifies your documentation workflow and makes it far easier to keep multilingual content up to date.

Automation tools like LaunchBrightly make it easy for you to create automation recipes using its point-and-click screenshot recipe builder, and will automatically generate screenshots in any number of unique modes based on the width, height, color scheme (light or dark), language and pixel density of your choice.

What if your application does not support localized browser settings

Not all applications are built to automatically detect and respond to browser-level language preferences. Some rely on account-level preferences saved as user settings and loaded at sign-in to determine which language to display. When the app ignores the accept-language header and pulls the language from a user-specific setting instead, automation becomes harder — and manual workarounds are often needed.

Capturing screenshots in multiple languages in these scenarios would most likely require setting up dedicated demo environments, configuring each to a specific language, and building custom automation recipes for each language. This approach lends itself to fragmented audit workflows for each of your supported languages — and adds maintenance overhead which increases as the number of languages grows. We therefore do not recommend this as a long-term solution.

One solution we’ve seen others implement, and we do recommend as a viable path to automation is adding a language preference option — such as Use current system setting — to your apps language settings. This option would then dynamically adjust the application language based on the user’s browser or system settings, and provides a viable path to automation by allowing you to create a single automation recipe to generate unique screenshots in multiple different languages (as outlined above). Additionally, the option still provides the ability for manual language selections — allowing users to override auto-detection when necessary.

Take support for multilingual documentation to the next level

When multilingual support is enabled in most help center platforms, the structure and organization of the help center is often automatically applied across all supported languages meaning they are effectively configured to operate as separate help centers — unique to each language.

When Intercom, for example, is enabled for multilingual support all all language variants of an article share the same Article ID but appear under different URLs that reflect the language and translated article name:

English: https://intercom.help/exampleapp/en/collections/152009-teams
French: https://intercom.help/exampleapp/fr/collections/152009-gestion-d-equipes

Rather than managing localized screenshots across each of these individual articles, automation tools like LaunchBrightly have designed their automation recipes to intelligently branch based on the rendered language of the screenshot and the article translation — allowing you to manage your translated articles and automated screenshots under a single, unified workflow, while doing so more efficiently and at scale.

Final thoughts

Multilingual support shouldn't mean multiplying your manual work. By adopting browser-based language detection and automation that respects user context, you can keep your product documentation sharp, localized, and in sync with your evolving app.

If your team is managing help center content across languages and looking to simplify screenshot maintenance, we'd love to talk.