dpis-localization

name	dpis-localization
description	Project-local DPIS localization workflow. Use when adding a new language, machine-translating or reviewing Android string resources, changing existing translations, adjusting AppLocaleManager language options, updating l10n scripts, or reviewing localization-related branch changes.

DPIS Localization

This is a project-local skill bundle. It turns DPIS localization work into a repeatable process for new languages, existing-language maintenance, and review.

Trigger

Use this skill before work involving:

• adding or removing app/src/main/res/values-*/strings.xml
• translating, machine-translating, reviewing, or normalizing strings
• changing language names, locale tags, or manual language choices
• editing AppLocaleManager or the language selector UI
• changing scripts/l10n/**, crowdin.yml, or localization docs
• reviewing a branch whose main surface is Android localization

Required Reads

Read only what applies to the task:

• Always read AGENTS.md.
• For string changes, read app/src/main/res/values/strings.xml and the touched locale file.
• For manual language choices, read app/src/main/java/com/dpis/module/AppLocaleManager.java and the language selector tests.
• For script or workflow changes, read scripts/l10n/README.md and the touched script.
• For review, inspect the diff against the target branch before conclusions.

Translation Frame

DPIS is a technical Android module for per-app DPI, interface scale, font size, and runtime hook configuration. Translate for Android users who understand apps, settings, and basic module concepts, but may not understand every hook detail.

Keep UI copy direct, calm, compact, and practical. Do not add claims, warnings, or explanations that are not present in the source string.

Avoid:

• marketing claims, slogans, jokes, or slang
• over-promising compatibility, stability, or visible effect
• translating internal identifiers or hook domains
• changing the meaning of safety, unsupported, unavailable, or failed states

Technical Terms

Keep these terms in English unless the source string clearly calls for a natural language explanation around them:

• DPIS
• LSPosed
• Xposed
• Android
• WebView
• TextView
• ActivityThread
• Resources
• DisplayMetrics
• Flutter
• HyperOS
• DPI
• dp
• sp
• px
• APK
• API
• GitHub
• WeChat Pay
• Alipay

Follow existing nearby translation style for surrounding text. Do not force a glossary term when it makes the target-language UI unnatural.

Invariants

Preserve exactly:

• Android placeholders such as %1$s, %2$d, %1$d%%, and %%
• escaped newlines such as \n
• URLs, package names, resource-like identifiers, and domain-like identifiers
• strings marked translatable="false" in the default resource file

Keep placeholder order unless the target language requires reordering. If reordering is needed, keep numbered placeholder forms.

Current internal font domains are not user-facing hook-chain switches:

• system_server_font
• activity_thread_font

New Language Workflow

1. Identify the target locale and inspect existing resource qualifiers before choosing the directory name. Prefer matching the repository's current Android qualifier style.
2. Generate or normalize from app/src/main/res/values/strings.xml; do not include default strings marked translatable="false" unless they are intentionally used as local language names in the default file.
3. Preserve placeholder sets, escapes, URLs, package names, and technical terms.
4. Decide whether the language is manually selectable:
   • If it is reviewed or intentionally offered, add the locale tag and label to AppLocaleManager.
   • If it is machine-translated or not reviewed, either leave it reachable only through "Follow system" or label the manual option honestly, such as 日本語（未校正）.
5. Add or update tests that cover resource parity and language selector wiring when the selector changes.
6. Run a focused resource test, then run the full unit suite before submitting unless the user explicitly accepts narrower verification.

Existing Language Workflow

1. Compare the touched locale against default strings by key, placeholder set, and escape usage.
2. Check that translations remain concise and match nearby project wording.
3. Remove stale localized entries for keys that are no longer translatable or no longer exist.
4. Prefer fallback to English over low-confidence translations for risky technical or safety wording.
5. If the change comes from machine translation, mark review state in the user facing label or project docs when the language is manually selectable.

Review Checklist

For localization branch review, check:

• New locale files are reachable as intended: follow-system only or manual selector.
• AppLocaleManager tags match Android resource qualifiers and user-facing labels.
• Machine-translated languages are not silently presented as fully reviewed.
• Placeholder, newline, URL, and package-name parity is intact.
• translatable="false" strings are not duplicated into locale resources unless there is an explicit product reason.
• scripts/l10n/README.md commands match real Gradle tasks.
• Tests cover changed wiring instead of only preserving stale string literals.

Validation Commands

Use real task names from the current Gradle project. Common checks:

./gradlew :app:testModernDebugUnitTest --tests com.dpis.module.StringResourceParityTest
./gradlew :app:testAllDebugUnitTests

For script changes, also run the touched script on a representative input or use its --help output if no safe fixture exists.

Output

When finishing localization work or review, report:

• languages and locale qualifiers touched
• whether each language is reviewed, machine-translated, or intentionally follow-system only
• language selector changes, if any
• scripts or docs changed
• tests or validation commands run