Salut,
Nous sommes en train de réfléchir à une solution pour permettre d'indiquer ces
indications d'une manière ou d'une autre. Le problème étant d'un côté pour les
dev mais surtout pour les traducteurs qui n'ont actuellement aucune information
sur la forme du texte. Les singuliers et pluriels pouvant en plus être
différents suivant les langues....
Les pistes actuelles et commentaires :
- modification de l'application de traduction pour permettre la récupération
d'un commentaire de fin de ligne. // plural par exemple
C'est la piste la plus légère pour les traducteurs.
- passer en lang[module][plural][12] va être compliqué car demandant trop de
modifications sur l'appli de trad. Par contre faire un module singular et un
plural est envisageable mais va obliger une retraduction complète de ces
modules.
++
Julien
----- Reply message -----
De : "Damien Touraine" <damien.toura...@limsi.fr>
Pour : "GLPI" <glpi-dev@gna.org>
Objet : [Glpi-dev] Proposition de clarification des noms de classes
Date : mer., août 17, 2011 08:56
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
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
