Bonjour,
Un poil HS mais également plein d'intérêt,
Je cherche à savoir comment fonctionne le module gettext pour indexer ses
messages via les fichiers mo
En fait après avoir fait le travail d'extraction, je m'inquiète un peu de
voir des chaines interminables passées en paramètres et je me demande
comment cela ne pourrait pas nuire aux performances du script.
Ensuite, le temps de réponse lors de l'accès aux valeurs associées à cette clé est indépendant puisque le résultat de la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a pas de champ mutable où stocker le résultat de la fonction de hachage.
Paul Gaborit wrote in message <wt9tzbp1yjy.fsf@marceau.enstimac.fr>:
Ensuite, le temps de réponse lors de l'accès aux
valeurs associées à cette clé est indépendant puisque le résultat de
la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a
pas de champ mutable où stocker le résultat de la fonction de hachage.
Ensuite, le temps de réponse lors de l'accès aux valeurs associées à cette clé est indépendant puisque le résultat de la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a pas de champ mutable où stocker le résultat de la fonction de hachage.
Paul Gaborit
À (at) 06 Oct 2008 19:09:20 GMT, Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Ensuite, le temps de réponse lors de l'accès aux valeurs associées à cette clé est indépendant puisque le résultat de la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a pas de champ mutable où stocker le résultat de la fonction de hachage.
'const char *' ? En Perl ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 06 Oct 2008 19:09:20 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit wrote in message <wt9tzbp1yjy.fsf@marceau.enstimac.fr>:
Ensuite, le temps de réponse lors de l'accès aux
valeurs associées à cette clé est indépendant puisque le résultat de
la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a
pas de champ mutable où stocker le résultat de la fonction de hachage.
'const char *' ? En Perl ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 06 Oct 2008 19:09:20 GMT, Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Ensuite, le temps de réponse lors de l'accès aux valeurs associées à cette clé est indépendant puisque le résultat de la fonction de hachage est stocké.
Stocké ? Stocké où ? gettext, ça prend un const char * en argument, il n'y a pas de champ mutable où stocker le résultat de la fonction de hachage.
'const char *' ? En Perl ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Paul Gaborit wrote in message :
'const char *' ? En Perl ?
gettext, c'est une API C, à la base. Tu peux avoir un wrapper en perl autour, mais je doute qu'il ajoute ce genre de cache.
Paul Gaborit wrote in message <wt9tzbpqwcv.fsf@marceau.enstimac.fr>:
'const char *' ? En Perl ?
gettext, c'est une API C, à la base. Tu peux avoir un wrapper en perl
autour, mais je doute qu'il ajoute ce genre de cache.
gettext, c'est une API C, à la base. Tu peux avoir un wrapper en perl autour, mais je doute qu'il ajoute ce genre de cache.
Paul Gaborit
À (at) Mon, 06 Oct 2008 13:30:55 +0200, Paul Gaborit écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200, "Jean-Charles Gibier" écrivait (wrote):
Du coup lorsque je considère les milliers de lignes du genre -> gettex("'Voulez-vous vraiment supprimer le fichier ressource du repertoire ...etc.'"); je pense que le temps de réponse doit forcemment être plus long que de simples -> gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse est indépendant da la taille de la clé (sauf la première fois qu'on voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du module Locale::Maketext qui pallie à plusieurs des défauts de la philosophie 'gettext'.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 06 Oct 2008 13:30:55 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200,
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> écrivait (wrote):
Du coup lorsque je considère les milliers de lignes du genre ->
gettex("'Voulez-vous vraiment supprimer le fichier ressource du repertoire
...etc.'");
je pense que le temps de réponse doit forcemment être plus long que de
simples ->
gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse
est indépendant da la taille de la clé (sauf la première fois qu'on
voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du
module Locale::Maketext qui pallie à plusieurs des défauts de la
philosophie 'gettext'.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 06 Oct 2008 13:30:55 +0200, Paul Gaborit écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200, "Jean-Charles Gibier" écrivait (wrote):
Du coup lorsque je considère les milliers de lignes du genre -> gettex("'Voulez-vous vraiment supprimer le fichier ressource du repertoire ...etc.'"); je pense que le temps de réponse doit forcemment être plus long que de simples -> gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse est indépendant da la taille de la clé (sauf la première fois qu'on voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du module Locale::Maketext qui pallie à plusieurs des défauts de la philosophie 'gettext'.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Paul Gaborit
À (at) 06 Oct 2008 21:40:58 GMT, Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
'const char *' ? En Perl ?
gettext, c'est une API C, à la base. Tu peux avoir un wrapper en perl autour, mais je doute qu'il ajoute ce genre de cache.
En lisant la description de Gettext (que je n'utilise pas) :
Gettext.pm emulates the gettext library routines in Perl, although it calls the external utility program gettext to actually read .mo files.
j'en avais conclu que tout était réécrit en Perl (sauf la lecture des fichiers .mo eux-mêmes) et donc avec des tables de hachages.
Mais ton message m'a fait douté. J'ai donc été lire le code. Et là... Horreur ! On trouve des lignes du genre :
Tu as donc raison sur les performances et c'est même bien pire puisqu'il y a appel à un shell et à gettext (donc deux processus) à chaque fois. Là, la longueur de la chaine ne pose plus de problème. C'est *lent* quoi qu'on fasse ! (il faut dire que c'est une version 0.01)
Il existe aussi un module Locale::gettext (1.05) qui semble mieux développé mais qui fait encore appel aux fonctions externes sans utiliser la puissance de Perl.
Reste donc le module que de nombreuses personnes conseillent avec raison : Locale::Maketext et sa variante Locale::Maketext::Gettext.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 06 Oct 2008 21:40:58 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit wrote in message <wt9tzbpqwcv.fsf@marceau.enstimac.fr>:
'const char *' ? En Perl ?
gettext, c'est une API C, à la base. Tu peux avoir un wrapper en perl
autour, mais je doute qu'il ajoute ce genre de cache.
En lisant la description de Gettext (que je n'utilise pas) :
Gettext.pm emulates the gettext library routines in Perl, although
it calls the external utility program gettext to actually read .mo
files.
j'en avais conclu que tout était réécrit en Perl (sauf la lecture des
fichiers .mo eux-mêmes) et donc avec des tables de hachages.
Mais ton message m'a fait douté. J'ai donc été lire le code. Et là...
Horreur ! On trouve des lignes du genre :
Tu as donc raison sur les performances et c'est même bien pire
puisqu'il y a appel à un shell et à gettext (donc deux processus) à
chaque fois. Là, la longueur de la chaine ne pose plus de problème.
C'est *lent* quoi qu'on fasse ! (il faut dire que c'est une version
0.01)
Il existe aussi un module Locale::gettext (1.05) qui semble mieux
développé mais qui fait encore appel aux fonctions externes sans
utiliser la puissance de Perl.
Reste donc le module que de nombreuses personnes conseillent avec
raison : Locale::Maketext et sa variante Locale::Maketext::Gettext.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Tu as donc raison sur les performances et c'est même bien pire puisqu'il y a appel à un shell et à gettext (donc deux processus) à chaque fois. Là, la longueur de la chaine ne pose plus de problème. C'est *lent* quoi qu'on fasse ! (il faut dire que c'est une version 0.01)
Il existe aussi un module Locale::gettext (1.05) qui semble mieux développé mais qui fait encore appel aux fonctions externes sans utiliser la puissance de Perl.
Reste donc le module que de nombreuses personnes conseillent avec raison : Locale::Maketext et sa variante Locale::Maketext::Gettext.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Jean-Charles Gibier
"Paul Gaborit" a écrit dans le message de news:
À (at) Mon, 06 Oct 2008 13:30:55 +0200, Paul Gaborit écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200, "Jean-Charles Gibier" écrivait (wrote):
Du coup lorsque je considère les milliers de lignes du genre -> gettex("'Voulez-vous vraiment supprimer le fichier ressource du repertoire ...etc.'"); je pense que le temps de réponse doit forcemment être plus long que de simples -> gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse est indépendant da la taille de la clé (sauf la première fois qu'on voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du module Locale::Maketext qui pallie à plusieurs des défauts de la philosophie 'gettext'.
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas. + une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
"Paul Gaborit" <Paul.Gaborit@invalid.invalid> a écrit dans le message de
news: wt9ljx1qto1.fsf@marceau.enstimac.fr...
À (at) Mon, 06 Oct 2008 13:30:55 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200,
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> écrivait
(wrote):
Du coup lorsque je considère les milliers de lignes du genre ->
gettex("'Voulez-vous vraiment supprimer le fichier ressource du
repertoire
...etc.'");
je pense que le temps de réponse doit forcemment être plus long que de
simples ->
gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse
est indépendant da la taille de la clé (sauf la première fois qu'on
voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du
module Locale::Maketext qui pallie à plusieurs des défauts de la
philosophie 'gettext'.
Merci
avant que je ne penche sur Locale::Maketext -> le principe est il le même
(dictionnaires portables compilés) ?
Sinon de manière générale les diverses remarques de ce thread m' en amènent
d'autres :
FCGI -> le programme sur lequel je travaille est multi plateforme mais
actuellement les tests sont sous IIS / perlis
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment
aller "au delà" d'une hashtable (à partir du moment où l'index numérique est
proscrit) peu importe qu'on soit en pure perl ou pas.
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen
de recenser les chaînes contenant des variables ("Le fichier nommé
$le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un
découpage ?
À (at) Mon, 06 Oct 2008 13:30:55 +0200, Paul Gaborit écrivait (wrote):
À (at) Mon, 6 Oct 2008 11:49:32 +0200, "Jean-Charles Gibier" écrivait (wrote):
Du coup lorsque je considère les milliers de lignes du genre -> gettex("'Voulez-vous vraiment supprimer le fichier ressource du repertoire ...etc.'"); je pense que le temps de réponse doit forcemment être plus long que de simples -> gettex(3980);
Mais peut être me trompe-je ?
Oui.
La recherche se fait dans une table de hachage : le temps de réponse est indépendant da la taille de la clé (sauf la première fois qu'on voit cette clé).
Je complète ma réponse en vous conseillant de regarder du côté du module Locale::Maketext qui pallie à plusieurs des défauts de la philosophie 'gettext'.
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas. + une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
Paul Gaborit
À (at) Tue, 7 Oct 2008 10:43:48 +0200, "Jean-Charles Gibier" écrivait (wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur les aspects linguistiques. Il faut lire l'article qui explique tout ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
Je ne comprends pas la question...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 7 Oct 2008 10:43:48 +0200,
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> écrivait (wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est
il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont
implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en amènent
d'autres :
FCGI -> le programme sur lequel je travaille est multi plateforme mais
actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être
faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment
aller "au delà" d'une hashtable (à partir du moment où l'index numérique est
proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur
les aspects linguistiques. Il faut lire l'article qui explique tout
ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen
de recenser les chaînes contenant des variables ("Le fichier nommé
$le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un
découpage ?
Je ne comprends pas la question...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 7 Oct 2008 10:43:48 +0200, "Jean-Charles Gibier" écrivait (wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur les aspects linguistiques. Il faut lire l'article qui explique tout ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
Je ne comprends pas la question...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Jean-Charles Gibier
"Paul Gaborit" a écrit dans le message de news:
À (at) Tue, 7 Oct 2008 10:43:48 +0200, "Jean-Charles Gibier" écrivait (wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur les aspects linguistiques. Il faut lire l'article qui explique tout ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
Je ne comprends pas la question...
Ce n'est pas vraiment capital mais c'est le problème posé par le présence des paramètres. Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des chaines. Donc s'il ya une autre méthode je suis preneur.
Merci pour les conseils.
"Paul Gaborit" <Paul.Gaborit@invalid.invalid> a écrit dans le message de
news: wt9ljx02098.fsf@marceau.enstimac.fr...
À (at) Tue, 7 Oct 2008 10:43:48 +0200,
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> écrivait
(wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est
il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont
implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en
amènent
d'autres :
FCGI -> le programme sur lequel je travaille est multi plateforme mais
actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être
faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment
aller "au delà" d'une hashtable (à partir du moment où l'index numérique
est
proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur
les aspects linguistiques. Il faut lire l'article qui explique tout
ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un
moyen
de recenser les chaînes contenant des variables ("Le fichier nommé
$le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un
découpage ?
Je ne comprends pas la question...
Ce n'est pas vraiment capital mais c'est le problème posé par le présence
des paramètres.
Dans l'option gettext on ne peut pas employer ce genre de construction :
print gettext("Le fichier : $nom_fichier est ouvert.n");
On est obligé de faire soit ceci :
print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n";
Soit ceci :
print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des
chaines.
Donc s'il ya une autre méthode je suis preneur.
À (at) Tue, 7 Oct 2008 10:43:48 +0200, "Jean-Charles Gibier" écrivait (wrote):
Merci avant que je ne penche sur Locale::Maketext -> le principe est il le même (dictionnaires portables compilés) ?
Non : les fichiers de traductions ne sont pas "compilés". Ils sont implicitement compilés en mémoire à chaque lancement du script.
Sinon de manière générale les diverses remarques de ce thread m' en amènent d'autres : FCGI -> le programme sur lequel je travaille est multi plateforme mais actuellement les tests sont sous IIS / perlis
Je n'ai jamais testé FastCGI avec IIS/Windows. Mais ça doit être faisable puisqu'il existe un package Perl FCGI::IIS...
lacunes de gettext -> en matière d'optimisation, je ne vois pas comment aller "au delà" d'une hashtable (à partir du moment où l'index numérique est proscrit) peu importe qu'on soit en pure perl ou pas.
L'optimisation a un prix : la mémoire.
Sinon, les améliorations apportées par Locale::Maketext sont plus sur les aspects linguistiques. Il faut lire l'article qui explique tout ça :
+ une question sur le problème d'interpolation -> Est ce qu'il ya un moyen de recenser les chaînes contenant des variables ("Le fichier nommé $le_nom_du_fichier est ouvert.") plus élégant qu' un sprintf ou un découpage ?
Je ne comprends pas la question...
Ce n'est pas vraiment capital mais c'est le problème posé par le présence des paramètres. Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des chaines. Donc s'il ya une autre méthode je suis preneur.
Merci pour les conseils.
Paul Gaborit
À (at) Tue, 7 Oct 2008 14:44:08 +0200, "Jean-Charles Gibier" écrivait (wrote):
Ce n'est pas vraiment capital mais c'est le problème posé par le présence des paramètres. Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des chaines. Donc s'il ya une autre méthode je suis preneur.
C'est un peu la même chose dans Locale::MakeText. Mais la syntaxe est différente :
print maketext("Le fichier : [_1] est ouvert.n"), $nom_fichier);
Ça permet de changer l'ordre d'apparition, de prévoir une éventuelle fonction de traitement pour les cas compliqués, ça permet aussi de vérifier qu'on n'oublie aucun argument...
Mais ça ne résoud pas votre problème : il faut quand même explorer tout le code pour extraire les chaînes à traduire. En fait, c'est assez fastidieux. Et c'est en général à ce moment-là qu'on se dit que la prochaine fois, on prévoira de faire l'I18N dès de le départ ! ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 7 Oct 2008 14:44:08 +0200,
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> écrivait (wrote):
Ce n'est pas vraiment capital mais c'est le problème posé par le présence
des paramètres.
Dans l'option gettext on ne peut pas employer ce genre de construction :
print gettext("Le fichier : $nom_fichier est ouvert.n");
On est obligé de faire soit ceci :
print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n";
Soit ceci :
print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des
chaines.
Donc s'il ya une autre méthode je suis preneur.
C'est un peu la même chose dans Locale::MakeText. Mais la syntaxe est
différente :
print maketext("Le fichier : [_1] est ouvert.n"), $nom_fichier);
Ça permet de changer l'ordre d'apparition, de prévoir une éventuelle
fonction de traitement pour les cas compliqués, ça permet aussi de
vérifier qu'on n'oublie aucun argument...
Mais ça ne résoud pas votre problème : il faut quand même explorer
tout le code pour extraire les chaînes à traduire. En fait, c'est
assez fastidieux. Et c'est en général à ce moment-là qu'on se dit que
la prochaine fois, on prévoira de faire l'I18N dès de le départ ! ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 7 Oct 2008 14:44:08 +0200, "Jean-Charles Gibier" écrivait (wrote):
Ce n'est pas vraiment capital mais c'est le problème posé par le présence des paramètres. Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
Ce qui n'est pas tres pratique lorsqu'on est en phase d'extraction des chaines. Donc s'il ya une autre méthode je suis preneur.
C'est un peu la même chose dans Locale::MakeText. Mais la syntaxe est différente :
print maketext("Le fichier : [_1] est ouvert.n"), $nom_fichier);
Ça permet de changer l'ordre d'apparition, de prévoir une éventuelle fonction de traitement pour les cas compliqués, ça permet aussi de vérifier qu'on n'oublie aucun argument...
Mais ça ne résoud pas votre problème : il faut quand même explorer tout le code pour extraire les chaînes à traduire. En fait, c'est assez fastidieux. Et c'est en général à ce moment-là qu'on se dit que la prochaine fois, on prévoira de faire l'I18N dès de le départ ! ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Patrice Karatchentzeff
"Jean-Charles Gibier" a écrit :
[...]
Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
<HS> La première solution n'est évidemment pas recommandable. La forme du langage étant spécifique à chaque langue, il faut laisser le maximum de libertés aux traducteurs pour remettre les mots à leur place. </HS>
"Jean-Charles Gibier" <jeancharles__and__g@free.fr.invalid> a écrit :
[...]
Dans l'option gettext on ne peut pas employer ce genre de construction :
print gettext("Le fichier : $nom_fichier est ouvert.n");
On est obligé de faire soit ceci :
print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n";
Soit ceci :
print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
<HS>
La première solution n'est évidemment pas recommandable. La forme du
langage étant spécifique à chaque langue, il faut laisser le maximum
de libertés aux traducteurs pour remettre les mots à leur place.
</HS>
Dans l'option gettext on ne peut pas employer ce genre de construction : print gettext("Le fichier : $nom_fichier est ouvert.n"); On est obligé de faire soit ceci : print gettext("Le fichier :"). $nom_fichier .gettext("est ouvert").".n"; Soit ceci : print sprintf (gettext("Le fichier : %s est ouvert.n"), $nom_fichier);
<HS> La première solution n'est évidemment pas recommandable. La forme du langage étant spécifique à chaque langue, il faut laisser le maximum de libertés aux traducteurs pour remettre les mots à leur place. </HS>
