Bonjour,
avec le changement sur le getTypeName (passage du nombre d'élément en
argument de la méthode), on peut désormais changer le nombre
(singulier/pluriel) du nom du type. Cela est parfaitement logique au
regard de l'évolution des noms d'onglets (ie : appel à getTypeName pour
les noms des onglets).
Mais je me pose la question si nous ne devrions pas être beaucoup plus
explicite dans le fichier de langage (fr_FR.php) en ajoutant, par
exemple : $LANG['typeName'][$type]['singular'] et
$LANG['typeName'][$type]['plural'] avec $type correspond au type de la
classe.
Je prends en exemple la classe Ticket (choisie au hasard parmis celles
qui utilisent le passage du nombre à getTypeName) :
D'une part, nous utilisons, au moins, trois $LANG différents : deux dans
getTypeName et un troisième dans getTabNameForItem. Je suppose que le
changement de "return self::createTabEntry($LANG['title'][28], $nb);" à
"return self::createTabEntry(self::getTypeName($nb), $nb);"
(inc/ticket.class.php, ligne 384) est un travail en court.
Ma proposition est la suivante ajout dans le fichier locales/fr_FR.php de :
$LANG['typeName']['Ticket']['singular'] = "Ticket";
$LANG['typeName']['Ticket']['plural'] = "Tickets";
Cela éviterait les confusions et regrouperait les noms associés à un
type : j'ai compté jusqu'à 4 "Ticket" différents dans fr_FR.php (lignes:
976, 1367, 2434, 2457).
De la même manière, nous aurions :
$LANG['typeName']['Computer']['singular'] = "Ordinateur";
$LANG['typeName']['Computer']['plural'] = "Ordinateurs";
...
A termes, nous pourrions, même, définir une méthode getNameOfType (en
replacement de getTypeName) indépendante de toute classe (qui reposerait
uniquement sur le fichier de traduction). Par exemple :
class CommonGLPI {
...
static function getNameOfType($type, $nb) {
global $LANG;
if (isset($LANG['typeName'][$type])) {
if ($nb > 1)
return $LANG['typeName'][$type]['plural'];
else
return $LANG['typeName'][$type]['singular'];
}
return 'N/A';
}
...
}
Nous n'aurions, alors, pas à charger le fichier d'une classe pour en
connaitre son nom. Cette séparation de la gestion du nom par rapport à
la classe permettrait d'utiliser un nom de classe plutôt qu'un label.
Par exemple, au lieu d'utiliser $LANG['common'][15] dans les formulaires
de saisies, nous mettrions CommonGLPI::getNameOfType("Location", 1) ou
CommonGLPI::getNameOfType("Location", 2) selon le cas souhaité. Nous
n'aurions plus à nous soucier des indices.
Je poses la question car je me suis rendu compte que ce serait plus
simple de fonctionner comme cela avec les classes sur lesquelles je
travaille (NetworkAddress, IPAddress, IPNetwork, InternetDomain,
NetworkAlias, ...).
Cela ne fait pas partie de la roadmap. Mais ce n'est pas si lourd que
cela à mettre en oeuvre. Surtout si on le fait petit à petit. En tout
cas, si cela est validé maintenant, au lieu d'adapter le fichier de
chaque classe pour mettre à jour son getTypeName en y ajoutant le
passage du nombre d'items en paramètre (et devoir y revenir plus tard
dans le cas où nous souhaiterions complexifier getTypeName), nous
n'aurions qu'à modifier le fichier de langue et supprimer cette méthode
de la classe (sans oublier de modifier la méthode getTypeName de
CommonGLPI pour faire appel à getNameOfType).
Si vous le souhaitez, je peux vous soumettre un patch modifiant
CommonGLPI en ce sens.
Cordialement
Damien
--
--------------------------------------------------------------------
Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/)
Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64
--------------------------------------------------------------------
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
