mcpField
1
1k-i18n

1k-i18n

github.com/onekeyhqDevelopment2.5k72 installsUpdated today
Repository

About 1k-i18n

A OneKey repository skill for managing localization and translation changes. It covers translation-key reuse and naming, Lokalise project and language checks, locale coverage, and verification of generated files.

Key features

  1. 01Search for existing translation keys
  2. 02Verify Lokalise project and languages
  3. 03Create keys and sync translations
  4. 04Maintain translations across repository locales
  5. 05Review generated translation-file changes

Use cases

  1. 01Add a new translation key
  2. 02Update an existing Lokalise translation
  3. 03Pull locale files and inspect generated diffs
  4. 04Validate translation coverage and placeholders

MCP support

The guide notes that a configured Lokalise MCP may be used to look up an existing translation. It requires verifying the target project and languages before remote changes.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/onekeyhq/app-monorepo --skill 1k-i18n

After installing, type/1k-i18nin Claude Code to confirm it loaded.

Bundled filesreferences/rules/i18n.md

Details

From the project README

Internationalization (i18n)

Guidelines for internationalization and translation management in OneKey.

Critical Restrictions

ABSOLUTELY FORBIDDEN (auto-generated files):

// ❌ NEVER modify these files - they are AUTO-GENERATED
// @onekeyhq/shared/src/locale/enum/translations.ts
// @onekeyhq/shared/src/locale/json/*.json

// ❌ NEVER hardcode text strings
<Text>Confirm</Text>

// ✅ CORRECT - Always use translation keys
import { ETranslations } from '@onekeyhq/shared/src/locale';
intl.formatMessage({ id: ETranslations.global__confirm })

Consequences of violation:

  • Translation system corruption
  • Loss of translation work
  • Build failures in i18n pipeline
  • Breaking localization for international users

Existing Keys First

Search locally and remotely before creating a key. Reuse a key only when its meaning, placeholders, and UI context match.

For any Lokalise create or update:

  • Verify the actual target project name and ID before mutating it.
  • Fetch that project's configured languages; do not infer them from an environment-variable name.
  • Prefer repository scripts and credential wrappers. yarn op is the default; keychain and oenv variants are supported alternatives.
  • A configured Lokalise MCP or Lokalise Web may be used for an existing translation, but the same project and language checks still apply.
  • After the remote change, sync locally with yarn i18n:pull, yarn i18n:pull:keychain, or yarn i18n:pull:oenv.

Key Shape Mapping

The same translation may appear in 3 different shapes depending on where you look:

Lokalise / MCP source key:     global::contact_us
Pulled local JSON key:         global.contact_us
Generated enum member:         ETranslations.global_contact_us

For newer suffix-style keys, Lokalise and local JSON usually match:

Lokalise / MCP source key:     address_book__action
Pulled local JSON key:         address_book__action
Generated enum member:         ETranslations.address_book__action

Query guidance:

  • Lokalise / MCP: prefer the exact source key. Legacy namespaced keys often use ::.
  • Local yarn i18n:search: searches pulled en_US.json, so legacy keys should be queried with ., while newer suffix-style keys should be queried with __.
  • Code usage: refer to the generated ETranslations member with _.

End-to-End Delivery Requirements

For any task that creates or updates a translation:

  1. Check the current branch and worktree before pulling generated files.
  2. Resolve credentials without printing tokens.
  3. Retrieve GET /projects/{project_id} and confirm the returned project name and ID match the intended target.
  4. Retrieve GET /projects/{project_id}/languages and record its exact lang_iso values.
  5. Search for the exact key in that verified project before creating it.
  6. Use yarn i18n:add for a missing key. It only creates en_US and optional zh_CN source translations; it does not complete the remaining locales.
  7. Ensure the key has valid translations for every checked-in locale. The repository currently has 19 locale JSON files.
  8. Pull generated files, verify the enum and all locale JSON files, and inspect the full generated diff for unrelated remote updates.
  9. Wire the generated ETranslations member in code and validate placeholder consistency.

Do not silently skip a repository locale because the target project uses a different code format. Map repository locale names to the project's configured lang_iso values. If the project genuinely lacks a required language, stop before upload and report the mismatch.

The completion report must state the verified project name/ID, covered locale set, pull command used, generated-file scope, and any unrelated keys brought in by the pull. Review code changes separately from generated locale changes.

Read i18n.md before performing any remote Lokalise mutation or i18n:pull. It contains the project preflight, current 19-locale set, translation-record update flow, and generated-diff verification.

Quick Reference

Using Translations in Components
import { useIntl } from 'react-intl';
import { ETranslations } from '@onekeyhq/shared/src/locale';

function MyComponent() {
  const intl = useIntl();

  return (
    <SizableText>
      {intl.formatMessage({ id: ETranslations.global__confirm })}
    </SizableText>
  );
}
Using formatMessage Outside Components
import { appLocale } from '@onekeyhq/shared/src/locale/appLocale';
import { ETranslations } from '@onekeyhq/shared/src/locale';

const message = appLocale.intl.formatMessage({
  id: ETranslations.global__cancel,
});

Translation Workflow

  1. Search first
    • Local search: yarn i18n:search "global.contact_us" or yarn i18n:search "address_book__action"
  2. Verify the target — confirm project name/ID and fetch exact project languages
  3. Search remotely — query the exact source key, such as global::contact_us, in that verified project
  4. If the key already exists, update it in Lokalise by translation record
  5. If it is a new key, add it via yarn i18n:add using the suffix-style underscore format
  6. Complete every repository locale — do not stop after en_US/zh_CN
  7. Pull and inspect — verify the key everywhere and call out unrelated generated changes
  8. Use in code:
    {intl.formatMessage({ id: ETranslations.global_contact_us })}
    

New Key Naming Pattern

semantic_key__type

Examples:
- send__title
- confirm_send__action
- enter_send_amount__desc
- transaction_failed__msg

Detailed Guide

For comprehensive i18n guidelines and the end-to-end Lokalise workflow, see i18n.md.

Topics covered:

  • Translation management restrictions
  • Using translations in components
  • Translation key naming conventions
  • Target project and language verification
  • Full 19-locale coverage
  • Safe Lokalise create/update and pull flow
  • Generated-diff inspection
  • Locale handling and fallbacks
  • Code examples

Key Files

PurposeFile Path
Translation enum (auto-generated)packages/shared/src/locale/enum/translations.ts
Locale JSON (auto-generated)packages/shared/src/locale/json/
App localepackages/shared/src/locale/appLocale.ts
Default localepackages/shared/src/locale/getDefaultLocale.ts
Lokalise add scriptdevelopment/scripts/i18n/i18n-add.js
Lokalise pull scriptdevelopment/scripts/i18n/i18n-pull.js

Related Skills

  • /1k-coding-patterns - Date formatting with locale support
  • /1k-coding-patterns - General coding patterns

Comments

Markdown supported