How to Use Argos CI to Compare Hindi and English Website Screenshots

Use Playwright to put your site into its Hindi and English states, capture each state with a stable screenshot name, and upload the captures to Argos CI. Give the two languages separate names so each is reviewed against its own accepted baseline. Translated pages are expected to differ from each other; the goal is to catch unintended changes within each language.

Argos’s Playwright integration uses the @argos-ci/playwright package, an Argos reporter, and argosScreenshot(page, name). The integration does not supply a Hindi/English fixture or switch your application language for you: your test must use the application’s real locale routes, controls, or setup. See the official Argos Playwright Quickstart.

1. Install and configure the Argos Playwright reporter

In an existing Playwright project, install the Argos SDK:

npm install --save-dev @argos-ci/playwright

Add the reporter to playwright.config.ts. Supply the project token through your CI secret as ARGOS_TOKEN; the Argos quickstart documents reporter configuration and token-based authentication.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  reporter: [
    ['list'],
    ['@argos-ci/playwright', { token: process.env.ARGOS_TOKEN }],
  ],
  use: {
    baseURL: process.env.BASE_URL ?? 'http://127.0.0.1:3000',
    browserName: 'chromium',
    headless: true,
  },
});

Set ARGOS_TOKEN in the CI environment using your Argos project token. Do not commit the token to source control. The Argos reporter can also receive supported authentication through its documented options, and the quickstart describes passing the token in other CI providers.

2. Capture both language states with stable names

The following test assumes the application serves English at /en/ and Hindi at /hi/. Change those paths and the readiness condition to match your application. If the site uses a language switcher, use it or establish the locale through the app’s supported test setup so the page is truly rendered in the intended language.

import { test, expect } from '@playwright/test';
import { argosScreenshot } from '@argos-ci/playwright';

test('homepage visual states: English and Hindi', async ({ page }) => {
  for (const locale of ['en', 'hi']) {
    await page.goto(`/${locale}/`);

    // Replace this with a stable app-specific readiness signal.
    await expect(page.locator('main')).toBeVisible();

    // Wait for fonts that affect glyph metrics and line wrapping.
    await page.evaluate(() => document.fonts.ready);

    // The locale in the name keeps each variant associated with its own baseline.
    await argosScreenshot(page, `homepage-${locale}`);
  }
});

Names such as homepage-en and homepage-hi are deliberately stable. Argos matches screenshots to baselines by name, so changing a name can make a capture appear as a new screenshot rather than an update to the intended baseline. Keep names unique across pages, viewports, themes, and other variants that should be reviewed independently.

3. Establish a baseline, then review pull requests

Configure CI to install dependencies, start the application, and run the Playwright suite with ARGOS_TOKEN available.
Run the workflow on the default branch first. Argos needs that build to establish the baseline; the quickstart says pull-request builds are marked orphan until a baseline exists.
Open a pull request and inspect the Argos check. Review homepage-en against its English reference and homepage-hi against its Hindi reference.
Approve a changed baseline only after deciding the visual change is intended. If only one language changed, investigate that locale’s layout, fonts, translation, or route separately.

Argos documents locale variants as Storybook modes with individual baselines. For Playwright, stable language-specific screenshot names provide a practical way to distinguish the variants; the app-specific locale setup remains your responsibility. See Argos visual testing.

4. Keep comparisons reproducible

Visual diffs are useful only when the capture environment is reasonably consistent. Playwright notes that operating system, browser version, browser settings, hardware, power source, and headless mode can affect rendered output. Use the same CI image and browser installation for baseline and comparison runs, and avoid generating a baseline locally if pull requests run in a different environment. See Playwright visual comparisons.

Use the same browser engine and version in baseline and pull-request jobs.
Keep viewport, device scale, color scheme, locale, timezone, and font availability stable.
Wait for page content and fonts to settle. Avoid arbitrary long sleeps when a specific readiness signal is available.
Control or disable animations and other time-varying content in your test environment where appropriate.
Include the locale in screenshot names or test identity. Argos SDK metadata can include URL, viewport, browser, automation library, SDK, and test title; see Argos screenshot metadata.

5. Choose the right baseline model for localization

Hindi and English text may use different glyphs, line lengths, and wrapping. Do not compare the Hindi pixels to the English pixels and treat every difference as a regression. Instead, review each capture against the accepted reference for that same language.

When introducing a new locale, Argos documents fallback baselines as a way to bootstrap visual coverage from a default locale. A fallback can help establish initial coverage, but it does not make translations visually equivalent or replace review of the localized page. See Argos fallback baselines.

6. Handle common failures

Symptom	Likely cause	Fix
Both screenshots show the same language	The test did not activate the locale, the route redirects, or the app’s language is stored in a cookie or browser storage.	Use the application’s supported locale route or switcher. Assert a locale-specific heading or document language before capture.
A pull-request build is orphaned or has no comparison	No baseline has been established on the default branch, or the pull-request build cannot find the expected project/token.	Run the workflow on the default branch first; verify the CI secret and reporter configuration.
Argos treats a familiar capture as new	The screenshot name changed, differs by locale, or is not unique and stable.	Restore a deterministic name such as `homepage-hi`; use distinct names for each intended variant.
Large diffs appear without a code change	Browser, operating system, fonts, rendering settings, viewport, or headless mode differ between runs.	Pin and reuse the same CI environment and browser version; check font installation and capture settings.
Text wraps differently on CI	A web font has not loaded, a fallback font is being used, or capture happens before layout settles.	Wait for `document.fonts.ready` and an app-specific ready condition; ensure CI can load the intended fonts.
Intermittent diffs in a region	Dynamic content, animations, timestamps, rotating content, or asynchronous data changes between captures.	Use deterministic test data, wait for the relevant state, or stabilize the dynamic region in the test environment.
No Argos upload appears	The reporter is absent from the active config, the suite did not run, or authentication is unavailable to the job.	Check the reporter output and CI environment, confirm `ARGOS_TOKEN` is set for that job, and ensure the Playwright command uses this config.

7. Argos CI or Playwright screenshot assertions?

Playwright’s built-in toHaveScreenshot() writes reference screenshots on an initial run and compares later runs to those references. It can suit a team that wants to manage screenshot references with its test suite. Argos is a fit when the team wants screenshots uploaded for a hosted review workflow and a pull-request check. Compare how your team stores and approves baselines, how it reviews pull requests, how the workflow fits existing Playwright or Storybook tests, and whether CI can keep rendering conditions consistent. Neither choice removes the need to stabilize the browser environment.

Or skip the browser setup

If you need page captures outside this visual-test workflow, ScreenshotNeo is a website screenshot API and MCP server for developers. Its API returns an image or PDF from one GET request; its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. It does not replace Argos’s named visual baselines and pull-request review.

For a one-off capture, see the ScreenshotNeo API documentation:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

FAQ

Should Hindi and English have the same screenshot baseline?

No. Treat them as separate visual states and review each against its own accepted reference.

Does Argos automatically switch my Playwright page to Hindi?

No. Your test must navigate to the localized route or use the application’s locale switch or setup. The Argos Playwright quickstart covers capture and upload, not a language fixture.

Can I bootstrap a new locale from the English baseline?

Argos supports fallback baselines. Use one to begin coverage if useful, then review and establish the localized page’s intended appearance.

Can I use Playwright’s own screenshot comparisons instead?

Yes. Playwright provides toHaveScreenshot(). Choose based on baseline storage and approval workflow, pull-request review needs, and your team’s environment consistency.