OVH Cloud OVH Cloud

Encodage et correction orthographique

37 réponses
Avatar
Olivier V
Bonjour,

Je suis sous Kubuntu 9.04, et j'utilise "kile" pour mes documents en LaTeX.
Les fichiers sur lesquels je travaille sont en fait des fichiers textes
encodés en iso-8859-15. Le reste du système est, comme par défaut, en utf8.
Le dictionnaire utilisé par kile est celui défini dans kde.

Or je ne parviens plus à régler le système pour obtenir un correcteur
orthographique travaillant en iso-8859-15.

Avant (kubuntu 8.04), on pouvait dans "kcontrol" définir le dictionnaire
utilisé, la langue et l'encodage,
mais ce n'est plus le cas, kcontrol ayant été remplacé par une autre
interface graphique ne laissant plus ce choix.

Avez une idée pour résoudre ce problème ?
Ou peut-on, par une succession de commandes, arriver à changer momentanément
l'encodage ?

Bref, toute proposition est la bienvenue !

Merci.

Olivier V

10 réponses

1 2 3 4
Avatar
Olivier V
wrote:

Cela dit (et j'aime pas faire la morale !), c'est vilain de poster le
même message dans plusieurs groupes sans le dire...



Parfaitement, mais j'ai bien "crossposté" le message initial, non ?

Olivier V
Avatar
Lucas Levrel
Le 13 novembre 2009, Olivier V a écrit :

Comment puis-je automatiser tout ça ?
J'ai pensé à faire :
alias kile='export LC_ALL= ; kile'
Est-ce la bonne méthode ?



Oui, mais note qu'à partir de là ton terminal aura cette locale (ce qui
peut perturber des commandes comme more/less, man...). Si tu utilises un
lanceur pas de pb, et pas besoin d'alias à vrai dire.

Pour répondre à la question « comment avoir le kile "normal" ? », tu fais
kile (avec bash tout du moins). Très pratique à connaître par exemple
quand on a « alias rm='rm -i' » et qu'on veut effacer une centaine de
fichiers...

Je n'ai pas essayé cette deuxième méthode.
Visiblement elle touchera tous les programmes,



... qui utilisent hunspell.


--
LL
Avatar
Lucas Levrel
Le 14 novembre 2009, Olivier V a écrit :

wrote:

> Cela dit (et j'aime pas faire la morale !), c'est vilain de poster le
> même message dans plusieurs groupes sans le dire...

Parfaitement, mais j'ai bien "crossposté" le message initial, non ?



Toutafé, c'est un boulet de fr.comp.text.tex qui n'a pas respecté le fu2,
ce qui t'a obligé à répondre aussi là-bas...

--
LL
Avatar
Olivier V
Lucas Levrel wrote:

Oui, mais note qu'à partir de là ton terminal aura cette locale (ce qui
peut perturber des commandes comme more/less, man...). Si tu utilises un
lanceur pas de pb, et pas besoin d'alias à vrai dire.



C'est fait avec un lanceur.
Mais aussi par clic droit "ouvrir avec kile", donc l'alias doit être
nécessaire.

Pour répondre à la question « comment avoir le kile "normal" ? », tu fais
kile (avec bash tout du moins). Très pratique à connaître par exemple
quand on a « alias rm='rm -i' » et qu'on veut effacer une centaine de
fichiers...



Merci pour ce tuyau.

Je n'ai pas essayé cette deuxième méthode.
Visiblement elle touchera tous les programmes,



... qui utilisent hunspell.



Oui.

Olivier V
Avatar
Olivier V
Lucas Levrel wrote:

Oui, mais note qu'à partir de là ton terminal aura cette locale (ce qui
peut perturber des commandes comme more/less, man...). Si tu utilises un
lanceur pas de pb, et pas besoin d'alias à vrai dire.



Je m'étais réjoui un peu vite ...

En fait, que ce soit avec un alias ou non, quand kile est lancé avec
'export LC_ALL= ; kile',
il ne parvient plus à ouvrir les répertoires contenant des caractères
accentués ... je n'en ai pas beaucoup, mais bon ...
Peut-être faut-il simplement y aller un peu moins fort que LC_ALL ?

Olivier V
Avatar
Olivier V
Lucas Levrel wrote:

Oui, mais note qu'à partir de là ton terminal aura cette locale (ce qui
peut perturber des commandes comme more/less, man...). Si tu utilises un
lanceur pas de pb, et pas besoin d'alias à vrai dire.



En fait c'est le cas ... que ce soit en konsole ou par lanceur.
En effet je viens de me rendre compte que je ne peux plus accéder aux
répertoires avec des accents (mauvaise habitude, mais j'en ai quelques uns
...).
Que ce soit par :
alias kile_euro='export LC_ALL= ; kile'
ou par
export LC_ALL= ; kile
avec un lanceur.

Peut-être faut-il y aller un peu moins fort que LC_ALL ?
Un des paramètres donnés par "locale" suffit peut-être à régler la langue
prise en compte pour le correcteur ?

Merci ... pour vos nouvelles idées.

Olivier V
Avatar
Olivier V
Olivier V wrote:

Lucas Levrel wrote:

Oui, mais note qu'à partir de là ton terminal aura cette locale (ce qui
peut perturber des commandes comme more/less, man...). Si tu utilises un
lanceur pas de pb, et pas besoin d'alias à vrai dire.



Je m'étais réjoui un peu vite ...

En fait, que ce soit avec un alias ou non, quand kile est lancé avec
'export LC_ALL= ; kile',
il ne parvient plus à ouvrir les répertoires contenant des caractères
accentués ... je n'en ai pas beaucoup, mais bon ...
Peut-être faut-il simplement y aller un peu moins fort que LC_ALL ?



Pas d'idées ?

J'ai aussi essayé avec hunspell dans mon home contenant :

export LC_ALL=
/usr/bin/hunspell $@

J'ai vérifié avec :

:~$ which hunspell
/home/meloli/bin/binperso/hunspell

Mais même problème : les mots avec accents ne sont pas lus correctement.

Des idées ?

Olivier V
Avatar
Lucas Levrel
Le 24 novembre 2009, Olivier V a écrit :

Peut-être faut-il y aller un peu moins fort que LC_ALL ?



Essaye LANG.

Un des paramètres donnés par "locale" suffit peut-être à régler la langue
prise en compte pour le correcteur ?



(quelques infos plus succinctes avec man bash aussi)

--
LL
Avatar
Olivier V
Lucas Levrel wrote:

Le 24 novembre 2009, Olivier V a écrit :

Peut-être faut-il y aller un peu moins fort que LC_ALL ?



Essaye LANG.



Même problème avec :
export LANG= ; kile

Olivier V
Avatar
Lucas Levrel
Le 26 novembre 2009, Olivier V a écrit :

Même problème avec :
export LANG= ; kile



Au fait, quel genre de problème ? Ici dans mon terminal, si je change
d'encodage en cours de route, les noms accentués pourrissent un peu
l'affichage mais c'est tout. (Notamment, si je crée un fichier avec
LANG= dans l'environnement, le nom de fichier est quand même
codé en UTF-8.)

--
LL
1 2 3 4