i18n

Add or update i18n resources for multi-language UI projects.

5.5k|794|Updated Nov 26, 2025
One-click install
npx skills add https://github.com/shiaho777/web-to-app --skill i18n-shiaho777
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: i18n
Source: https://github.com/shiaho777/web-to-app/tree/main/app/src/main/assets/skills/i18n
Command: npx skills add https://github.com/shiaho777/web-to-app --skill i18n-shiaho777

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Add or update translations for an app in a way that matches the project's existing i18n structure, reducing drift and making localization scalable.

Core Features & Use Cases

  • Extract visible strings from UI and map them to language files (for example i18n/en.json, i18n/zh.json) or a dedicated messages.js module.
  • Propose a minimal translation shape if none exists and ensure language codes follow ISO 639-1; handle RTL where appropriate.
  • Avoid translating code identifiers or internal IDs; preserve existing keys to maintain consistency across updates.

Quick Start

Create or update language files to align with the project's i18n structure.

Frequently Asked Questions about i18n

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

FAQPage Schema
How do I add multilingual UI translations to an existing app structure?

You can update translations by modifying i18n resources like i18n/en.json or messages.js to align with your project's structure, preserving existing keys while expanding multilingual coverage.

What is the best way to handle UI internationalization for web and mobile projects?

UI internationalization is handled by extracting visible strings, mapping them to language files, enforcing ISO 639-1 language codes, and configuring RTL handling where appropriate for multilingual UX.

How do I avoid translating code identifiers when extracting strings for localization?

To avoid translating code identifiers during localization, the process strictly extracts only visible UI strings into language files while leaving internal IDs and code identifiers untouched.

Does this i18n approach support RTL handling and standard language codes?

Yes, this i18n approach supports RTL handling where appropriate and enforces standard ISO 639-1 language codes to ensure your multilingual UI adheres to recognized localization formats.

What storage formats can I use for app translations and multilingual strings?

You can use common storage formats such as JSON language files (e.g., i18n/en.json, i18n/zh.json) or a dedicated messages.js module to centralize app translations and manage multilingual strings effectively.

Why should I preserve existing keys when updating language files?

Preserving existing keys when updating language files prevents localization drift, maintains consistency across updates, and ensures your app's i18n structure remains scalable as you add new multilingual translations.