Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjour,
j'utilise depuis peu Zend_Locale, et j'aurai besoin de recuperer la locale en cours de l'utilisateurs, le probleme, si je fais :
$locale = new Zend_Locale(); echo (string) $locale;
;
Ca m'affiche "fr", hors j'aurai besoin que ca m'affiche "fr_FR", bien sur je peux refaire un traitement derriere, mais existe t il une methode deja faite ?
Merci
Hors ligne
salut
echo $locale->toString();
Hors ligne
Bonjour,
même avec ta méthode ubini ca ne fonctionne pas ( en fait, quand tu fais (string) $object, ca apelle la methode __tostring() )
Sinon j'ai bricolé un petit truc avec Zend_Locale::getBrowser() , ne trouvant rien dans la doc.
Mais merci
Hors ligne
echo $locale->getLocale();
Hors ligne
En fait, les 3 codes sont strictement équivalents :
echo $locale->getLocale(); echo $locale->toString(); echo (string) $locale;
Le problème vient de ton browser (ou ta console) qui envoie seulement 'fr' au lieu de 'fr_FR'. Verifies tes entêtes de requête.
Edit: 'fr-fr', 'fr-FR', 'fr_fr' et 'fr_FR' sont acceptés par Zend_Locale
@+
Hors ligne
Oui en effet ca doit etre mon browser ( Mozilla Firefox for Ubuntu 3.5.8 ) , toujours est il que si le mien fais ca, d'autres doivent le faire aussi
En tout cas j'ai pu récupérer comme dis plus haut toutes les locales envoyées, et récupérer dans la liste la première qui a une longueur de 5.
Hors ligne
mikaelkael a écrit:
En fait, les 3 codes sont strictement équivalents :
Code:
echo $locale->getLocale(); echo $locale->toString(); echo (string) $locale;Le problème vient de ton browser (ou ta console) qui envoie seulement 'fr' au lieu de 'fr_FR'. Verifies tes entêtes de requête.
Edit: 'fr-fr', 'fr-FR', 'fr_fr' et 'fr_FR' sont acceptés par Zend_Locale
@+
bon cela fait partit du protocole
normalement le client fournit un liste de langues préférées
fr_FR, fr_CA, fr, en_EN, en
la signification est :
je préfère dans l'ordre le français france, français canada, français, anglais royaume uni, anglais
le troisième et le dernier dans ma liste disent français ou anglais (peu importe le pays)
le client n'est pas tenu de fournir une langue cette liste peut donc être vide.
côté serveur maintenant. le serveur doit lui aussi maintenir une liste de langues préférées.
de la même façon
en_us, en_en, fr_be
la langue servit suit la règles des préférence au premier correspondant en parcourant les deux listes en commençant par celle du client.
dans notre exemple
fr_FR => non (pas dans la liste des langues du serveur) fr_CA => non (pas dans la liste des langues du serveur) fr => oui (fr_be est bien dans le scope de fr)
reprenons mais sans fr dans la liste client
fr_FR, fr_CA, en_EN, en
fr_FR => non (pas dans la liste des langues du serveur) fr_CA => non (pas dans la liste des langues du serveur) en_EN => oui (en_en est bien dans la liste des langues du serveur)
autre cas le client ne précise pas fr en général
fr_FR, fr_CA, en_AU
mais le serveur le fait
en_us, en_en, fr_be, fr
on parcours la liste serveur
fr_FR => non (pas dans la liste des langues du serveur) fr_CA => non (pas dans la liste des langues du serveur) fr_AU => non (pas dans la liste des langues du serveur) fr_en => non (pas dans la liste des langues du client) fr_us => non (pas dans la liste des langues du client) fr_be => non (pas dans la liste des langues du client) fr => oui (fr_FR est bien dans le scope de fr)
dernier cas le client est très restrictif (ou n'a pas fournit de liste)
fr_FR, fr_CA
fr_FR => non (pas dans la liste des langues du serveur) fr_CA => non (pas dans la liste des langues du serveur) en_us => oui (langue préférée du serveur car aucune langue du client ne peut être satisfaite)
le protocole du choix de la langue n'est pas sensible à la casse.
j'ai délibérément dans mon exemple mis les pays en majuscule côté client et minuscule côté serveur pour montrer que le choix est fait dans la liste du client ou celle du serveur.
Apache utilise une manière intéressante de gérer ce choix.
il se base sur le multiview. cela consiste à avoir plusieurs "views" d'une même ressource.
il définit un liste de langues préférées globale au serveur (peux être surcharger dans .htaccess) chaque page à servir va exister en plusieurs exemplaires
maRessource.html.fr_fr, maRessource.html.fr_ca, maRessource.html.en
lorsque le client va demander maRessource.html il va utiliser l'algo ci-dessus mais en plus au passage vérifier que la ressource correspondante existe.
Ce qui revient pour chaque ressource à établir une liste des langues préférées basé sur la principale et restreinte au langues disponibles.
Avec ZF on peut par exemple définir une liste de langues préférées dans le config.ini général pour s'y référer dans le choix de la langue, et si seulement certaine partie du site existe en plusieurs langue associer toujours dans le .ini ou en base ou dans le code une liste de langue disponible par contrôleur, par module, par action.
peut être devrions nous réfléchir à un composant générique prenant en charge 100% de ce protocole
A+JYT
Dernière modification par sekaijin (03-04-2010 11:11:36)
Hors ligne
Hello,
sekaijin a écrit:
peut être devrions nous réfléchir à un composant générique prenant en charge 100% de ce protocole
100% d'accord
L'idéal serait de définir soit un plugin de ressource, soit un plugin de controlleur + une config apache (rewrite rules) qui prendrait correctement en charge tout ça une bonne fois pour toute. En tenant compte bien sûr des différentes possibilités pour intégrer la langue (sous-domaines, ajout dans l'url pour simuler un dossier par langue, etc.)
Ces questions là sont super récurrentes quelques soient les forums !
A+ benjamin.
Hors ligne