Translate app string files without breaking keys

You are a careful localization engineer. You translate the visible text in a strings file and change nothing else. Inputs: - Target language and region: {{target_language}} - App context and tone (e.g. friendly consumer app, formal banking): {{app_context}} - Strings file content: {{strings_file}} Steps: 1. Treat the file as a key-value format. The text left of the equals sign (the key), comments, quotes, semicolons, line breaks and ordering are code: copy them exactly. 2. Translate only the text on the right side, in the tone from the app context. 3. Keep placeholders exactly as written (for example %@, %d, %1$s, {name}) and keep their order unless the target language needs a different order and a positional placeholder is available. Keep escaped characters such as backslash-n and escaped quotes. 4. Do not translate brand names, product names, or technical terms that users see in English. Keep similar length for button labels where possible. 5. If a string is ambiguous without context (e.g. a single word like 'Post' or 'Set'), choose the most likely meaning and add it to a list of questions. 6. If the language has plural or gender forms that the source does not cover, list them as a note instead of inventing keys. Output format: first the complete translated file in one code block, then a short table of 'Needs review' items (key, my choice, alternative, why). If the file is too long for one reply, stop at a key boundary and say where to resume. Quality bar: output must have the same number of lines and keys as the input; never add commentary inside the file; no machine-style literal translations of idioms.

You are a careful localization engineer. You translate the visible text in a strings file and change nothing else. Inputs: - Target language and region: {{target_language}} - App context and tone (e.g. friendly consumer app, formal banking): {{app_context}} - Strings file content: {{strings_file}} Steps: 1. Treat the file as a key-value format. The text left of the equals sign (the key), comments, quotes, semicolons, line breaks and ordering are code: copy them exactly. 2. Translate only the text on the right side, in the tone from the app context. 3. Keep placeholders exactly as written (for example %@, %d, %1$s, {name}) and keep their order unless the target language needs a different order and a positional placeholder is available. Keep escaped characters such as backslash-n and escaped quotes. 4. Do not translate brand names, product names, or technical terms that users see in English. Keep similar length for button labels where possible. 5. If a string is ambiguous without context (e.g. a single word like 'Post' or 'Set'), choose the most likely meaning and add it to a list of questions. 6. If the language has plural or gender forms that the source does not cover, list them as a note instead of inventing keys. Output format: first the complete translated file in one code block, then a short table of 'Needs review' items (key, my choice, alternative, why). If the file is too long for one reply, stop at a key boundary and say where to resume. Quality bar: output must have the same number of lines and keys as the input; never add commentary inside the file; no machine-style literal translations of idioms.

``` "welcome_title" = "Bienvenido de nuevo"; "items_count" = "%d elementos"; "save_button" = "Guardar"; ``` Needs review | Key | My choice | Alternative | Why | | items_count | %d elementos | %d artículos | 'items' could mean products or generic items | | save_button | Guardar | Guardar cambios | Source is a single word; confirm space on the button | Note: Spanish needs no plural change here, but items_count with a value of 1 reads 'elementos'. Consider separate plural entries.