Cómo localizar capturas de pantalla de la App Store en más de 30 idiomas
Un manual práctico para publicar capturas de pantalla localizadas en la App Store y Google Play sin tener que bifurcar las plantillas por idioma. Cubre la estructura de claves de traducción, la distribución multi-locale, el manejo de RTL, los fallbacks de fuentes y el QA automatizado del layout.
TL;DR
Externaliza cada texto en una clave de traducción, traduce las claves (no la imagen) y luego envía una sola petición a la API con una lista de locales. Screenshots.live renderiza cada locale en paralelo a partir de la misma plantilla: el renderizador se encarga del RTL, el CJK y los overrides por locale.
¿Por qué localizar las capturas de pantalla?
La propia investigación de desarrolladores de Apple constata que los usuarios tienen muchas más probabilidades de instalar una app cuando la ficha de la App Store está en su idioma nativo. Lo mismo está documentado en la checklist de localización de Google: las fichas localizadas convierten más y se posicionan mejor en las búsquedas. Traducir solo los strings de metadatos —título, subtítulo, palabras clave— sin traducir las capturas de pantalla es la solución a medias más habitual, y deja conversión real sobre la mesa porque el activo principal sigue estando en inglés.
El obstáculo para la mayoría de los equipos es operativo, no estratégico. Traducir un set de cinco capturas de pantalla a 30 idiomas a mano significa 150 archivos de diseño, 150 ciclos de revisión y 150 oportunidades para una errata. La solución es tratar las capturas de pantalla como cualquier otra UI localizada: claves en el código, copys en un TMS y layout renderizado en un paso del build.
¿Cómo deberías estructurar las claves de traducción?
Usa la misma estructura de claves que tus traducciones in-app. Agrupa las claves por ID de captura de pantalla y luego por rol del elemento:
{
"screenshots": {
"01_home": {
"headline": "Build faster.",
"subhead": "Ship every store size in one API call.",
"badge": "New"
},
"02_pricing": {
"headline": "Plans for every team.",
"cta": "Start free"
},
"03_api": {
"headline": "Built for developers.",
"subhead": "REST, Fastlane, and GitHub Actions out of the box."
}
}
}Y a continuación el archivo correspondiente en alemán:
{
"screenshots": {
"01_home": {
"headline": "Schneller bauen.",
"subhead": "Alle Store-Formate mit einem API-Call.",
"badge": "Neu"
},
"02_pricing": {
"headline": "Pläne für jedes Team.",
"cta": "Kostenlos starten"
}
}
}Las claves no cambian nunca. Solo cambian los valores. Los traductores trabajan sobre la columna de valores en su TMS sin tocar la plantilla de Screenshots.live.
¿Qué códigos de locale deberías usar?
Usa BCP-47 de forma consistente. Utiliza solo el subtag de idioma cuando no haya variación regional (de, fr, ja) y añade la región solo cuando las variantes diverjan de forma significativa (en-GB vs en-US, pt-BR vs pt-PT, zh-Hans vs zh-Hant). Tanto Apple como Google aceptan BCP-47, aunque sus códigos internos difieren ligeramente: consulta la lista de locales de App Store Connect y los idiomas soportados de Google Play. Mapéalos una sola vez en tu script de CI.
¿Cómo distribuyes los renders entre locales?
La API recibe un ID de plantilla, un catálogo de traducciones y un array de locales. Devuelve un PNG renderizado por locale y por dispositivo:
curl -X POST https://api.screenshots.live/v1/renders \
-H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"templateId": "tpl_app_release_v3",
"locales": ["en", "de", "es", "fr", "pt-BR", "it", "nl", "ja", "ko", "zh-Hans", "ar", "he"],
"devices": ["iphone-6.7", "iphone-6.1", "ipad-12.9", "phone-android"],
"translations": {
"en": "@translations/en.json",
"de": "@translations/de.json",
"es": "@translations/es.json"
}
}'Internamente, el renderizador paraleliza por locale y por dispositivo. Un render de 12 locales × 4 dispositivos —48 archivos PNG— suele completarse en menos de 90 segundos. Consulta los docs de renderizado de la API para ver la forma completa de la petición.
¿Cómo manejas los idiomas de derecha a izquierda?
El árabe (ar), el hebreo (he), el persa (fa) y el urdu (ur) requieren reflejar todo el layout: alineación del texto, posiciones de las imágenes, iconos de flechas e incluso el orden de los grupos de varios elementos. El reflejo a medias (girar solo el texto pero no el layout) le parece incorrecto a los lectores nativos y daña la credibilidad.
En Screenshots.live, marca la plantilla con direction: "auto" y el renderizador girará automáticamente el layout, la alineación del texto y los chevrons decorativos al renderizar locales RTL. Sobrescribe elementos individuales con direction: "ltr" cuando algo deba mantenerse de izquierda a derecha (un número de teléfono, una URL, un bloque de código).
¿Y los overrides de texto por locale?
Algunos idiomas simplemente no caben en la misma caja de texto. Los nombres compuestos del alemán pueden ser un 40% más largos que en inglés; el japonés y el chino pueden ser un 50% más cortos. Permite overrides de texto por locale sin bifurcar la plantilla:
{
"screenshots.01_home.headline": {
"en": "Build faster.",
"de": "Schneller bauen.",
"fi": "Rakenna nopeammin.",
"ja": "もっと速く。"
},
"screenshots.01_home.subhead": {
"en": "Ship every store size in one API call.",
"de": "Alle Formate mit einem Aufruf.",
"ja": "ワンコールで全サイズ対応。"
}
}¿Y las fuentes y los glifos CJK?
Las fuentes con escritura latina (Inter, SF Pro, Roboto) suelen carecer de glifos CJK, cirílicos, devanagari o árabes: el texto se renderiza como cajas tofu. Configura fallbacks de fuentes por escritura:
- Latina / Cirílica / Griega: Inter, SF Pro, Roboto
- CJK (japonés / coreano / chino): Noto Sans CJK
- Árabe / Persa / Urdu: Noto Sans Arabic, IBM Plex Sans Arabic
- Devanagari (hindi): Noto Sans Devanagari
- Tailandés: Noto Sans Thai, Sarabun
La familia Noto cubre todas las escrituras que soportan Apple y Google. Configúrala como una cadena de fallbacks en la plantilla: el renderizador elige la fuente correcta para cada code point sin intervención manual.
¿Cómo haces QA de los layouts a escala?
La revisión manual de 30 locales no escala. Automatiza los modos de fallo evidentes:
- Desbordamiento de texto: renderiza a un cuarto de resolución, aplica OCR al resultado y compáralo con el string de origen. Las discrepancias significan que el texto se ha recortado.
- Glifos faltantes: cuenta las cajas tofu en el PNG renderizado mediante un modelo de visión o un histograma de píxeles sobre el carácter de reemplazo de Unicode.
- Traducciones vacías: haz fallar el build si algún locale tiene más de un 5% de claves faltantes respecto al inglés.
- Presupuestos de longitud: establece un límite de longitud estricto por clave. Si la traducción al alemán lo supera, haz fallar el build en lugar de dejar que se publique con desbordamiento.
¿Cómo subes capturas de pantalla por locale?
Tanto App Store Connect como Google Play aceptan capturas de pantalla por locale. Fastlane deliver lee desde fastlane/screenshots/<locale>/ y Fastlane supply lee desde fastlane/metadata/android/<locale>/images/phoneScreenshots/. Mapea la salida de tu renderizador a esas rutas y el resto es simplemente fastlane deliver / fastlane supply --skip_upload_apk.
¿Qué deberías hacer a continuación?
Combina esto con nuestra guía de automatización CI/CD para que la localización se ejecute en cada release. Usa la funcionalidad de soporte multi-plataforma para distribuir a iOS, Android y stores web desde el mismo catálogo.
Genera todos estos tamaños automáticamente
Deja de redimensionar capturas de pantalla manualmente. Diseña una sola plantilla y renderiza cada tamaño, dispositivo e idioma con una única llamada a la API.
Empieza gratis — Prueba Screenshots.live