Translate Strings

Translate Strings

Translating a string here is not a lookup — it is writing the same UX copy in another language. Read the string's usage context before translating it, and match the tone rules in the root AGENTS.md (active voice, present tense, sentence case, name the concrete thing) in the target language's own idiom, not a literal transliteration of the English sentence structure.

Supported Languages

If asked to add a language outside this table, confirm the language and its folder qualifier with the user before creating files — don't guess a BCP-47 tag.

Control Language: Slovak (values-sk)

English (values/strings.xml) is still the canonical source for keys, placeholders, and structure — but English UI copy is often terse enough to be ambiguous about the actually-intended nuance. Slovak (values-sk) is this app's control translation: the app owner personally reviews and corrects it, so a confirmed Slovak string encodes the verified intended meaning, tone, and terminology choice more precisely than the English source alone.

When translating a string into any language other than Slovak, read both the English source and the Slovak translation before writing the target-language text — use English for literal meaning and structure, and Slovak to resolve tone, nuance, or ambiguity English leaves open. Where the two would suggest different readings, follow the interpretation Slovak embodies, since it reflects reviewed intent rather than a first-pass translation. If a Slovak entry doesn't exist yet for a key, fall back to English alone and say so rather than guessing what a not-yet-written control would say.

Don't translate from Slovak's grammar — its declension and word order don't transfer to unrelated languages. Slovak is a meaning/tone reference; English remains the structural source (placeholder count and order, key names, sentence type).

Android Platform Vocabulary

Activity, Service, Receiver (Broadcast Receiver), Provider (Content Provider), Intent filter, Permission, Manifest, Package, APK, SDK are Android platform terms, not ordinary English prose — this app's strings already render them as short category labels (components_type_activities = "Activities", components_scope_providers = "Providers", etc., see feature/app-detail/impl/src/main/res/values/strings.xml). The right call is neither "always translate" nor "always keep English" — it's use whichever term Android's own official localization already uses for that exact word in that language, so it matches what a user may already recognize from Android Studio, developer.android.com, or the Play Console in their language:

• Google officially localizes Android developer docs for: Spanish, Japanese, Korean, Portuguese (Brazil), Russian, Chinese (Simplified/Traditional), Indonesian, Turkish, Vietnamese — largely overlapping with this table's es, ja, ko, pt-rBR, ru, zh-rCN, in, tr, vi. For these, use the exact term developer.android.com uses in that locale for Activity/Service/ Receiver/Provider/etc. Verify the current term rather than recalling it from memory or an old session — Google's supported-docs-language list and its terminology both drift over time.
• Not officially localized: German, French, Italian, Polish, Slovak, Czech, Ukrainian, Arabic, Hindi. For these, the established local Android developer convention is almost always to keep the English term as a loanword (Activity, Service, Broadcast Receiver, Content Provider) — that also avoids inventing a translation no one in that market's Android ecosystem actually uses.
• APK, Intent, Manifest stay in English in effectively every language, including ones with localized docs — they function as fixed technical terms across the whole Android world, the same way this skill already treats APK elsewhere.
• If you're not sure for a specific language/term pair, say so and check developer.android.com in that locale (or ask) instead of guessing silently — getting this wrong reads as a translation that doesn't know the platform, which undermines trust more than an occasional English loanword would.

Always-English Keys

A handful of specific keys are pinned to the exact English source text in every language, Slovak included — not translated, not adapted. These are deliberate app-owner calls (not derivable from the general platform-vocabulary rule above), so don't second-guess them into translation during an audit:

• permission_label_wake_lock → Wake lock. The English source string itself reads "Keep Device Awake" (plain prose, not this term) — every locale still renders the Android API name Wake lock instead of translating that source sentence. This is an intentional exception to "translate the English source," not an oversight.
• permission_label_ad_id → Advertising ID, permission_label_ad_attribution → Ad Attribution, permission_label_ad_custom_audience → Ad Audiences, permission_label_ad_topics → Ad Topics (all core/app-permissions).
• permission_label_bluetooth_advertise → Bluetooth Advertise (core/app-permissions).
• permissions_level_dangerous / _signature / _internal / _normal (feature/app-detail/impl) and their browse_protection_level_* counterparts (feature/browse/impl) → Dangerous / Signature / Internal / Normal.
• app_detail_target_sdk and general_info_target_sdk (feature/app-detail/impl) → Target SDK. sort_target_sdk (feature/apps/impl) → Target Android SDK (matches that key's own English source, which includes "Android" where the other two don't — copy each key's own default text verbatim rather than harmonizing the three into one phrase).

If a new key looks like it belongs in one of these families (e.g. a future permission_label_ad_* or another *_target_sdk label), ask before deciding whether it joins the always-English set or gets a normal translation — don't extend the pattern by inference.

Scope: One Module at a Time

Every module with a values/strings.xml gets its own values-<qualifier>/strings.xml with the exact same key set.

Translate module by module. Don't merge keys from different modules into one file, and don't create a locale folder for a module that has no values/strings.xml.

Order of Work: String-by-String vs Language-by-Language

For a small batch of new or changed strings, translate string-by-string across all languages, not language-by-language across all strings. Reading the usage context (workflow step 3 below) is the expensive, error-prone part — do it once per string, then produce every language's translation while that context and its resolved meaning are still fresh. Translating language-by-language for a handful of new keys means re-deriving the same context up to 18 times and risks resolving an ambiguous string differently on different passes. Translate Slovak first (or immediately after confirming the English meaning) among the batch, since it's the control language — having it settled gives you, and the user on review, a second concrete reference before propagating to the remaining languages.

The exception is a large-scale audit of many already-existing strings (a full-module or full-app correctness review, not a handful of new keys) — group that by language instead. A single sustained pass through one language builds up internal terminology and register consistency across the whole file that a string-by-string pass would fragment, and it parallelizes cleanly across languages when multiple reviewers (human or agent) are available.