vtex-io-messages-and-i18n

Replace hardcoded user-facing strings with vtex.messages-backed localized copy in VTEX IO apps.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/exilonX/ap2 --skill vtex-io-messages-and-i18n-exilonx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vtex-io-messages-and-i18n
Source: https://github.com/exilonX/ap2/tree/main/.agents/skills/vtex-io-messages-and-i18n
Command: npx skills add https://github.com/exilonX/ap2 --skill vtex-io-messages-and-i18n-exilonx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

VTEX IO apps often ship with hardcoded, non-localizable user-facing text that becomes inconsistent across storefront and Admin experiences, making translation and reviews painful.

Core Features & Use Cases

  • Centralized localization via vtex.messages: Keep UI strings discoverable and resolvable through VTEX’s messages runtime instead of embedding literals in components.
  • Translation contract with explicit keys: Define app-scoped message IDs in messages context and back them with /messages/*.json files for each locale.
  • Guardrails for correct usage: Ensure user-facing strings come from the messages infrastructure, keep keys stable and organized, and avoid using message files for configuration or secrets.

Use this skill for adding or refactoring localized storefront/Admin/backend flows that display translated labels, buttons, headings, alerts, or user-facing copy.

Quick Start

Update your VTEX app’s messages/context.json and /messages/*.json files to declare and translate the message keys your UI or backend responses use.

Frequently Asked Questions about vtex-io-messages-and-i18n

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I localize hardcoded user-facing strings in VTEX IO apps?

You can localize VTEX IO apps by replacing hardcoded UI text with vtex.messages-backed copy, defining app-scoped message IDs in a messages context, and managing translation payloads in /messages/*.json files for each locale.

What is the best way to structure translation files for a VTEX storefront?

The best way to structure VTEX translation files is maintaining small, locale-specific /messages/*.json payloads explicitly declared in messages context, ensuring strict separation from configuration or secrets to keep UI strings discoverable and resolvable.

When do I need to use react-intl with vtex.messages for internationalization?

You need to use react-intl with vtex.messages when adding or refactoring localized storefront or Admin flows that display translated labels, buttons, headings, or alerts, ensuring user-facing strings come from the messages infrastructure.

Can I use vtex.messages to manage backend or GraphQL localized responses?

Yes, vtex.messages can be used from backend or GraphQL boundaries to handle localized responses, provided you define stable, app-scoped message IDs and back them with the appropriate /messages/*.json payloads for each locale.

Why should translation keys be kept separate from configuration in VTEX apps?

Translation keys should be kept separate from configuration in VTEX apps because message files are designed strictly for localized UI copy, and mixing them with secrets or configuration violates internationalization guardrails and makes translation reviews painful.