How to Configure Argos CI Screenshots for Indian Language Websites
Configure Argos CI screenshots for Indian-language websites with Playwright, reliable font loading, locale coverage, and stable visual tests.
To configure Argos CI for an Indian-language website, run screenshots through your existing test runner, visit each localized route or state, ensure the page’s intended Indic font has loaded, and capture only after app-specific loading and dynamic content have settled. For Playwright, install Argos’s CLI and Playwright integration, enable its reporter in CI, then call argosScreenshot from a test. Treat each language and script your site supports as a real rendering case: “Indian language” does not mean one script, one font, or one screenshot.
This guide uses Playwright because Argos’s documented setup is clearest for it. Argos also documents integrations for other runners; confirm their current setup in the Argos documentation and guides rather than assuming Playwright’s reporter applies to every runner.
1. Choose the language, script, and page coverage
Start with the combinations your product actually serves. The mapping between language and script is not one-to-one: a script may serve multiple languages, and some languages may be written in multiple scripts. W3C’s 2020 Working Draft reports 22 constitutionally recognized Indian languages and 12 scripts, while focusing mainly on Devanagari; use it as context, not as an exhaustive rendering specification for every script. See the W3C Indic Layout Requirements and Unicode’s Indic scripts FAQ.
A practical matrix should cover representative combinations, not necessarily every route in every locale:
| Case | What it can reveal |
|---|---|
| Text-dense page in each supported script | Font coverage, conjunct shaping, mark placement, and line height |
| Navigation, buttons, and headings | Clipping, overflow, and layout changes from translated text |
| Narrow viewport | Wrapping, truncation, and responsive layout differences |
| Form with validation or error text | Longer messages, punctuation, and alignment issues |
| Script-specific component | Rendering behavior that a Latin-only page will not exercise |
This is a useful sampling strategy, not a prescribed W3C test matrix. Use representative, language-appropriate strings and have a reviewer who knows the language check text content and shaping: a pixel diff can flag appearance changes, but cannot establish linguistic correctness.
2. Install and configure Argos for Playwright
In a project that already uses Playwright, install the Argos packages and configure the reporter for CI. The package names and pattern below follow Argos’s Playwright and GitHub Actions guide; check that guide and the current package docs when adopting or updating the integration, because SDK configuration can change.
npm install --save-dev @argos-ci/cli @argos-ci/playwright
Add the reporter while retaining any reporters your project already uses:
// playwright.config.ts
import { defineConfig } from "@playwright/test";
const defaultReporters = [["list"]];
export default defineConfig({
reporter: process.env.CI
? [...defaultReporters, ["@argos-ci/playwright/reporter"]]
: defaultReporters,
});
Keep your existing server startup, browser configuration, projects, retries, and reporters in this config. The snippet shows the reporter pattern; it is not a complete replacement for a project’s configuration.
3. Visit localized routes and wait for the page to be ready
Use your application’s actual locale mechanism: a localized path, query parameter, cookie, or test setup. Argos does not supply one universal Playwright locale switch. Give each capture a stable name that identifies the route and locale.
// tests/locale-home.spec.ts
import { argosScreenshot } from "@argos-ci/playwright";
import { expect, test } from "@playwright/test";
const locales = [
{ id: "hi", path: "/hi", heading: "home-heading-hi" },
{ id: "ta", path: "/ta", heading: "home-heading-ta" },
];
test.describe("localized home page", () => {
for (const locale of locales) {
test(`renders ${locale.id}`, async ({ page }) => {
await page.goto(`http://127.0.0.1:3000${locale.path}`);
// Prefer an app-specific ready marker over a fixed sleep.
await expect(page.locator("main")).toBeVisible();
await expect(page.locator("h1")).toHaveAttribute(
"data-testid",
locale.heading,
);
// Explicitly wait for browser font loading before capture.
await page.evaluate(() => document.fonts.ready);
await argosScreenshot(page, `home-${locale.id}`);
});
}
});
Replace the sample routes and assertions with the site’s real locale setup and readiness signal. If the app changes locale through a cookie or client-side state, set it before navigation or use the app’s locale control, then assert the expected translated content. A fixed delay can be a temporary diagnostic, but a readiness condition is usually less brittle.
Argos documents its screenshot helper as waiting for resources such as fonts and images, network idle, and removal of [aria-busy] loading states. The explicit font wait above makes the font requirement clear in the test; it does not replace app-specific readiness checks. See Argos’s stabilization guidance.
4. Make Indic font rendering deterministic
Indic text needs appropriate font coverage and shaping. Unicode explains that Indic fonts may need glyph substitution for conjuncts and glyph positioning for marks; a font-family declaration alone does not prove the intended font file loaded or includes the glyphs the page needs. Review Unicode’s font guidance and its South and Central Asian scripts chapter.
- Confirm the CI browser can fetch the same web font your page expects. Check font requests for failures and confirm the rendered family in browser developer tools.
- Use actual sample strings for every supported script; a font may cover one script and lack another.
- Wait for
document.fonts.readybefore capture. If the site’s font loads after a user action, perform that action and wait again. - Inspect fallback behavior deliberately. If a font cannot load, decide whether the test should fail or whether fallback rendering is an accepted product state.
- Do not use letter spacing as a generic correction for Indic text. First verify font coverage, shaping, and the script-specific layout.
A screenshot captured during a fallback-font render can differ in glyph shape, text width, line breaks, and component height. This follows from the font-loading risk Argos describes and the shaping requirements Unicode documents.
5. Stabilize content and capture conditions
Before capturing, make the page repeatable. Argos’s helper addresses several common readiness conditions, but it cannot infer every application-specific state.
- Navigate to the localized route or establish the locale state.
- Wait for a meaningful app-ready signal, such as the main content becoming visible or a loading marker disappearing.
- Ensure the intended web fonts have loaded and verify that the page is not showing a font-loading fallback.
- Use stable test data. Fix dates, sort results deterministically, and avoid randomly generated text or IDs.
- Settle animations and asynchronous widgets. Argos documents automatic handling for some CSS animations; JavaScript-driven motion and app-specific transitions may need a test flag, explicit wait, or targeted masking.
- Capture with a stable name, then review the diff in the Argos workflow.
Mask or hide a region only when it is irrelevant to the comparison. Keep its layout effect if that layout is part of what you are testing. For example, hiding a changing avatar may be reasonable; masking an entire header could conceal a real translation overflow. Avoid third-party scripts in test runs where practical. Argos describes options for dynamic content and external UI in its stabilization guide.
6. Run the test in CI
Run your normal Playwright test command in CI after installing dependencies and the browser required by your project. Here is a minimal GitHub Actions shape based on Argos’s integration guide; retain your project’s Node version, build, and server startup steps.
name: Visual tests
on:
pull_request:
push:
branches: [main]
jobs:
visual:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npm ci
- run: npm exec playwright install --with-deps
- run: npm exec playwright test
Run screenshot baselines in a consistent browser and CI environment. Operating system, browser, font files, rasterization, and hardware can affect pixels. Compare CI captures with CI captures, and do not assume screenshots from different machines will be pixel-identical. Set branch, pull request, retry, and shard behavior according to your repository and the current Argos integration documentation.
7. Locale handling in other Argos workflows
For Playwright, select each locale through your own app’s routing or state and capture it as a distinct screenshot. Argos’s Storybook material describes locale variants through modes, so teams using Storybook can define and capture locale variants there; see the Argos Storybook guide. Argos also documents a Vitest browser-mode workflow; verify its current package and plugin configuration before using it. Do not copy the Playwright reporter setup into Cypress, WebdriverIO, Storybook, or Vitest without checking that runner’s integration.
8. Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Large text diff across the page | Web font arrived late, failed in CI, or lacks the tested script’s glyphs | Inspect font requests and actual rendered font; check script coverage; wait for document.fonts.ready. |
| Conjuncts or vowel marks look wrong | Font or shaping support is missing or a fallback is active | Verify the selected font’s Indic support and inspect representative script strings in the CI browser. Do not mask the text. |
| Text wraps differently in CI | Different font, viewport, browser, or content; late layout shift | Standardize the capture environment and viewport, stabilize content, and wait for fonts and app readiness. |
| Screenshot contains a loader or blank area | Capture happened before app-specific content was ready, or an async request stalled | Wait for a meaningful ready marker; inspect failed requests and loader state. Do not rely only on network idle for apps with background traffic. |
| Intermittent diffs from dates or changing cards | Clock, randomized data, ordering, or third-party content changes between runs | Use fixed test data and deterministic sorting; remove unnecessary external content or target a narrow mask. |
| Animation appears at different frames | JavaScript animation or transition was still active | Disable it in test mode or wait for the stable state. CSS-only overrides may not stop canvas or JavaScript animation. |
| Argos uploads are missing | Reporter is not enabled for that run, test command did not execute, or runner setup differs | Check the CI config and test output against the current Argos runner guide; preserve existing reporters when adding Argos. |
| Locale screenshots show the same language | Route, cookie, or client-side locale state was not set before rendering | Set locale using the application’s supported mechanism and assert a known translated string before capture. |
9. Performance, reliability, and cost considerations
Each locale and viewport adds browser work, so select representative routes and states based on user-visible risk. Keep the matrix intentional: text-heavy pages and components that exercise a script’s shaping or wrapping often provide more useful coverage than duplicating every route mechanically.
Waiting for fonts and application readiness improves reliability but may add time when the page has slow or persistent requests. Prefer explicit app-ready conditions over long fixed sleeps. Use stable fixtures and one canonical CI environment to reduce reruns and noisy reviews. Retries can help diagnose intermittency, but they do not correct the underlying instability.
Argos pricing and plan limits are not specified in the cited setup material here, so check Argos’s current pricing directly before estimating service cost. Your CI runtime, browser installation, and test matrix also affect operating cost.
Or skip the browser setup
ScreenshotNeo is a screenshot API and MCP server for developers. It can capture a URL as PNG, JPEG, WebP, or PDF with one GET request. Its capture flow accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents.
For an ordinary URL capture, this cURL example saves a WebP file:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
Python:
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)
Node.js:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));
See the ScreenshotNeo API documentation for authentication and capture options. Screenshots can use full-page capture, element selectors, device presets or custom viewports, retina scale, dark mode, custom CSS and JavaScript, waits, request blocking, cookies, headers, and more. ScreenshotNeo is useful for capturing pages without maintaining browser setup; an API screenshot is not a replacement for testing your own app’s locale state and asserting that its actual Indic font rendered correctly.
ScreenshotNeo includes 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000 screenshots. Sign up for free and try 1,000 screenshots a month with no card.
FAQ
How do I take Argos screenshots of an Indian-language website?
Use your test runner to open each localized route or state, wait for the app and intended fonts, then call the Argos screenshot helper with a locale-specific name. The Playwright example above shows the pattern.
Why does Hindi or other Indic text look different in CI screenshots?
Check whether the intended font loaded and supports the script, then confirm the browser and viewport match the baseline environment. Indic rendering relies on font coverage and shaping, not just Unicode text being present.
How do I test multiple locales with Argos?
In Playwright, loop through the site’s supported routes or locale states and capture each with a distinct name. For Storybook, check Argos’s locale modes documentation; locale selection is runner-specific.
Does a passing visual diff prove the translation is correct?
No. It indicates whether the rendered image differs from its baseline. A language-aware reviewer should still check wording, shaping, punctuation, and line breaks.


