Laravel 11

Cours Laravel 11 – la localisation

Lorsque vous développez un site web, il est courant de vouloir le rendre accessible à un public international. Cela implique l’internationalisation (i18n) et la localisation (L10n). L’internationalisation consiste à préparer une application pour qu’elle puisse être adaptée à différents langages et régions, tandis que la localisation vise à ajouter des composants spécifiques à une langue ou un pays.

Ces sujets sont relativement complexes, car ils ne se limitent pas à la simple traduction des textes, mais ont également un impact sur la représentation des dates, la gestion des pluriels, parfois même sur la mise en page et d’autres aspects culturels spécifiques.

Laravel, en tant que framework PHP populaire, offre diverses fonctionnalités pour gérer l’internationalisation et la localisation. Dans ce chapitre, nous allons explorer les outils et les méthodes que Laravel met à votre disposition pour créer des applications web multilingues et adaptées à différents marchés. Nous aborderons des exemples pratiques et des recommandations pour vous aider à implémenter ces concepts dans vos propres projets Laravel.

Pour les curieux i18n parce qu’il y a 18 lettres entre le « i » et le « n » d’internationalisation et L10n parce qu’il y a 10 lettres entre le « L » et le « n » de Localisation.

Le principe

Les fichiers de langage

On a deux façons de gérer les langues.

Clés et valeurs

On a déjà parlé des fichiers de langage. Lorsque Laravel est installé, il n’y a aucune information concernant le langage dans l’application. Mais on peut utiliser cette commande d’artisan pour les publier :

php artisan lang:publish

On a cette architecture :

Il n’est prévu au départ que la langue anglaise (en) avec 4 fichiers. Pour ajouter une langue, il suffit de créer un nouveau dossier, par exemple fr pour le Français.

Il faut évidemment avoir le même contenu comme nous allons le voir.

Vous n’allez pas être obligé de faire toute cette traduction vous-même ! Certains s’en sont déjà chargés avec ce package. Nous l’avons déjà utilisé dans ce cours. 

On va ajouter la traduction française. Déjà dans le fichier .env :

APP_LOCALE=fr

Puis avec Artisan :

composer require laravel-lang/common --dev
php artisan lang:update

Le français a été ajouté et on a gagné des fichiers au passage.

Les fichiers présents sont constitués de la même manière. Prenons le plus léger : pagination.php, pour l’anglais, on a :

return [
    'previous' => '« Previous',
    'next' => 'Next »',
];

On voit qu’on se contente de renvoyer un tableau avec des clés et des valeurs. On ne peut pas faire plus simple ! Si on prend le même fichier en version française :

return [
    'previous' => '« Précédent',
    'next'     => 'Suivant »',
];

On retrouve bien sûr les mêmes clés avec des valeurs adaptées au langage.

Les textes

Le système clé/valeur peut devenir rapidement lourd et confus lorsqu’on a beaucoup de textes à traduire. Laravel propose une autre approche qui consiste à utiliser la traduction par défaut comme clé.

Si la langue par défaut est l’anglais par exemple, on aura le texte anglais directement dans le code. Les autres traductions se trouveront dans des fichiers JSON.

Par exemple, pour le français, on a le fichier fr.json :

Ce fichier contient des éléments de ce type :

"Browse": "Parcourir",

On a :

  • Browse : le texte en langage par défaut présent dans le code
  • Parcourir : la traduction en français

Les deux systèmes peuvent cohabiter et se compléter.

Configuration de la locale

La configuration de la locale est effectuée, comme on l’a vu, dans le fichier .env :

APP_LOCALE=fr

On peut changer cette locale en cours d’exécution si nécessaire :

use Illuminate\Support\Facades\App;

App::setLocale('fr');

Si une traduction n’est pas trouvée dans la locale actuelle, alors on va chercher la traduction de la locale par défaut définie également dans le fichier .env :

APP_FALLBACK_LOCALE=en

On peut connaître la locale actuelle :

use Illuminate\Support\Facades\App;
 
$locale = App::currentLocale();

Et même tester si on a une certaine locale :

if (App::isLocale('fr')) {
    //
}

Dans le code

L’helper __

Concrètement, au niveau du code, on utilise l’helper __. Il suffit de préciser la clé comme paramètre (la clé pour le système clé-valeur et le texte dans la langue d’origine pour le second système). Prenons un exemple :

$info = __('Posts for category: ');

Si la locale est en c’est ce texte qui sera directement affiché. Si la locale est fr c’est le texte correspondant qu’on trouve dans le fichier fr.json qui sera affiché :

"Posts for category: ": "Articles pour la catégorie : ",

Blade

On peut utiliser l’helper __ dans une vue Blade :

{{ __('Get In Touch With Us') }}

Mais il est plus pratique d’utiliser la directive @lang :

@lang('Get In Touch With Us')

Le pluriel

La gestion du pluriel n’est pas toujours facile. On peut prévoir le texte du singulier et celui du pluriel séparés par le caractère | :

'pommes' => 'une pomme|plusieurs pommes',

On peut affiner :

'pommes' => '{0} aucune pomme|[1,10] quelques pommes|[10,*] beaucoup de pommes',

On utilise dans le code la fonction trans_choice. Voici un exemple tiré d’une application :

{{ trans_choice(__('comment|comments'), $post->valid_comments_count) }}

Selon la valeur de $post->valid_comments_count, autrement dit le nombre de commentaires valides, on prend le singulier ou le pluriel grâce à trans_choice et dans la langue voulue grâce à l’helper __.

Si on a un seul commentaire, on a le singulier :

Sinon on a le pluriel :

Des assistants

Pour gérer toutes ces traductions, il existe des assistants bien utiles.

Pour le système clé-valeur voici un package intéressant :

Il copie les fichiers de langue dans la base de données et permet une gestion à partir d’une interface web.

Pour la gestion des fichiers JSON j’ai aussi créé un package :

Il ajoute 4 commandes à Artisan :

  • language:strings pour visualiser tous les textes du code (dans app et resource/views)
  • language:make pour créer un fichier JSON pour une locale complétée avec les textes du code
  • language:diff pour voir les différences entre une locale JSON et les textes du code
  • language:sync pour synchroniser une locale JSON avec les textes du code

Les noms pour la validation

Il y a un autre élément à prendre en compte pour la traduction : le nom des contrôles de saisie. Ces noms ne sont pas visibles tant qu’il n’y a pas de souci de validation, ils sont alors transmis dans le texte de l’erreur.

‌On voit mal présenter en langue française « Le champ name est obligatoire… ». Alors comment faire ?

Si vous regardez dans le fichier resources/lang/fr/validation.php vous trouvez ce tableau :

'attributes'           => [
    'address'               => 'adresse',
    'age'                   => 'âge'

Ici, on fait correspondre le nom d’un attribut avec sa version linguistique pour justement avoir quelque chose de cohérent au niveau du message d’erreur.

Les dates

Il ne vous a sans doute pas échappé que les dates et les heures ne sont pas présentées de la même manière selon la langue utilisée. En particulier entre le français et l’anglais.

En France nous utilisons le format jj/mm/aaaa alors que les Américains utilisent le format mm/jj/aaaa. De la même façon les heures sont présentées différemment.

Laravel utilise Carbon pour la gestion des dates. Carbon hérite de la classe PHP DateTime. On dispose donc de toutes les possibilités de cette classe, plus toutes celles ajoutées par Carbon, et elles sont nombreuses. Le vous conseille vivement la lecture de la documentation.

Quand Eloquent récupère une date de created_at ou updated_at il la transforme automatiquement en instance Carbon. On peut modifier ce comportement, mais je n’en vois pas l’intérêt sauf cas bien particulier.

Partez d’une nouvelle installation de Laravel et allez dans le fichier AppServiceProvider pour ajouter ce code :

public function boot(): void
{
    setlocale(LC_TIME, config('app.locale'));

    ...
}

La méthode setLocale fait appel à la fonction PHP strftime. C’est ainsi qu’on a la date et l’heure bien affichées pour l’anglais et le français.

Dans la vue welcome.blade.php entrez ce code :

Date : {{ \Carbon\Carbon::now()->isoFormat('LL') }}

En anglais, vous affichez :

Date : October 1, 2020

Et en français :

Date : 1 octobre 2020

Dans la vue welcome.blade.php entrez maintenant ce code :

Date : {{ \Carbon\Carbon::now()->calendar() }}

En anglais, vous affichez :

Date : Today at 12:27 PM

Et en français :

Date : Aujourd’hui à 12:27

Le but de ce chapitre est de montrer comment localiser l’interface d’une page web. S’il s’agit d’adapter le contenu selon la langue, c’est une autre histoire et il faut alors intervenir au niveau de l’url. En effet, un principe fondamental du web veut que pour une certaine url on renvoie toujours le même contenu.

En résumé

  • Laravel possède les outils de base pour la localisation.
  • Laravel propose deux systèmes complémentaires : clé-valeur ou texte dans le code associé à des fichiers JSON.
  • Il faut créer autant de fichiers de localisation qu’on a de langues à traiter.
  • Il faut prévoir la version linguistique des attributs.
  • Grâce à Carbon la présentation des dates est heures selon la locale est simplifiée.
Print Friendly, PDF & Email

Laisser un commentaire