Je n'avais jamais eu besoin des caractères accentués pour l'intant, mais
là, dans nvi, NetBSD 1.6 avec un shell csh, j'ai les nerfs !
J'ai cherché un peu partout dans les faqs et google groupes, rien ne
marche. J'ai bien mon clavier en français bien entendu, mais les setenv
LANG ne semblent pas fonctionner. J'ai tenté de changer rc.conf, ça ne
marche pas non plus :(
J'utilise nvi en mode texte, sans X.
Quelqu'un a-t-il eu ce pépin et peut-il m'indiquer comment faire pas à pas ?
(à force de changer rc, rc.conf, .cshc etc... m'en sors plus).
Dans .cshrc, ça fonctionne (alors que sur la flopée de sites visités, même en allemand, chacun a une solution différente !). J'avais même essayé la locale en_US* car c'était conseillé sur un site français.
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur choix. Un certain nombre de truc localisés ont une conception bizarre du principe de localisation ... L'exemple le plus amusant c'est libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière localisée, du coup les flottant sont affichés avec ',' et non pas '.', comme ça, on pourrait penser que ce n'est pas grave, mais quand on cherche à sérialiser des infos dans des fichiers et que le contenu change en fonction de la locale ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <42521c33$0$1246$8fcfb975@news.wanadoo.fr>, costaclt wrote:
Dans .cshrc, ça fonctionne (alors que sur la flopée de sites visités,
même en allemand, chacun a une solution différente !). J'avais même
essayé la locale en_US* car c'était conseillé sur un site français.
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur
choix. Un certain nombre de truc localisés ont une conception bizarre
du principe de localisation ... L'exemple le plus amusant c'est
libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière
localisée, du coup les flottant sont affichés avec ',' et non pas '.',
comme ça, on pourrait penser que ce n'est pas grave, mais quand on
cherche à sérialiser des infos dans des fichiers et que le contenu
change en fonction de la locale ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Dans .cshrc, ça fonctionne (alors que sur la flopée de sites visités, même en allemand, chacun a une solution différente !). J'avais même essayé la locale en_US* car c'était conseillé sur un site français.
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur choix. Un certain nombre de truc localisés ont une conception bizarre du principe de localisation ... L'exemple le plus amusant c'est libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière localisée, du coup les flottant sont affichés avec ',' et non pas '.', comme ça, on pourrait penser que ce n'est pas grave, mais quand on cherche à sérialiser des infos dans des fichiers et que le contenu change en fonction de la locale ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Vincent
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur choix. Un certain nombre de truc localisés ont une conception bizarre du principe de localisation ... L'exemple le plus amusant c'est libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière localisée, du coup les flottant sont affichés avec ',' et non pas '.', comme ça, on pourrait penser que ce n'est pas grave, mais quand on cherche à sérialiser des infos dans des fichiers et que le contenu change en fonction de la locale ...
Bon exemple. À propos de locale, quelqu'un a déjà obtenue une date en français avec 'date' ou avec strftime ?
Juste pour savoir Vincent
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur
choix. Un certain nombre de truc localisés ont une conception bizarre
du principe de localisation ... L'exemple le plus amusant c'est
libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière
localisée, du coup les flottant sont affichés avec ',' et non pas '.',
comme ça, on pourrait penser que ce n'est pas grave, mais quand on
cherche à sérialiser des infos dans des fichiers et que le contenu
change en fonction de la locale ...
Bon exemple.
À propos de locale, quelqu'un a déjà obtenue une date en français avec
'date' ou avec strftime ?
Parfois, la locale en_US.ISO8859-1 (ou la 15 ... ) est un meilleur choix. Un certain nombre de truc localisés ont une conception bizarre du principe de localisation ... L'exemple le plus amusant c'est libgtk2 qui redéfinit (lui ou un autre truc lié) printf de manière localisée, du coup les flottant sont affichés avec ',' et non pas '.', comme ça, on pourrait penser que ce n'est pas grave, mais quand on cherche à sérialiser des infos dans des fichiers et que le contenu change en fonction de la locale ...
Bon exemple. À propos de locale, quelqu'un a déjà obtenue une date en français avec 'date' ou avec strftime ?
Juste pour savoir Vincent
Cyrille Szymanski
On 2005-04-03, Manuel Bouyer wrote:
Xavier wrote:
Cyrille Szymanski wrote:
setenv LC_CTYPE fr_FR.ISO8859-1
Ça fait pas râler perl ça ?
Oh que si !
Mais ca ne l'empeche pas de marcher.
C'est dû à perl ou à NetBSD en particulier ?
-- Cyrille Szymanski
On 2005-04-03, Manuel Bouyer <bouyer@nerim.net> wrote:
C'est dû à une perl qui considère les choix de 'locale' comme incomplets, incohérents ou tout simplement non reconnus... En attendant mieux, pour se débarasser du message de perl à chaque exécution, on peut définir la variable d'environnement PERL_BADLANG à 0.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
On 2005-04-03, Manuel Bouyer <bouyer@nerim.net> wrote:
Xavier <xavier@groumpf.org> wrote:
Cyrille Szymanski <cns@cns2.invalid> wrote:
setenv LC_CTYPE fr_FR.ISO8859-1
Ça fait pas râler perl ça ?
Oh que si !
Mais ca ne l'empeche pas de marcher.
C'est dû à perl ou à NetBSD en particulier ?
C'est dû à une perl qui considère les choix de 'locale' comme incomplets,
incohérents ou tout simplement non reconnus... En attendant mieux, pour se
débarasser du message de perl à chaque exécution, on peut définir la variable
d'environnement PERL_BADLANG à 0.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
C'est dû à une perl qui considère les choix de 'locale' comme incomplets, incohérents ou tout simplement non reconnus... En attendant mieux, pour se débarasser du message de perl à chaque exécution, on peut définir la variable d'environnement PERL_BADLANG à 0.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
C'est dû à une perl qui considère les choix de 'locale' comme incomplets, incohérents ou tout simplement non reconnus... En attendant mieux, pour se débarasser du message de perl à chaque exécution, on peut définir la variable d'environnement PERL_BADLANG à 0.
Ok merci
-- Cyrille Szymanski
On 2005-04-06, Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
On 2005-04-03, Manuel Bouyer <bouyer@nerim.net> wrote:
Xavier <xavier@groumpf.org> wrote:
Cyrille Szymanski <cns@cns2.invalid> wrote:
setenv LC_CTYPE fr_FR.ISO8859-1
Ça fait pas râler perl ça ?
Oh que si !
Mais ca ne l'empeche pas de marcher.
C'est dû à perl ou à NetBSD en particulier ?
C'est dû à une perl qui considère les choix de 'locale' comme incomplets,
incohérents ou tout simplement non reconnus... En attendant mieux, pour se
débarasser du message de perl à chaque exécution, on peut définir la variable
d'environnement PERL_BADLANG à 0.
C'est dû à une perl qui considère les choix de 'locale' comme incomplets, incohérents ou tout simplement non reconnus... En attendant mieux, pour se débarasser du message de perl à chaque exécution, on peut définir la variable d'environnement PERL_BADLANG à 0.
