IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

[Tableaux] Gestion des langues [Fait]


Sujet :

Langage PHP

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé Avatar de sourivore
    Homme Profil pro
    Lead Tech Front-End
    Inscrit en
    Juin 2005
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Lead Tech Front-End

    Informations forums :
    Inscription : Juin 2005
    Messages : 451
    Par défaut [Tableaux] Gestion des langues
    Bonjour,

    Je cherche le meilleur moyen pour gérer les changements de langues j'ai beau visualiser toutes les solutions possibles aucun ne me satisfait vraiment.

    Voici les solutions envisagées :
    1) Création d'un fichier XML pour chaque langue et chargement du bon fichier suivant la langue.
    Inconvénients : A chaque page ou dans un fichier optimisé, à chaque changement de langue où à l'ouverture de l'application on est obligé de lancer le parseur sur le fichier XML qui peut être assez volumineux si on veut garder une certaine cohérence hiérarchique. Par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    <document>
     <menuGauche>
      <libMenu1>
       Accueil
      </libMenu1>
     </menuGauche>
     <pageCentrale>
      <bandeau>
       <nomSite>
        MonSite
       </nomSite>
      <bandeau>
     </pageCentrale>
    </document>
    Tout ceci pour seulement 2 libellés à moins de casser toutes la structure mais dans ce cas je ne vois pas l'avantage du XML. L'avantage est bien sûr que tout un chacun comprenne le fichier et puisse modifier correctement les libellés sans avoir accès au code.

    2) Création d'un fichier PHP de variables globales pour chaques langue et include du bon fichier suivant la langue.
    Inconvénients :
    - La structure n'apparait pas. Il n'est donc pas simple de savoir quel variable correspond à quel libellé à moins de se tapper tout le code ou d'être un dieu du nommage de variable
    - Les différentes solutions que ce soient des variables standard ou des tableaux associatifs ou même dans un cas extrême des classes, nécessite de donner un identifiant pour chaque libellé, ce qui peut s'avérer énorme et compliqué à déterminer même en tant que dieu du nommage (par ex "libBtConnexionMenuGauche")

    3) On multiplie chaque page par autant de langues.
    Inconvénients : Nombreux = Redondance des modifications de structures, nombre de fichiers énormes...

    4) Se créer une interface d'admin en PHP d'administration des langues avec construction d'un fichier PHP ou XML ou TXT (peu importe) mais en background donc invisible à l'utilisateur
    Inconvénients : Difficile de trouver une interface simple d'utilisation qui permet de savoir quel libellé on est en train de paramétrer

    Merci de vos solutions ou de m'indiquer les techniques que vous utilisez pour de telles problèmes.

  2. #2
    Membre éclairé Avatar de daajack
    Inscrit en
    Octobre 2007
    Messages
    97
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 97
    Par défaut
    En ce qui concerne la traduction d'interface, j'ai pu voir plusieurs systèmes différents.

    Accès

    La première question à se poser, je pense, c'est de savoir comment on va accéder au variables traduites. Déjà là on a plusieurs possibilités :

    • Une variable : $Menu1
    • Un tableau : $traduction['menu1']
    • Une classe : Traduction::get('menu1')
    • un objet : $traduction->get('menu1')
    • une fonction : traduction('menu1')


    Les variables, personnellement je n'aime pas trop, ça dégueulasse le code et il y a un risque de conflit avec d'autres variables du code. Mais on peut mettre les variables de traduction avec une majuscule au début p.ex.

    J'ai utilisé le nom 'traduction', mais on peut utiliser p.ex. une fonction qu'on appellera __() (2 underscores) ce qui simplifie l'appel et permet de reconnaître facilement les traductions dans le code. (c.f. Symfony)
    Un autre avantage d'une fonction ou d'un objet est qu'on peut marquer les termes qui n'ont pas été traduits dans la langue en cours sans que ça provoque une erreur.

    Références

    La deuxième question qu'on peut se poser c'est la manière donc sont stocké les variables,
    • par abbréviation,
    • sans abbréviation (complète quoi), ou
    • par id.

    Cette dernière solution est à mon avis à proscrire pour des raison évidentes de clareté.

    Les abbréviations sont pratiques pour les longues chaînes, mais on ne retient pas toujours à quelle abbréviation correspondent quels termes.
    Les chaîne complètes ne sont pas vraiment pratiques quand il s'agit de longs texte, mais on sait exactement ce qu'on doit noter pour l'obtenir, et le code est plus facile à lire puisque l'on voit exactement le résultat dans le code.

    Le stockage

    • XML
    • BDD


    Au niveau XML il existe une norme, que je trouve personnellement très peu pratique, appellé XLIFF. Où chaque fichier XML correspond à une traduction, les termes dans la langue de référence devant être copié dans chaque fichier. Ce qui pose problème quand il faut faire des modifs.
    Bien sûr le XML est peu pratique à modifier au bloc-note, mais il existe des apps open-source et on peut facilement créer un interface soi-même.

    Quand à la dernière solutions évidemment, c'est la BDD avec une ligne par terme et une colonne par langue. Le terme de référence pouvant être une colonne supplémentaire (abbrév.) ou l'une des langues existantes.

    Voilà, petite synthèse pour un sujet qui m'a posé pas mal de problèmes (et qui m'en pose encore), et qui mériterait d'être plus largement développer (c.f. internationalisation, localisation et formats de nombre et de date).

  3. #3
    Membre éclairé Avatar de sourivore
    Homme Profil pro
    Lead Tech Front-End
    Inscrit en
    Juin 2005
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Lead Tech Front-End

    Informations forums :
    Inscription : Juin 2005
    Messages : 451
    Par défaut
    Jolie réponse qui répond quasiment à toutes mes questions ^^
    Il m'en reste toutefois quelques-unes.

    Notamment, une fois la traduction stockée, à quel moment parse-ton le fichier XML ou lit-on dans la BDD.

    Je veux dire par là que se tapper tout le fichier à chaque page pour mettre les valeurs dans des variables ou dans des tableaux... (cf. ton premier point), ça risque d'alourdir le fichier.

    Il faudrait donc initialiser toutes les variables dans des variables de session dès la première page et là ça risque d'être assez long vu le nombre de libellés dans une application fusse-t-elle moyenne.

    Sinon il faut charger les bonnes variables plutôt que toutes à chaque page mais :
    - En BDD, il faut lancer une requête sur une table qui contient beaucoup de données
    - En XML, même si on ne stocke pas toutes les variables on se retrouve quand même souvent à parser tout le fichier...
    Tout ça pour dire qu'à chaque page ça risque d'être long (J'espère que vous avez suivi jusque là ^^)

    2e point :
    Avez-vous des conventions de nommage intelligentes pour identifier ces libellés? Par exemple pour le libellé de la 3e question d'un formulaire sur la page Quizz : libQuestion3Quizz (je ne sais pas si c'est intelligent comme nommage et c'est justement ce que je cherche ^^)
    D'ailleurs le nommage de variable est un point qui a toujours posé problème a toute une communauté de développeur aguerris

    En tout cas merci de la dernière réponse ça va vraiment me servir

  4. #4
    Membre éclairé Avatar de daajack
    Inscrit en
    Octobre 2007
    Messages
    97
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 97
    Par défaut
    à quel moment parse-ton le fichier XML ou lit-on dans la BDD
    Effectivement un parsage n'est pas réputé pour être économe en ressource, dans ce cas le faire une fois pour toute au lancement de l'application serait une solution. Avec une barre de chargement si vraiment. Même chose pour la BDD, quoique là on pourrait envisager de le refaire à chaque chargement de script, c pas Bysance, mais à moins de faire un portail à 100'000 accès par jour, ça devrait être gérable pour le serveur.

    Sinon comme tu dis, le plus propre et peut-être aussi le plus lourd à mettre en place, c'est de classer les traductions par catégories et de ne charger que les catégories qui t'intéressent. Plus sympa pour le serveur, mais plus difficile à gérer car il faut vérifier de mettre les variables dans les bonne catégories, une catégorie global serait pratique dans ce cas.

    Et dernière solution, pour les BDD, la plus mauvaise, c'est une requête par terme traduit, qui à mon avis ne mérite pas plus de réflexion que ça.

    Personnellement j'ai une préférence pour la BDD, qui est plus efficace et plus aisée à mettre en place.

    Pour le nommage des variables, c'est toujours un problème. Le mieux est d'avoir une vision globale du projet pour pouvoir définir les différents niveaux de contexte qu'on rencontrera. Il faut imaginer les variables dans une hiérarchie, dont le premier niveau serait les catégories citées plus haut. A l'intérieur de ces catégories il n'est pas nécessaire d'utiliser de terme qui indique la catégorie dans laquelle elle se trouve. P.ex avoir un objet voiture, nous permet d'avoir des sous-objets roues, carrosserie ou vitre et non pas voiture_roues, voiture_carrosserie etc... ensuite pour décrire les roues, l'idéal serait d'avoir un objet roues dans lequel on mettrait avant_gauche, avant_droite, etc.... mais si les variables co-existent dans un même contexte alors on aura roue_avant_droite, roue_avant_gauche, etc... Je sais pas si c clair...

    Dans ton exemple, il ne serait pas nécessaire de mettre quizz dans le nom de la variable si il n'y a que le quizz qui est traduit, ou si il se trouve dans une catégorie. Nous aurions donc lib en admettant qu'il y est les question et les réponse, puis 3. Le terme question est inutile dans ce cas puisqu'il y a déjà libellé et quizz. Donc quizz['lib1'], quizz['lib2'], quizz['lib3'] et quizz['rep1'], quizz['rep2'], quizz['rep3'].

    Pour terminer un petit exemple illustré :
    Quizz
    L Question
    L 1 -> QuizzQuestion1
    L 2 -> QuizzQuestion2
    L ..
    L Réponse
    L 1 -> QuizzRéponse1
    L ..
    L Interface
    L Intro ->QuizzIntro ou QuizzInterfaceIntro
    L Conclusion -> QuizzConclusion ou QuizzInterfaceConclusion
    Interface
    L Menus
    L Menu1 -> InterfaceMenusMenu1
    L Autres
    L ..
    + un petit lien pour la route : Internationalisation (i18n) en PHP avec XML

  5. #5
    Membre éclairé Avatar de sourivore
    Homme Profil pro
    Lead Tech Front-End
    Inscrit en
    Juin 2005
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Lead Tech Front-End

    Informations forums :
    Inscription : Juin 2005
    Messages : 451
    Par défaut
    Merci beaucoup pour toutes ces réponses et pour le lien (même si je pense que je vais suivre ton conseil et utiliser une BDD)
    Il est vrai que le nommage de variable est un problème récurrent pour tout informaticien.
    D'ailleurs je ne pense pas que quiconque a déjà eu l'idée de créer une norme universel pour le nommage des variables ce qui traiterait serait un pur sujet de linguistique. Dommage.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Problème de gestion des langues avec MFC
    Par Figaro dans le forum Visual C++
    Réponses: 4
    Dernier message: 20/11/2006, 15h56
  2. API gestion des langues
    Par sroux dans le forum API standards et tierces
    Réponses: 4
    Dernier message: 03/10/2006, 22h32
  3. [C#] Gestion des langues d'une application
    Par therock dans le forum Windows Forms
    Réponses: 4
    Dernier message: 15/05/2006, 08h47
  4. [Tableaux] gestion des connexions
    Par zahiton dans le forum Langage
    Réponses: 3
    Dernier message: 02/11/2005, 14h37
  5. [Plugin]Eclipse et la gestion des langues
    Par Gougou dans le forum Eclipse Java
    Réponses: 2
    Dernier message: 26/07/2005, 12h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo