Je ne connais pas bien Gettext, mais peut être qu'il gère mieux ça que nous
Je ne sais pas.

Pour l'instant, je me suis penché sur la localisation. Et j'ai un soucis . On reviendra sur vos remarques après (merci).

On sait qu'on doit présenter ça sous la forme xx_XX, par exemple : fr_BE. Unix, BSD, et Mac accepte très bien cette notation (iso-3166-1_alpha-2), mais qui se démarque une fois de plus ? Notre cher et tendre ami Windows ! Il utilise donc son propre encodage (iso-3166-1_alpha-3) ... je commence à en avoir marre de lui.
C'est à dire, qu'on ne définit plus les régions/pays et langues par 2, mais 3 lettres. Donc toutes les normes que le W3C, Unicode font et que le monde entier utilise ne fonctionnent pas sous Windows. Comment résoudre ce problème ?
A l'aide de la documentation d'Unicode, j'ai réussi à parser un fichier XML (lien dans un de mes messages précédents), et à récupérer les listes complètes. J'ai déjà 2 listes : de 7 et 10ko. Je ne vais pas encore faire 2 listes pour Windows (qui seront en gros un peu moins d'un tiers plus grosses).
Alors si quelqu'un à résolu le problème (oui c'est un problème), ce serait sympa de me signaler ça. Pendant ce temps, je vais regarder les sources de symphony et ZF pour voir s'ils ont résolu le problème.

Merci

J'avoue n'en avoir aucune idée, j'ai toujours ignoré la deuxième partie (régionalisation) pour ne prendre que le code langue sur deux lettres

Bon, d'après ce que je comprends rapidement des sources de Zend Framework, tout dépend de l'entrée. Si on est sous Windows, on rentre un encodage valide pour Windows, sinon on utilise l'encodage standard.

Je pense que je vais faire comme ça pour l'instant. Ce qui me dérange, c'est que c'est moins pratique à gérer mais je ne vois pas de solutions :s

Développons d'abord pour les systèmes normaux, on verra les exceptions plus tard (beaucoup plus tard) Je deviens de plus en plus adepte de cette philosophie lol


Edit : J'ai trouvé cette liste de correspondances : http://www.unicode.org/onlinedat/countries.html, toujours sur le site de l'Unicode. Il y a des ressources très intéressantes. Mais cette liste n'existe pas en format XML, on ne peut donc rien en faire :s Je continue mes recherches.

Si windows, stocke les trois premières lettres, n'enregistre que les 3 premières lettres du pays dans ta liste, et tronque à 2 lettres si tu es sur un systèmes UNIX. Et dans le cas où tu as les deux premières lettre de l'identifiant win qui sont différentes de celles de la notation standard, tu ne stoque que les 2 lettres de la notation standard et tant pis pour windows...

Oui, c'est ce que je pensais faire. Mais Windows est encore plus capricieux. Regardez : Donc, j'aimerais avoir un tableau associatif de l'iso 3166-1 alpha-2 à alpha-3. Si j'ai ce tableau, je n'ai qu'à mettre toutes les valeurs : les corrects (alpha-2), l'abrégé Windows 98, et l'abrégé Windows XP et plus (alpha-3). De cette façon, ce sera toujours juste.

Bon, on dirait qu'une solution est en train de se dessiner au loin. Seulement, ce tableau associatif n'existe quand HTML, et je ne peux donc pas l'exploiter dynamiquement (ou très difficilement). J'ai envoyé un mail à Unicode pour savoir s'ils n'ont pas ce tableau en XML. On verra s'ils répondent.

J'ai également regarder du côté de ISO (.gov), mais leur base de données sont payantes pour les versions complètent et intéressantes. Ce qui est gratuit est dans le bon format, mais ce n'est pas complet ou alors pas intéressant. Dommage.

J'attends la réponse de Unicode pour avancer. Je vais regarder regarder la traduction (Gettext) pour l'instant

Suite au prochaine épisode.

Oublie Win 98, tu te donneras du mal pour rien. C'est un système encore répandu chez ceux qui ne sont pas fanas d'informatique, mais qui est obsolète et n'existera plus très longtemps.
Et puis, setlocale, c'est pour les serveurs non ? Pourquoi se faire chier pour des serveurs 9x, ca n'existe pas. Et vérifie au passage que les Windows Server gèrent les locales comme Windows XP, parce que s'ils gèrent comme UNIX (ce qui m'étonnerait puisque ce serait con de faire des gestions différentes des locales sur des systèmes aussi proches), tu te seras fait chié pour rien...

Oui, enfin de toute façon, je vais avoir besoin d'une liste associative alpha-2 vers alpha-3, et je pourrais toujours avoir quelque chose de fonctionnel.

Mal à la tête moi ...

Edit : Bon, on avance J'ai donc commencé le développement sans m'occuper de Windows pour l'instant. Un seul problème subsiste cependant, et je pense qu'au moins une personne sur le forum aurait cette ressource.
On peut définir le local soit en mettant : fr, fr_FR, FR, ou même Europe/Paris. Quand on cherche par continent/ville, je n'ai que la région en retour (FR) et pas la langue (fr). Donc si on fait Europe/Oslo, il me retourne NO, et pas nb (Norwegian Bokmål), nn (Norwegian Nynorsk), ou se* (Northern Sami).
Je pourrais faire une recherche, et retourner un tableau, mais à Oslo, il parle le nb, et pas le nn, ni se (à la relecture, je me rends compte que c'est pas facile à comprendre tout ça haha).
Donc je cherche un tableau qui me dit : ville => langue parlée.

Si quelqu'un à ça Et que c'est exploitable facilement (XML par exemple), ce serait super sympa

Le message précédent, c'est moi. Pourquoi ? Car je voulais poster un nouveau message (2 jours que j'essaye), mais je ne peux me répondre. Et comme je doute qu'une édition envoie une notification, je lance un message en tant qu'invité, pour pouvoir répondre ! (simple ...)

Bon alors, passons aux choses sérieuses ^^

Localisation

J'ai beaucoup avancé. J'ai même terminé la localisation. Comme ni Unicode, ni ISO ne répondaient à mes mails, je me suis moi-même créer mes tableaux de correspondances. Soit à travers des fichiers XML présents sur leur site, soit à partir de page HTML que je me suis résigné à parser.

Voici ce qu'on faire maintenant :

• fr_FR fonctionne ;
  fra_FRA fonctionne ;
  FR fonctionne ;
  FRA fonctionne ;
  Europe/Paris fonctionne ;
  France fonctionne.

Si on n'arrive pas à compléter l'informations (par exemple Europe/Paris retourne FR, on doit donc trouver la langue : fr), on retourne une liste de choix. Mais on cherchera toujours un résultat logique.

J'ai également réussi à contourner le problème de Windows avec son encodage à 2 balles (iso-3166-1_alpha-3 au lieu de 2).

Voici les liens qui m'ont été utile :

• ISO 3166 code lists : pour avoir la liste des correspondances régions <-> pays ;
  Unicode : Supplemental Data : pour avoir les correspondances language <-> régions et continent/ville <-> régions ;
  Country Codes: ISO 3166, Microsoft, and Macintosh : pour avoir la correspondance entre alpha2 et alpha3.

Je rappelle que Mac utilise l'alpha2.
Avec ces 4 listes, de la méthode, et beaucoup de cheveux (oui, on en arrache pas mal), on peut tout faire


Traduction

Passons donc à la traduction.
J'ai regardé Gettext de plus près. Les problèmes sont :

• un fichier compilé sous Linux ne fonctionnera que sous Linux ;
  un fichier complié sous Windows ne fonctionnera que sous Windows ;
  Windows ne définissant pas bien le local (LC_MESSAGES), Gettext ne trouve pas bien son chemin.

On va devoir faire un lecteur Gettext autre que gettext();. Il va donc falloir regarder du côté de unpack() et cie, mais là, je n'y comprends rien du tout '^^. Un peu d'aide serait la bienvenue.

Il va également falloir faire d'autres systèmes de traductions. Et serait-ce nécessaire de faire des traducteurs (lol) : par exemple de Gettext vers TMX, TMX vers INI etc.



Ah oui, une dernière question ! Est-ce que quelqu'un pourrait me donner la valeur de $_SERVER['HTTP_ACCEPT_LANGUAGE'] sous Konqueror s'il vous plaît ? Mozilla et Opera respectent les standards, mais IE 6&7, et Safari non. J'aimerais savoir pour Konqueror.

Merci

un fichier compilé sous Linux ne fonctionnera que sous Linux ;
un fichier complié sous Windows ne fonctionnera que sous Windows ;

Je ne suis pas convaincu de ça, tu as testé ou tu as lu ça concrètement quelque part ? Le fichier .mo est normalement tout-à-fait portable.

Windows ne définissant pas bien le local (LC_MESSAGES), Gettext ne trouve pas bien son chemin.

Oui mais de toute façon il vaut mieux toujours spécifier le TEXTDOMAIN (en constante en début d'application puis on le réapplique à chaque appel de gettext()), ça marche toujours mieux car même sous Linux il ne retrouve pas toujours ses petits si on lui laisse deviner le TEXTDOMAIN. Idem pour les emplacements par défaut des LC_MESSAGES même si ça ne touche que Windows.

On va devoir faire un lecteur Gettext autre que gettext()

Là je pense que tu devrais t'arrêter tout de suite parce que tu n'arriveras jamais à reproduire cet outil, en particulier sa vitesse d'exécution quand il utilise les fichiers compilés.
Et les formes plurielles ça va vite te gonfler à implémenter, alors que c'est un bonheur à utiliser.

Ah oui, une dernière question ! Est-ce que quelqu'un pourrait me donner la valeur de $_SERVER['HTTP_ACCEPT_LANGUAGE'] sous Konqueror s'il vous plaît ?

Chez moi ça donne : "fr, en"
Avec lynx ça donne ça : "en"

Pour la non-portabilité des fichiers *.mo compilés, oui je l'ai lu. Ca m'a beaucoup surpris. Mais à y réfléchir, c'est sûrement une bêtise.

Ok pour Gettext. Mais sous Windows, quand on lui dit setlocale(LC_ALL, 'fr_FR');, déjà il ne comprend pas, on doit lui dire setlocale(LC_ALL, 'fr_FR', 'fr', 'FR', 'FRA', 'FRANCE');. Ssi on renseigne de cette façon, celà fonctionnera sur toutes les plates-formes Windows. Mais que va-t-il enregistrer par la suite ? Si on regarde (setlocale(LC_ALL, 0);), il va nous dire : French_France.1225 ou un truc du genre (je ne connais pas tout par coeur quand même :roll:). Donc quand Gettext va chercher son chemin (locale/fr_FR/LC_MESSAGES/*.mo), il ne trouvera tout simplement pas le dossier fr_FR. Le problème est ici.

Quand je disais refaire un lecteur gettext(); je voulais dire refaire le comportement de la fonction. J'ai vu que ZF a fait ça avec des unpacks, mais j'y comprends rien du tout :P

Merci pour Lynx et Konqueror. Konqueror est encore un cas particulier ... (j'aime). Et si des gens sont motivés pour me donner la valeur de $_SERVER['HTTP_ACCEPT_LANGUAGE'] sous des Palm et autres, ce serait sympa ;-) (pourquoi aucun ne respecte les standards à part Firefox et Opera mince !)

Sympa la gestion des formes plurielles sous Gettext.

Donc si j'utilise Gettext par défaut, ça ne devrait pas poser de soucis (sauf ceux ci-dessus) ?

Ben c'est standard aussi la sortie de Konqueror.
Le «;q=X.Y» est facultatif, tout comme la région.
Mon Opéra sort «fr-FR,fr;q=0.9,en;q=0.8» mais il me semble que «fr,en» serait tout aussi valable

Pour le palm je te dis ça :
Windows Mobile 5.0
Internet Explorer : «fr» (et je n'ai trouvé nulle part une option pour changer cette valeur)
Opera Mini : «fr,en;q=0.9»

Ok nikel. Merci

Par contre, impossible de faire marcher gettext sous Windows :s

Je ne l'ai jamais fait fonctionner que sous Linux donc je ne peux pas trop te dire, mais à mon avis tu t'embêtes pour pas grand-chose, tu comptes offrir plusieurs systèmes de localisation ? Et bien le module «gettext» ne sera pas garanti si utilisé sur un serveur Windows. De toute façon vu la probabilité qu'un script PHP5 tourne sous Windows, tu peux te le permettre tant qu'il reste des solutions alternatives (TMX, INI, …).

Oui tu as raison.
Allé hop.

Et de toute façon, utiliser Windows sur un serveur est une hérésie alors ...

Je vous tiens au jus.

PS : comble de l'histoire. Ma mémoire vive a des problèmes en ce moment dû à son grand âge (>~5ans). A chaque démarrage, Windows perd la date et heure. C'est drôle Bientôt un Mac de toute façon