j'ai un petit problème avec locale.setlocale sur python.
Sur un ordi sous Ubuntu,
locale.setlocale(locale.LC_ALL, 'en_GB.UTF8')
marche sans problème.
Sous debian, il me crache un
:Error: unsupported locale setting
D'où mes questions :
1) est-il possible de lister les locale installé sur l'ordinateur où s'exécute un programme python ? si oui comment ?
2) comment faire pour installer une locale ?
Pour le point 2), j'ai essayé de changer le fichier /etc/locale.gen et de lancer le scripte locale-gen en root, mais rien ne change.
Merci pour votre aide.
# installer une locale
Posté par roduit (site web personnel) . Évalué à 0.
Cette méthode est-elle valable sous les autre systèmes (RedHat, Mandriva, Gentoo, ...) ?
Y a-t-il une méthode plus user-friendly (là, on est obligé de passer root) ?
[^] # Re: installer une locale
Posté par dave . Évalué à 2.
man locales
man locale-gen
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: installer une locale
Posté par dave . Évalué à 3.
dpkg-reconfigure locales.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: installer une locale
Posté par dave . Évalué à 2.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
# Liste des locales installées
Posté par roduit (site web personnel) . Évalué à 0.
pour l'instant, je fait un try ... except... et affiche une erreur si la locale n'est pas installée.
Mais ce qui m'intéresse, c'est de pouvoir lister toutes les locales installées, depuis mon scripte python, pour voire si une compatible à mon système est installée.
Pour plus de clarté, je m'explique :
Je dois lire des fichiers dans lequel il y a la date de création sous formatage anglo-saxon. J'utilise donc la librairie time de python qui me permet d'extraire la date. Ça me permet de trier chronologiquement mes fichiers.
Cependant, time extrait la date selon la locale définie dans l'environnement. Pour cela, je dois faire un setlocale avant. J'ai jeté mon dévolu sur en_GB.UTF8, mais je pense que tous les en_**.UTF8 sont possible.
Donc plutôt que de tester tous les existant, il me serait plus simple d'avoir une liste et de faire une recherche par expression régulière.
Voilà pourquoi ça me serait plus simple d'avoir une liste et de mettre l'erreur qu'en dernier recours.
Merci pour vos commentaires !
[^] # Re: Liste des locales installées
Posté par dave . Évalué à 2.
locale -a
pour lister les locales disponibles sur ton système.Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Liste des locales installées
Posté par roduit (site web personnel) . Évalué à 1.
Sur mon système, c'est bon, mais le problème sera sur les système sur lequel mon soft sera installé. J'aimerais pouvoir être le plus générique possible.
Bon, je peux toujours me créer une liste de toutes les locales qui fonctionnent (et que j'aurais testé) et les essayer les unes après les autres, mais ça risque d'allonger le démarrage.
[^] # Re: Liste des locales installées
Posté par benoar . Évalué à 2.
En effet, en python, je ne trouve rien du tout. Et même pas en C par la glibc ! Il n'y a que possibilité de définir la locale, pas de les lister.
Je me suis demandé comment était construite la liste de "locale -a", et la réponse est dans les sources (Luke !) :
http://sourceware.org/git/?p=glibc.git;a=blob;f=locale/progr(...)
Ce n'est donc pas une fonction d'une librairie. Le résultat de locale (1) est construit en allant voir les fichiers de locale et le contenu de locale.alias. Voilà.
À toi donc de faire une fonction pour lancer locale -a et récupérer la liste. Pas trop de soucis pour la généricité, c'est une appli faisant partie de la glibc, et le format de sortie est exactement celui attendu par setlocale.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.