Localisation des messages d'erreur

Nous utilisons la méthode req.error() de l'API de message à la fois dans la classe d'implémentation pour AdminService de notre scénario et dans la classe d'implémentation pour notre service de catalogue. Cette méthode permet d'éditer des messages d'erreur en cas d'échec des validations. Jusqu'à présent, nous avons codé en dur les messages signalés sous forme de littéraux textuels.

Dans cette leçon, nous allons apprendre à internationaliser les messages. Au lieu de les incorporer codés en dur, ils sont gérés dans des fichiers distincts - appelés paquets de textes - en tant que paires clé-valeur. Les clés sont ensuite utilisées par le code d'application pour accéder aux textes correspondants. Cela signifie que les valeurs pour les clés sont les textes propres à la langue réelle. Afin de prendre en charge différentes langues, différents fichiers sont gérés et fournissent des textes traduits pour les mêmes clés (voir la figure suivante). 

La procédure détaillée est la suivante : Créez un fichier avec le nom messages.properties dans un dossier nommé _i18n, i18n ou assets/i18n. Le dossier du fichier messages.properties doit être situé directement sous le répertoire du projet ou dans un répertoire contenant les fichiers utilisés pour définir les modèles de service (comme le répertoire srv dans notre projet).

Les textes requis sont gérés comme couples clé-valeur dans le fichier messages.properties. En règle générale, les textes y sont gérés en anglais. Des caractères génériques peuvent être utilisés, qui sont notés sous la forme "{n}". n parcourt les nombres naturels en commençant par 0.

Pour prendre en charge des langues supplémentaires, des fichiers supplémentaires sont créés dans le même dossier que le fichier messages.properties selon la convention d'appellation suivante : messages<_languageCode><_countryCode>.properties. Le code pays est facultatif. Exemples de noms de fichiers : messages_de.properties, messages_fr_CA.properties ou messages_es_MX.properties.

Les fichiers supplémentaires utilisent les mêmes clés que le fichier messages.properties. Cependant, les valeurs des clés sont traduites en fonction du code langue et, le cas échéant, du code pays du nom de fichier.

Dans l'exemple présenté, deux fichiers .properties ont été créés : messages.properties avec des textes anglais et messages_de.properties avec les traductions allemandes correspondantes.

Supposons qu'un texte soit interrogé via une clé lors du traitement d'une demande, l'allemand étant déterminé pour la langue. Si un texte est géré pour la clé dans le fichier messages_de.properties, ce texte est utilisé par l'application. Cependant, s'il n'y a pas de fichier messages_de.properties ou si la clé utilisée n'est pas gérée dans le fichier messages_de.properties existant, CAP revient au fichier messages.properties et tente de déterminer une valeur pour la clé via ce fichier. Si cela est possible, le texte correspondant est utilisé par l'application. Si messages.properties ne contient pas non plus d'entrée correspondante, l'application utilise le nom de clé comme texte.

Les textes gérés dans les paquets de textes sont accessibles via l'API de message, par exemple via les méthodes req.error() ou req.warn(). Pour ce faire, la clé correspondante est simplement transmise à ces méthodes au lieu du message réel (voir figure suivante).

Facultativement, un tableau avec des valeurs d'espace réservé peut être transmis aux méthodes à partir de l'API de message comme dernier paramètre. La première valeur du tableau est ensuite utilisée pour le caractère générique {0}, la deuxième valeur du tableau pour le caractère générique {1} , etc.

Vous pouvez utiliser le paramètre URL sap-locale pour tester différentes langues. Dans l'exemple suivant, les textes allemands sont demandés :

1234567
POST <service_url>/submitOrder?sap-locale=de
Content-Type: application/json

{
  "book": "0ec991dc-95c5-4d8f-91e6-f81a92744781",
  "quantity": 0
}

Vous pouvez également utiliser des demandes avec un en-tête Accept-Language approprié :

12345678
POST <service_url>/submitOrder
Accept-Language: de
Content-Type: application/json

{
  "book": "0ec991dc-95c5-4d8f-91e6-f81a92744781",
  "quantity": 0
}

Le paramètre URL sap-locale a la préférence la plus élevée. Il remplace l'en-tête Accept-Language s'il doit également être défini.

Regardez la vidéo pour voir comment utiliser les messages d'erreur localisés.