¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Symfony 5
  3. Internacionalizar las aplicaciones Symfony
Extrait - Symfony 5 Desarrolle sitios web PHP estructurados y eficientes
Extractos del libro
Symfony 5 Desarrolle sitios web PHP estructurados y eficientes Volver a la página de compra del libro

Internacionalizar las aplicaciones Symfony

Introducción

1. Locale, internacionalización y regionalización

Cualquier sitio web contiene una gran cantidad de datos textuales para que el usuario los lea. Si elimináramos todo el código informático de su proyecto, todavía habría una parte significativa de mensajes, textos y contenido en castellano dispersos por sus templates, controladores y bases de datos.

Si desea transformar su sitio web, que está exclusivamente en castellano, en un sitio web multiidioma, hay que modificar muchas capas de la aplicación. La tarea se puede volver difícil rápidamente o incluso hacer que su proyecto sea ilegible si no elige las herramientas adecuadas.

Afortunadamente, Symfony tiene un componente encargado de gestionar las traducciones de un sitio con flexibilidad y simplicidad. Antes de descubrirlo, primero es necesario definir algunos términos.

a. Locale

El locale es un identificador que representa principalmente el idioma del usuario, así como otros posible parámetros de idioma, como el país.

El valor del identificador de referencia cultural es libre. Sin embargo, Symfony recomienda utilizar el código de idioma ISO639-1 y, opcionalmente, un underscore y un código de país ISO3166 Alpha-2.

Estos son algunos ejemplos válidos de identificadores de referencia locale:

  • es: un usuario español.

  • es_AR: un usuario español en Argentina....

Detectar la referencia al locale de un usuario

1. Las técnicas

a. Negociación de contenido

El protocolo HTTP admite un mecanismo llamado negociación de contenido. Permite devolver diferentes representaciones (llamadas variantes) de un recurso en función de una serie de criterios, incluido el locale del usuario. Estos criterios se envían en cabeceras HTTP cuando se hace la petición del cliente.

Sin embargo, esta técnica puede dañar el SEO de su sitio. Google también lo desaconseja y, en su lugar, recomienda una URL distinta para cada idioma de una página determinada.

b. Por la URL

La segunda técnica consiste en utilizar una URL por idioma.

El locale del usuario se puede colocar en una URL de diferentes maneras. A continuación, se muestran algunos ejemplos de URL para una página de un sitio web italiano:

  • http://mi-proyecto.it/mi-pagina: uso de un dominio nacional de primer nivel (o ccTLD). A diferencia del dominio genérico de nivel superior (como .com, .org, .net, etc.), el ccTLD está asociado a un país. Sin embargo, esta estructura de URL es bastante restrictiva porque le obliga a adquirir un nuevo nombre de dominio para cada nuevo idioma que desee admitir. Por esta razón, queda reservado para sitios web con un gran presupuesto.

  • http://it.mi-proyecto.com/mi-pagina: uso de un subdominio como complemento de un dominio de primer nivel genérico...

Activación de las traducciones

1. El componente translator

Para establecer el sistema de traducción de Symfony, en primer lugar es necesario instalar el componente translator. Si ha creado su aplicación usando el modelo de aplicación (symfony/website-skeleton), entonces ya está instalado, pero, de lo contrario, ejecute la recipe Flex adecuada con el comando:

composer require symfony/translation 

2. Configuración del framework

El sistema de traducción proporcionado por el componente translator ofrece el archivo de configuración config/packages/translation.yaml con el siguiente contenido predeterminado:

# config/packages/translation.yaml  
framework:  
   default_locale: en  
   translator:  
       default_path: '%kernel.project_dir%/translations'  
       fallbacks:  
             en 

Contiene el locale predeterminado (default_locale) y el directorio de traducción predeterminado (default_path). Este es el directorio de traducciones ubicado en la raíz de su proyecto.

Obviamente, una primera adaptación importante de este archivo es ajustar el locale predeterminado de su aplicación: es es un buen valor si desea que su aplicación sea nativa en castellano.

También...

Rutas y traducciones

Anteriormente, hemos explicado que, para crear un sitio web multiidioma, debe indicar el locale del usuario en la URL. Symfony lo hace posible gracias al parámetro especial de enrutamiento _locale:

home:    
   path:      /{_locale}/home   
   controller: App\DefaultController::home   
   requirements:    
       _locale: en|es 

Aquí definimos una ruta multiidioma para la acción home de uno de nuestros controladores. Se podrá acceder a esta acción usando dos URL:

  • http://mi-proyecto.local/en/home

  • http:// mi-proyecto.local/es/home

Cuando accede a cualquiera de estas rutas, Symfony coloca el locale del usuario en en o es para inglés y castellano, respectivamente.

Archivos de traducción

1. Organización y reglas de nomenclatura

Los archivos de traducción se deben guardar en el directorio translations/ del proyecto y deben seguir estrictas reglas de nomenclatura.

a. Regla de nomenclatura

Los nombres de los archivos de traducción siguen una sintaxis determinada: dominio.locale.formato.

locale

La configuración regional se corresponde con el locale de las traducciones contenidas en el archivo. Cada archivo solo puede contener un locale, es decir, no puede definir traducciones al inglés y al castellano en el mismo archivo.

format

Los archivos de traducción de Symfony pueden utilizar diferentes formatos. Para las traducciones de rutas, vamos a utilizar YAML porque es el más fácil de configurar, pero también existen XLIFF y PHP.

XLIFF es una extensión del lenguaje XML específica para la regionalización. Este formato es más estándar que YAML, pero mucho más expresivo. Una vez que esté familiarizado con las traducciones, le recomendamos que cambie YAML por XLIFF.

domaine

El dominio es una forma de organizar las traducciones. En cierto modo, es el equivalente del espacio de nombres para las clases PHP: principalmente, permite evitar conflictos.

El dominio predeterminado es messages; veremos más adelante cómo especificar el dominio cuando se traduzca un mensaje.

Ejemplos de ubicaciones de archivos de traducción...

Traducir un mensaje

1. El servicio translator

El servicio translator se utiliza para traducir mensajes. Así es como se debe usar desde una acción:

...  
use Symfony\Contracts\Translation\TranslatorInterface;  
  
...  
  
public function hola(TranslatorInterface $translator)  
{  
   $mensaje = $translator->trans('Hola');  
   return new Response($mensaje);   
} 

Para traducir el mensaje al inglés, por ejemplo, debe crear el siguiente archivo de traducción:

# translations/messages.en.yaml  
 
Hola: Hello 

Si abre esta página con el locale en en la URL, verá «Hello» en la pantalla.

Si no es así, intente borrar la memoria caché.

El archivo utiliza el dominio messages (y, por lo tanto, el archivo messages.en.yaml) porque es el dominio predeterminado. A continuación, le indicamos cómo usar otro durante la traducción:

$translator->trans('Hola', array(), 'el_dominio'); 

Aquí, se tendrá en cuenta el dominio el_dominio. Ahora veremos el papel de la tabla vacía que se pasa como segundo parámetro.

2. Marcadores de sustitución (placeholders)

Los parámetros de sustitución permiten crear mensajes dinámicos. Son similares a los parámetros de sustitución de las rutas.

Supongamos...