Usar localizaciones y códigos de idioma en el SDK de Capacitor

Por qué esto es importante

Los códigos de idioma entran en juego cuando Adapty elige la localización para un flow o un onboarding, y cuando lees un Remote Config para un paywall personalizado.

Los códigos de idioma son complejos y pueden variar de una plataforma a otra, por lo que Adapty se basa en un estándar interno único para todas las plataformas que admite. Entender ese estándar te ayuda a predecir qué localización recibirá cada usuario.

Estándar de códigos de idioma en Adapty

Para los códigos de idioma, Adapty utiliza una versión ligeramente modificada del estándar BCP 47: cada código se compone de subetiquetas en minúsculas separadas por guiones. Algunos ejemplos: en (inglés), pt-br (portugués (Brasil)), zh (chino simplificado), zh-hant (chino tradicional).

Coincidencia de códigos de idioma

En SDK v4, los flows y los onboardings coinciden con los códigos de idioma de forma diferente: los flows se localizan mediante el SDK en el dispositivo, y los onboardings mediante el servidor de Adapty.

Flows y paywalls del Paywall Builder

Un paywall construido en el Paywall Builder se entrega como un flow en el SDK v4, por lo que la regla siguiente aplica a ambos.

La coincidencia es exacta. El SDK compara el código que pasas con los códigos de localización del flow carácter a carácter: no cambia mayúsculas ni minúsculas, no reemplaza guiones bajos (_) por guiones (-), y no recurre al subtag de idioma. Para un flow con localización pt-br, solo pt-br coincide: pt-BR, pt_BR y pt-PT no coinciden.

Cuando el código no coincide con ninguna localización, el flow se renderiza en silencio en su configuración regional predeterminada: el SDK no devuelve un error ni registra ninguna advertencia.

Cuando el código coincide, Adapty combina la localización con la predeterminada: las cadenas de texto y los recursos que no estén definidos en la localización encontrada se obtienen de la localización predeterminada.

Omitir el código de idioma no es lo mismo que pedir la localización predeterminada del flow: el SDK sustituye un en fijo. Un flow cuya localización predeterminada sea de seguirá renderizándose en en si tiene una localización en, y solo recurrirá a de cuando no la tenga.

Onboardings

Los onboardings se localizan en el servidor, y las reglas del servidor toleran otros formatos. Cuando pasas un locale a getOnboarding:

1. La cadena de configuración regional se convierte a minúsculas y todos los guiones bajos (_) se reemplazan por guiones (-)
2. Adapty busca la localización con el código de configuración regional que coincida exactamente
3. Si no se encuentra ninguna coincidencia, Adapty toma la subcadena anterior al primer guión (pt para pt-br) y busca la localización que coincida
4. Si tampoco se encuentra ninguna coincidencia, Adapty devuelve el contenido en la configuración regional predeterminada del onboarding

Esta forma, pt_BR, pt-BR y pt-br se resuelven todas en la misma localización de onboarding.

Implementación de localizaciones

En el SDK v4, no se pasa un código de idioma al obtener un flow — getFlow devuelve el flow con todas sus localizaciones, y Adapty aplica una cuando se construye la vista del flow.

• Flows creados en el builder: el SDK no lee el idioma del dispositivo, así que resuélvelo en tu app y pásalo como opción locale en createFlowView. Es opcional — si lo omites, el flow se renderiza en en, o en su idioma predeterminado cuando el flow no tiene localización en en.

  import { createFlowView } from '@adapty/capacitor';
  
  const view = await createFlowView(flow, { locale: 'es' });

view.locale informa la localización con la que se construyó la vista. Tanto la opción locale como view.locale requieren Capacitor SDK 4.0.1-beta.1, y view.locale es undefined en versiones anteriores. El manejador onAppeared informa el mismo valor.

• Paywalls personalizados (Remote Config): getFlow devuelve todas las localizaciones configuradas en flow.remoteConfigs. Cada entrada tiene un código lang y un objeto data. Selecciona la entrada que coincida con el usuario, con tu propio fallback:

const flow = await adapty.getFlow({ placementId: 'placement_id' });
const config = flow.remoteConfigs?.find((c) => c.lang === 'en') ?? flow.remoteConfigs?.[0];
// read your values from config?.data

Adapty almacena esos códigos lang en el formato descrito en Estándar de código de idioma en Adapty. El SDK no compara los Remote Configs con un idioma concreto, por lo que es tu app quien decide qué entrada aplicar.

Por qué esto es importante

Hay varios escenarios en los que los códigos de idioma entran en juego; por ejemplo, cuando intentas obtener el paywall correcto para la localización actual de tu app.

Como los códigos de idioma son complejos y pueden variar de una plataforma a otra, usamos un estándar interno para todas las plataformas que soportamos. Sin embargo, precisamente por esa complejidad, es fundamental que entiendas exactamente qué estás enviando a nuestro servidor para obtener la localización correcta y qué ocurre después, de modo que siempre recibas lo que esperas.

Estándar de códigos de idioma en Adapty

Para los códigos de idioma, Adapty utiliza una versión ligeramente modificada del estándar BCP 47: cada código está formado por subetiquetas en minúsculas separadas por guiones. Algunos ejemplos: en (inglés), pt-br (portugués de Brasil), zh (chino simplificado), zh-hant (chino tradicional).

Coincidencia de códigos de idioma

Cuando Adapty recibe una llamada desde el SDK con el código de idioma y comienza a buscar la localización correspondiente de un paywall, ocurre lo siguiente:

1. La cadena de idioma recibida se convierte a minúsculas y todos los guiones bajos (_) se reemplazan por guiones (-)
2. A continuación, se busca la localización con el código de idioma que coincida exactamente
3. Si no se encuentra ninguna coincidencia, se toma la subcadena anterior al primer guión (pt en pt-br) y se busca la localización correspondiente
4. Si tampoco se encuentra ninguna coincidencia, se devuelve el contenido del idioma predeterminado del paywall

De este modo, un dispositivo iOS que envíe 'pt_BR', un dispositivo Android que envíe pt-BR y otro dispositivo que envíe pt-br obtendrán el mismo resultado.

Implementación de localizaciones: forma recomendada

Si estás pensando en localizaciones, es probable que ya estés trabajando con los archivos de cadenas localizadas en tu proyecto. En ese caso, te recomendamos añadir un par clave-valor con el código de idioma de Adapty correspondiente en cada uno de tus archivos de localización. Después, extrae el valor de esa clave al llamar a nuestro SDK, así:

// 1. Modify your localization files (e.g., using react-i18next)

/*
en.json
*/
{
  "adapty_paywalls_locale": "en"
}

/*
es.json
*/
{
  "adapty_paywalls_locale": "es"
}

/*
pt-BR.json
*/
{
  "adapty_paywalls_locale": "pt-br"
}

// 2. Extract and use the locale code

const MyComponent = () => {
  const { t } = useTranslation();
  
  const fetchPaywall = async () => {
    const locale = t('adapty_paywalls_locale');
    // pass locale code to adapty.getPaywall or adapty.getPaywallForDefaultAudience method
    const paywall = await adapty.getPaywallForDefaultAudience('placement_id', locale);
  };
};

Así te aseguras de tener control total sobre qué localización se recuperará para cada usuario de tu app.

Implementación de localizaciones: el otro método

Puedes obtener resultados similares (aunque no idénticos) sin definir explícitamente códigos de idioma para cada localización. Eso implicaría extraer un código de idioma de otros objetos que proporciona tu plataforma, así:

const getLocaleCode = () => {
  if (Capacitor.getPlatform() === 'ios') {
    return navigator.language || 'en';
  } else {
    return navigator.language || 'en';
  }
};

const fetchPaywall = async () => {
  const locale = getLocaleCode();
  // pass locale code to adapty.getPaywall or adapty.getPaywallForDefaultAudience method
  const paywall = await adapty.getPaywallForDefaultAudience('placement_id', locale);
};

Ten en cuenta que no recomendamos este enfoque por varias razones:

1. En iOS, los idiomas preferidos y el locale actual no son idénticos. Si quieres que la localización se seleccione correctamente, tendrás que apoyarte en la lógica de Apple, que funciona de forma automática si usas el enfoque recomendado con archivos de cadenas localizadas, o recrearla manualmente.
2. Es difícil predecir exactamente qué recibirá el servidor de Adapty. Por ejemplo, en iOS es posible obtener un locale como ar_OM@numbers='latn' en un dispositivo y enviarlo a nuestro servidor. En ese caso, en lugar de la localización ar-om que buscabas, obtendrás ar, lo cual probablemente no sea lo esperado. Should you decide to use this approach anyway — make sure you’ve covered all the relevant use cases.