Localización e internacionalización
La localización y la internacionalización (L10N e I18N) son dos conceptos que suelen combinarse bajo el término «localización». Sin embargo, son dos cosas distintas, y Unreal Engine (UE) las gestiona de forma diferente. El sistema de localización en UE se basa en nuestro tipo de texto, mientras que nuestra compatibilidad con la internacionalización hace uso de la biblioteca de componentes internacionales para Unicode (ICU).
Si bien son independientes, en UE no es posible tener localizaciones en tiempo de ejecución sin la compatibilidad de internacionalización adecuada.
ICU y soporte de internacionalización
ICU es una biblioteca de internacionalización robusta y consolidada que UE usa para gestionar todo lo relacionado con el procesamiento o los datos específicos de una variante, como por ejemplo:
-
Obtención de la variante para la plataforma o el sistema operativo.
-
Gestión de la reserva priorizada de variantes.
-
Gestión del formato correcto de los números (incluidos los porcentajes y la moneda) y las fechas y horas (incluidos los datos de la zona horaria) de la variante.
-
Gestión del formato correcto del plural en la variante (durante el formato del texto).
-
Gestión de transformaciones de texto compatibles con Unicode (p. ej., ToUpper, ToLower).
-
Gestión de la comparación y el cotejo de texto compatibles con Unicode.
-
Gestión de [análisis de límites] compatibles con Unicode (https://unicode-org.github.io/icu/userguide/boundaryanalysis/) (caracteres, palabras y saltos de línea).
-
Gestión de la detección de texto bidireccional (BiDi) compatible con Unicode.
Los datos específicos de la variante que necesita ICU para funcionar se almacenan fuera de ICU. UE proporciona algunos conjuntos de datos aproximados que puedes usar para minimizar el tamaño de tu proyecto:
-
Inglés (~1,77 MB)
-
EFIGS: inglés, francés, italiano, alemán y español (~2,38 MB)
-
EFIGSCJK: inglés, francés, italiano, alemán, español, chino, japonés y coreano (~5,99 MB)
-
CJK: chino, japonés y coreano (~5,16 MB)
-
Todos (~15,3 MB)
La opción que elijas dependerá de las regiones para las que vayas a localizar tu proyecto. Estas opciones se pueden modificar en la configuración del proyecto. Consulta Empaquetado de datos de localización para obtener más información.
Variantes
En UE, las variantes contienen información de internacionalización para una configuración regional concreta. Los nombres de las variantes culturas se componen de tres partes separadas por guiones (una etiqueta de idioma IETF):
-
Un código de idioma de dos letras ISO 639-1 (por ejemplo, «zh»).
-
Un código de secuencia de comandos opcional ISO 15924 de cuatro letras (por ejemplo, «Hans»).
-
Un código de país opcional ISO 3166-1 de dos letras (por ejemplo, «CN»).
Cuando UE busca datos de localización para una variante en particular, los procesa de más a menos específicos. Por ejemplo:
-
zh-Hans-CN se procesa como «zh-Hans-CN», después como «zh-CN», «zh-Hans» y luego «zh».
-
en-GB se procesa como «en-GB» y, a continuación, como «en».
Para lograr la mayor cobertura de una variante en particular, usa el código de variante menos específico que sea válido. Por lo general, es solo el código de idioma, pero debes ser consciente de las variaciones regionales de idioma que es necesario tener en cuenta.
En la mayoría de los casos, estas variaciones regionales se limitan a un código de país específico, lo que facilita su resolución. Sin embargo, hay algunos casos más complejos, como se muestra a continuación.
Chino
El chino tiene dos variantes, el simplificado y el tradicional, representadas por los códigos de secuencia de comandos ISO-15924 «Hans» y «Hant». Usa «zh+Hans» para la localización de la variante simplificada y «zh+Hant» para la variante tradicional.
Español
El español tiene dos variantes principales: la europea y la latinoamericana. Sin embargo, no existe un código de secuencia de comandos práctico que pueda usarse para distinguir una de otra. Existe una etiqueta de idioma del IETF para el español de Latinoamérica («es-419»), pero la mayoría de las plataformas no la proporcionarán, sino que te darán un código de país real («es-MX»).
Para solucionar este problema, usa «es» para el español de Europa y «es-419» para el español de Latinoamérica. Seguidamente, usa la función de reasignación de variantes de UE para asignar los países latinoamericanos de habla hispana al código «es-419».
Esto se puede hacer añadiendo lo siguiente a tu archivo DefaultGame.ini :
[Internationalization]
+CultureMappings="es-AR;es-419"
+CultureMappings="es-BO;es-419"
+CultureMappings="es-CL;es-419"
+CultureMappings="es-CO;es-419"
+CultureMappings="es-CR;es-419"
+CultureMappings="es-CU;es-419"
+CultureMappings="es-DO;es-419"
+CultureMappings="es-EC;es-419"
+CultureMappings="es-GT;es-419"
+CultureMappings="es-HN;es-419"
+CultureMappings="es-MX;es-419"
+CultureMappings="es-NI;es-419"
+CultureMappings="es-PA;es-419"
+CultureMappings="es-PE;es-419"
+CultureMappings="es-PR;es-419"
+CultureMappings="es-PY;es-419"
+CultureMappings="es-SV;es-419"
+CultureMappings="es-US;es-419"
+CultureMappings="es-UY;es-419"
+CultureMappings="es-VE;es-419"
Objetivos de localización
Los objetivos de localización son módulos autocontenidos con nombre de datos de localización. Los objetivos de localización tienen las siguientes propiedades:
-
Tienen texto recopilado de un conjunto específico de fuentes.
-
Se almacenan en un archivo de manifiesto.
-
Se traducen en archivos de almacenamiento específicos de variantes.
-
Se compilan en archivos de recursos de localización específicos de cada variante y los archivos de recursos compilados específicos de cada variante son los que muestra el sistema.
Un proyecto puede tener un único objetivo de localización para simplificar, o puede tener varios objetivos para dividir los datos de localización del proyecto en secciones. Unreal Editor tiene un objetivo de localización independiente del resto de UE, por lo que el editor puede localizarse sin distribuir esos datos de localización con los juegos. Normalmente, un juego tendrá un objetivo de localización para todos los datos de localización del proyecto base y objetivos de localización adicionales para cualquier ampliación.
Proceso de localización
El proceso de localización se basa en un enfoque de «creado en origen» para la localización. Esto significa que si necesitas un mensaje de texto que diga «¡Hola, mundo!» en la interfaz, solo tienes que escribir «¡Hola, mundo!» en la propiedad del texto (o usa las macros NSLOCTEXT o LOCTEXT en C++) y el recopilador de localización se encarga de capturar el texto para que pueda localizarse.
El enfoque basado la creación en origen es muy dinámico y permite a los desarrolladores no pensar demasiado en la localización durante el desarrollo. Sin embargo, también puede ser frustrante para los equipos que quieren un control estricto sobre el texto usado en su proyecto. Para solucionar esto, UE admite las tablas de cadenas para permitir un enfoque de creación y referencia para la localización (aunque internamente, el proceso solo trata a las tablas de cadenas como otro origen de creación en origen).
Un método antiguo (y ya no compatible) de solucionar la falta de tablas de cadenas nativas consistía en usar una variante de origen «falsa» (probablemente «es-US-POSIX») con identificadores como texto de origen y, a continuación, usar la función de contracción de cadenas que UE tenía antes de la versión 4.14 para traducir estos identificadores a cada idioma. Puede que encuentres referencias a este método en preguntas de soporte antiguas, pero ya no debería usarse. Los proyectos que usen ese método deberían migrarse a tablas de cadenas.
El proceso de localización funciona en objetivos de localización, y un objetivo de localización se compone de dos partes: su configuración (almacenada en Config/Localization/) y sus datos (almacenados en Content/Localization/{TargetName}/).
Si asumimos que el objetivo de localización funciona en inglés («en») y francés («fr»), su disposición en la carpeta Content/Localization/ quedaría así:
{TargetName}/
{TargetName}.manifest
{TargetName}.locmeta
en/
{TargetName}.archive
{TargetName}.po
{TargetName}.locres
fr/
{TargetName}.archive
{TargetName}.po
{TargetName}.locres
Todos los archivos y las carpetas anteriores se generan a partir de las distintas partes del proceso de localización.
| Carpeta | Descripción |
|---|---|
| {TargetName}.manifest |
|
| {TargetName}.archive |
|
| {TargetName}.po |
|
| {TargetName}.locres |
|
| {TargetName}.locmeta |
|
Los objetivos de localización también especifican una variante de origen que debería ajustarse a la variante en la que se crea el contenido (lo que se suele denominar «texto de origen» o «datos de origen»).
Las variantes de origen pueden contener «traducciones» como cualquier otra variante, aunque estas solo existen para facilitar la edición del texto de origen sin tener que editar directamente el código fuente o los recursos.
Las variantes extranjeras usan el texto de la variante de origen como texto de origen para la traducción y quedarán obsoletas si se cambia el texto de la variante de origen (hay un ajuste en el paso de compilación de la localización para permitir traducciones obsoletas si es necesario).
Para obtener más información sobre cómo optimizar tu proceso de localización, consulta Optimización del proceso.
Formato de archivo PO
Unreal Engine usa el siguiente formato predeterminado para sus archivos PO, en función del modo de contracción utilizado en la exportación del archivo PO.
Al usar el modo de contracción Identidad de texto y texto de origen idénticos:
msgctxt contiene la identidad de Unreal Engine de la entrada.
msgid contiene la cadena de origen.
msgstr contiene la traducción.
Al usar el modo de contracción Espacio de nombres y texto de origen idénticos*:
msgctxt contiene el espacio de nombres de Unreal de la entrada.
msgid contiene la cadena de origen.
msgstr contiene la traducción.
También tenemos un formato alternativo que produce mejores resultados si usas Crowdin para gestionar tus traducciones, aunque debes tener en cuenta que este formato no es capaz de detectar traducciones obsoletas importadas de archivos PO (puesto que ya no tenemos el original del que se hizo la traducción).
Este modo produce el mismo resultado al usar el modo de contracción Espacio de nombres y texto de origen idénticos, pero para el modo de contracción Identidad de texto y texto de origen idénticos produce lo siguiente:
msgctxt no se usa.
msgid contiene la identidad de Unreal Engine de la entrada.
msgstr contiene la cadena (para la variante de origen) o la traducción (para variantes extranjeras).
El atributo de encabezado X-Crowdin-SourceKey especifica que se usará msgstr como texto de origen desde la variante de origen.
Empaquetado de datos de localización
Empaquetar los datos de localización e internacionalización correctos para tu proyecto requiere configurar algunos parámetros de la sección de ajustes avanzados de Empaquetado en la configuración del proyecto.
Los dos ajustes que debes verificar son los siguientes:
-
Localizaciones para empaquetar:- con esto, puedes elegir las variantes para las que quieres almacenar los datos de localización. Puedes usar la opción Mostrar localizadas para filtrar la lista y mostrar solo las variantes para las que tienes archivos
LocRes. -
Soporte de internacionalización: esto permite elegir qué conjunto de datos de internacionalización de ICU quieres almacenar. Esta opción debe solaparse con los datos de localización que quieras preparar.