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 :P Bientôt un Mac de toute façon :!:

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, …).

Ok nikel. Merci ;-)

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

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»

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 [color=olive]setlocale(LC_ALL, 'fr_FR');[/color], déjà il ne comprend pas, on doit lui dire [color=olive]setlocale(LC_ALL, 'fr_FR', 'fr', 'FR', 'FRA', 'FRANCE');[/color]. [b]Ssi[/b] 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 ([color=olive]setlocale(LC_ALL, 0);[/color]), il va nous dire : [color=olive]French_France.1225[/color] ou un truc du genre (je ne connais pas tout par coeur quand même :roll:). Donc quand Gettext va chercher son chemin ([color=olive]locale/fr_FR/LC_MESSAGES/*.mo[/color]), il ne trouvera tout simplement pas le dossier [color=olive]fr_FR[/color]. 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 [color=olive]$_SERVER['HTTP_ACCEPT_LANGUAGE'][/color] 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) ?

[quote="HyWaN"]un fichier compilé sous Linux ne fonctionnera que sous Linux ;
un fichier complié sous Windows ne fonctionnera que sous Windows ;[/quote]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.

[quote]Windows ne définissant pas bien le local (LC_MESSAGES), Gettext ne trouve pas bien son chemin.[/quote]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.

[quote]On va devoir faire un lecteur Gettext autre que gettext()[/quote]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 [url=http://www.gnu.org/software/libc/manual/html_node/Advanced-gettext-functions.html]formes plurielles[/url] ça va vite te gonfler à implémenter, alors que c'est un bonheur à utiliser.

[quote]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 :) ? [/quote]Chez moi ça donne : "fr, en"
Avec lynx ça donne ça : "en"

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 ^^

[size=150]Localisation[/size]

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 :
[list][b]fr_FR[/b] fonctionne ;
[b]fra_FRA[/b] fonctionne ;
[b]FR[/b] fonctionne ;
[b]FRA[/b] fonctionne ;
[b]Europe/Paris[/b] fonctionne ;
[b]France[/b] fonctionne.[/list]
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_[b]alpha-[u]3[/u][/b] au lieu de [b][u]2[/u][/b]).

Voici les liens qui m'ont été utile :
[list][url=http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html]ISO 3166 code lists[/url] : pour avoir la liste des correspondances régions <-> pays ;
[url=http://unicode.org/cldr/data/common/supplemental/supplementalData.xml]Unicode : Supplemental Data[/url] : pour avoir les correspondances language <-> régions et continent/ville <-> régions ;
[url=http://unicode.org/onlinedat/countries.html]Country Codes: ISO 3166, Microsoft, and Macintosh[/url] : pour avoir la correspondance entre alpha2 et alpha3.
[/list]
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 :)


[size=150]Traduction[/size]

Passons donc à la traduction.
J'ai regardé Gettext de plus près. Les problèmes sont :
[list]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.[/list]

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 :)

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 ...

[b]Edit[/b] : Bon, on avance :P 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 :D 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 ;)

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, c'est ce que je pensais faire. Mais Windows est encore plus capricieux. Regardez :
[code]on donne :
setlocale(LC_ALL, 'de_DE');
ça ne fonctionne pas pour Windows, et fonctionne pour les autres.

on donne :
setlocale(LC_ALL, 'de_DE', 'de');
ça ne fonctionne pas pour Windows, et je n'ai pas essayé pour les autres, mais devrait être fonctionnel.

on donne :
setlocale(LC_ALL, 'de_DE', 'de', 'deu');
ça fonctionne partout.[/code]

Donc, j'aimerais avoir un tableau associatif de l'iso 3166-1 [b]alpha-2[/b] à [b]alpha-3[/b]. 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.

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...

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) :P Je deviens de plus en plus adepte de cette philosophie lol


[b]Edit[/b] : 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.

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 :oops:

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

Pour l'instant, je me suis penché sur la localisation. Et j'ai un soucis :P. 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 :)

function __($message, $lang = null) {
  $message = mb_strtolower($message, mb_detect_encoding($message));
  ...
}

function compile_lang($lang) {
  ...
        $translations[mb_strtolower($original_message, mb_detect_encoding($original_message))] = $line;
  ...
}

[quote="HyWaN"]Mais ça pose un problème, on est obligé de taper la phrase avec la même case (minuscule/majuscule), sinon on ne trouvera pas l'entrée dans notre tableau.[/quote]Être sensible à la casse me paraît vital en effet :? On ne peut pas être sûr que la ponctuation ou la gestion de la casse sera la même d'une langue à l'autre, donc il faut rester sensible à la casse. C'est d'ailleurs le cas de gettext et de TMX.
Non la grosse faiblesse de mon système, ou plutôt la grosse force de gettext (je ne connais pas le détail de TMX) c'est la gestion des pluriels. Par exemple en français on dira "0 objets" (on met au pluriel) alors qu'en anglais ce sera "0 object" (on laisse au singulier). Dans un système où on ne peut gérer les pluriels on devra se contenter d'une traduction générique "%u object(s)" => "%u objet(s)", alors que gettext permettra de gérer ça finement (je n'ai plus le détail de la méthode en tête, mais ça se fait dans des directives de config au début du fichier .po).

Si tu tiens à être insensible à la casse, il faut simplement mettre les clés du tableau en basse casse et comparer avec le message en basse casse :[php]function __($message, $lang = null) {
$message = mb_strtolower($message, mb_detect_encoding($message));
...
}[/php][php]function compile_lang($lang) {
...
$translations[mb_strtolower($original_message, mb_detect_encoding($original_message))] = $line;
...
}[/php]

Ainsi s'il y a l'entrée "Object" => "Objet", alors "objeCt" sera aussi traduit par "Objet", mais est-ce bien élégant ? Quant à reporter la casse du message à traduire sur le message traduit, comment le faire alors qu'il n'y aura pas le même nombre de lettres, et pas les mêmes mots dans le même ordre (ni au même nombre non plus) dans le message traduit ?