Changer de langue · Localisation

InfraGuard est une console en 8 langues, avec le coréen comme langue par défaut du siège et l’anglais comme langue de repli globale. Cet article explique (1) comment un utilisateur change de langue depuis le sélecteur de l’en-tête, (2) comment la langue d’affichage est résolue à chaque requête et (3) comment un administrateur choisit les langues qui apparaissent dans le sélecteur.

Vue d’ensemble — à quoi cela sert

Chaque libellé, entrée de menu et message de la console passe par une clé de traduction (__('menu.security'), etc.) plutôt que par de l’anglais écrit en dur. Changer de langue amène le serveur à rendre l’interface à partir des fichiers de traduction de cette langue (resources/lang/{locale}/*.php) dès la requête suivante.

Le catalogue des langues prises en charge correspond aux 8 entrées sous admin dans config/locales.php. Chaque langue est toujours affichée par son propre libellé natif, quelle que soit la langue active à ce moment-là.

Au départ, seuls ko et en sont réellement traduits (priority => ['ko','en'] dans config/locales.php). Les six autres (ja·zh·es·fr·de·ru) n’ont pas encore de fichiers de traduction et se replient automatiquement sur en (fallback_locale = en dans config/app.php). Choisir ja aujourd’hui affiche donc encore en anglais les chaînes non traduites : le sélecteur liste bien les 8 langues, seul le texte se replie.

Quand l’utiliser

• Un visiteur souhaite consulter la console dans une langue qu’il maîtrise — utilisez le sélecteur de langue de l’en-tête.
• Vous voulez changer de langue même sur l’écran de connexion (avant qu’une session n’existe) — /lang/{locale} est autorisé aux invités.
• Vous voulez n’exposer que certaines langues à l’échelle de l’organisation et fixer la langue par défaut des premières visites — un administrateur modifie l’ensemble activé et son ordre (voir « Gérer les langues activées » plus bas).

Disposition

Sélecteur de langue de l’en-tête (sur tous les écrans)

Le menu déroulant de langue de l’en-tête (layouts.partials.locale-switch + ui/locale-dd.js) ne liste que les langues activées par l’administrateur. Chaque entrée affiche le libellé natif suivi d’une étiquette courte (par exemple KO, EN), et la langue courante est marquée comme active.

Administration ▸ Localisation (gérer les langues activées)

Sur l’écran Administration ▸ Localisation (accessible depuis le bouton en haut à droite), vous pouvez, pour le catalogue de 8 langues :

• Activer ou désactiver chaque langue (selon qu’elle apparaît ou non dans le sélecteur).
• Réordonner par glisser-déposer — la première langue activée devient la langue principale (par défaut) du site.
• Enregistrer avec un minimum d’une langue imposé (enregistrer zéro langue est refusé).

Utilisation

1) Changer depuis le sélecteur de l’en-tête

1. Ouvrez le menu déroulant de langue dans l’en-tête.
2. Choisissez une langue → le navigateur va vers GET /lang/{locale}.
3. Le serveur enregistre votre choix et vous redirige vers la page précédente (redirect()->back()). La nouvelle langue s’applique dès le rendu suivant.

Le point d’entrée de changement se présente ainsi :

GET /lang/ko      # passer au coréen
GET /lang/en      # passer à l’anglais
GET /lang/ja      # japonais (non traduit → repli sur en)

Ce que fait le serveur (LocaleController@switch) lors du changement :

Lorsqu’un utilisateur connecté change de langue, le choix est aussi enregistré dans users.lang (langue du profil), si bien que la langue est conservée à la prochaine connexion. Les choix des invités (non connectés) ne sont conservés qu’en session et en cookie.

Appeler /lang/{locale} avec un code non pris en charge (ou désactivé par l’administrateur) est ignoré silencieusement et la langue courante est conservée — aucune erreur n’est levée.

2) Comment la langue d’affichage est résolue (SetLocale)

Le middleware SetLocale détermine la langue à chaque requête web (écran de connexion compris) selon la priorité ci-dessous. Chaque candidat n’est retenu que s’il s’agit d’une langue actuellement activée.

1. session infr_locale   (choisie explicitement via le sélecteur dans cette session)
2. cookie  infr_locale   (choix persistant d’une visite à l’autre · s’applique à l’écran de connexion, avant la session)
3. session infr_lang     (profil de l’utilisateur connecté users.lang → chargé en session à la connexion)
4. défaut du site        (Locales::primary() = première langue de la liste activée)

Aucune détection automatique via l’en-tête Accept-Language du navigateur n’est effectuée. Une première visite sans session, sans cookie ni choix de profil est servie de façon déterministe dans la langue par défaut du site définie par l’administrateur, et non dans celle du navigateur (le réglage global du site fait autorité). Les visiteurs peuvent toujours en changer avec le sélecteur de l’en-tête.

3) Gérer les langues activées (administrateur)

1. Allez dans Administration ▸ Localisation.
2. Activez les langues à exposer (le sélecteur, le changement de langue, la langue du profil et l’édition multilingue de l’inventaire passent tous par cet ensemble), et désactivez les autres.
3. Réordonnez par glisser-déposer — la première langue activée devient la langue par défaut.
4. Enregistrez. L’enregistrement est audité dans infr_audit_log sous localization.save.

Réduire les langues activées restreint immédiatement l’offre du sélecteur de l’en-tête. Par sécurité, au moins une langue doit rester activée (enregistrer zéro langue renvoie 422) et, s’il ne reste aucun code valide, le système se replie sur le catalogue complet afin qu’au moins une soit toujours garantie.

Sources de données

Les réglages des langues activées et de l’ordre sont lus par App\Support\Locales avec un cache de 60 secondes. En cas d’erreur de base de données ou d’absence de réglage, il se replie sans risque sur un tableau vide (→ catalogue complet). Après un enregistrement, Locales::flush() invalide le cache immédiatement.

-- Où sont stockés l’ensemble activé et l’ordre (exemple)
SELECT `group`, `key`, `value` FROM infr_setting WHERE `group` = 'i18n';
-- group | key     | value
-- i18n  | order   | ko,en,ja,zh,es,fr,de,ru
-- i18n  | enabled | ko,en

Transmission au frontend

Le serveur transmet la langue active et le paquet de messages au bootstrap de la vue (par exemple window.__t = @json(__('msg')), window.__locale). Les pages et les mixins Vue s’en servent pour rendre les chaînes côté client et formater les dates selon la langue d’interface active.

Accès

• Changer de langue est ouvert à tous (ce n’est pas une action sensible).
• L’écran d’administration qui décide des langues présentes dans le sélecteur est réservé aux administrateurs : double défense avec le groupe de routes infr.level:10 plus une garde interne au contrôleur (user_level >= 10). Les paliers de niveau sont demo=1 · staff=5 · admin=10 (voir Niveaux · RBAC).

Dépannage et FAQ

La langue que je veux ne figure pas dans le sélecteur

Elle a très probablement été désactivée par un administrateur. Activez son interrupteur dans Administration ▸ Localisation. Le sélecteur, le changement de langue et la langue du profil passent tous par l’ensemble activé.

J’ai changé de langue mais une partie du texte reste en anglais

ja·zh·es·fr·de·ru n’ont pas encore de vrais fichiers de traduction et se replient sur en (stratégie initiale). Voir en anglais uniquement les chaînes non traduites est le comportement attendu. ko et en sont entièrement traduits.

La première visite ne s’ouvre pas dans la langue de mon navigateur

C’est voulu. InfraGuard ne lit pas Accept-Language ; il s’ouvre dans la langue par défaut du site définie par l’administrateur (la première de la liste activée). Une fois que vous changez de langue, le choix est enregistré en session et en cookie, puis conservé lors des visites suivantes.

Après une déconnexion puis une reconnexion, ma langue est réinitialisée

Si le cookie (infr_locale, 1 an) est présent, la langue persiste. Pour les utilisateurs connectés, le choix est aussi enregistré dans users.lang et restauré comme langue de profil à la connexion suivante. Sans cookie ni profil, l’interface s’ouvre dans la langue par défaut du site.

Que se passe-t-il avec un code inconnu comme /lang/xx ?

Un code non pris en charge est ignoré silencieusement et la langue courante est conservée (aucune erreur). Les seuls codes valides sont ceux qui sont activés parmi les 8.

Et si je désactive toutes les langues ?

C’est bloqué. L’enregistrement impose un minimum d’une langue (enregistrer zéro langue renvoie 422). Même si le réglage venait à être corrompu, le système se replie sur le catalogue complet : le sélecteur n’est donc jamais vide.

Voir aussi

• Administration ▸ Localisation (gérer les langues activées)
• Mon profil · langue
• Navigation · structure du menu
• Thème (clair · sombre)
• Niveaux · RBAC
• Utiliser ce manuel