gestion des codes de caracteres dans Lifelines
Bernard
Je suis un ancien habitué de Lifelines qui n'a pas eu suffisamment de
temps pour s'occuper de sa généalogie depuis plusieurs années.
En 2008, j'avais tout de même remplacé ma vieille version originelle
(3.02) par la 3.062, laquelle, après quelques ajustements et un patch
pour corriger un bug, avait fonctionné à merveille.
Puis, à nouveau, de nombreux mois se sont écoulés. En août dernier, j'ai
été obligé de remplacer mon vieux system Linux Debian Sarge par Debian
Lenny, et c'est seulement maintenant que je réinstalle Lifelines. Je
constate qu'on en est toujours à la version 3.062. Le problème,
aujourd'hui, c'est que je n'arrive pas à 'acclimater' cette version à mon
environnement, s'agissant des caractères accentués, alors que j'y étais
parvenu précédemment sur mon vieux système Sarge sur la même machine.
Que les menus s'affichent en anglais, je m'en moque, et même çà
m'arrange, car j'ai toujours eu cet environnement là avec Lifelines. Par
contre, lorsque j'ouvre une base lifelines dans laquelle les noms,
prénoms, professions etc.. comportent des accents, cédilles etc..., je
souhaite que çà s'affiche correctement, comme c'était précédemment le cas.
Comment m'y prendre ? Le fichier .linesrc comporte des options, que
j'ai - sauf erreur - toutes essayées, sans résultat, tout au moins pour
les bases. Quant aux fonctions permettant de changer les codages, je ne
sais pas les utiliser, et ce que j'en ai essayé n'a aboutit qu'à des
erreurs.
Merci d'avance pour votre aide.
Bernard
Patrick Texier
> Comment m'y prendre ? Le fichier .linesrc comporte des options, que
> j'ai - sauf erreur - toutes essay�es, sans r�sultat, tout au moins pour
> les bases. Quant aux fonctions permettant de changer les codages, je ne
> sais pas les utiliser, et ce que j'en ai essay� n'a aboutit qu'� des
> erreurs.
Il faut que tu v�rifies que ta base de donn�es a un jeu de caract�res
d�clar�.
Dans .linesrc, le jeu par d�faut pour les nouvelles bases est � la
ligne�:
NewDbProps=codeset=UTF-8
Pour voir le jeu de la base ouverte, depuis le menu principal :
u Utilitaires divers
o Modifier le fichier d'options utilisateur
� l'�diteur, il doit afficher une ligne :
codeset=UTF-8
Il n'est pas possible de modifier (ou de d�finir s'il n'y en a pas) le
jeu d'une base. Il faut importer un gedcom dans une base vide.
On voit les conversions effectu�es en utilisant :
t Modifier les tables de correspondance de caract�res
Sous Windows, cela m'affiche :
e �diteur vers Interne : 0 passage:
m Interne vers �diteur : 0 passage:
i GEDCOM vers Interne : 0 passage:
x Interne vers GEDCOM : 0 passage:
g Affichage vers Interne : 1 passage: iconv(CP850,UTF-8)
d Interne vers Affichage : 1 passage: iconv(UTF-8,CP850)
p Rapport vers Interne : 0 passage:
r Interne vers Rapport : 0 passage:
--
Patrick Texier
vim:syntax=mail:ai:ts=4:et:tw=72
Bernard
Merci Patrick pour ces précisions. Je n'ai toujours pas trouvé la
solution.
J'ai bien compris que pas mal de choses avaient changé dans la gestion
des langues et jeux de caractères dans Lifelines. Mais je ne comprends
toujours pas la différence entre mes deux ordis et, s'agissant du
premier, la différence entre ce que j'obtenais avec mon ancien système
Linux Debian Sarge et le nouveau (Debian Lenny). Avec mon ordi de bureau,
llines 3.0.62 sous Debian Sarge fonctionnait sans problème, les accents
étant traduits normalement. llines 62 ? Oui, je pense que c'était cette
version, même si la confusion est possible.
Sur mon ordi de bureau sous Lenny, j'ai Lifelines 3.0.62 installé depuis
un tarball récupéré sur sourceforge. J'ai également testé
Lifelines-3.0.61 installé depuis le Debian package, ce qui donne les
mêmes résultats s'agissant des caractères accentués.
Sur mon portable, c'est Ubuntu 8.04 (Hardy Heron), et ensuite
Lifelines-3.0.61 installé par rpm package, puis 3.0.62 installé ensuite
par le processus classique (./configure, make, make install)
Sur le premier (ordi de table avec Lenny), le "menu", dans un terminal
sous GNOME, s'affiche en français sans les accents. Voici un copié collé
de ce que j'ai :
┌───────────────────────────────────────────────────────────────────────┐
│Quel rM-CM-)pertoire contient (ou contiendra) la base LifeLines ? (?
lis
tentrez le chemin d'accM-CM-
(s : │
└───────────────────────────────────────────────────────────────────────┘
Avec le second (portable avec Ubuntu), çà s'affiche plus correctement :
Quel répertoire contient (ou contiendra) la base LifeLines ? (? lis
te) entrez le chemin d'accès :
Si, dans une configuration comme dans l'autre, je modifie, dans .linesrc,
la ligne :
# UiLocaleCollate=en en :
UiLocaleCollate=en
(ainsi que UilocaleMessages)
le menu apparaît en anglais, sans faute, ce qui, à tout le moins,
démontre que mes fichiers '.linesrc' sont bien dans les bon répertoire et
opérationnels.
Voilà donc pour afficher dès l'abord les différences entre mes deux
installations. Sur l'un comme sur l'autre ordi, mes variables 'LOCALE'
affichent très exactement la même chose :
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
et cependant, l'un tient compte des accents, l'autre non.
J'ai bien compris que dans les versions récentes de LL, les paramètres
liguistiques devaient être déclarés dans les gedcoms avant leur
importation dans les bases, aussi trouvai-je normal que mes vieilles
bases n'affichent pas les accents avec les dernières versions de
Lifelines. J'ai donc essayé de démarrer une nouvelle base, et d'y saisir
une fiche, avec accents. Eh bien, sur mon ordi de bureau (Debian Lenny),
les caractères accentués ne se retrouvent pas après sauvegarde, alors
qu'ils s'y retrouvent bien sur mon DELL sous Ubuntu avec les mêmes
Lifelines 3.0.61 et 3.0.62.
Sur le premier (Debian Lenny), voici l'affichage des menus concernés :
't' : 0 passage pour chaque ligne
'u' 'c' :
LifeLines 3.0.62 - SGBD gM-CM-)nM-CM-)alogique et systM-CM-(me de
programmation │
│ Copyright M-BM-) de 1991 M-CM- 1996, par T. T. Wetmore
IV │
│ Base ouverte - /home/bd/lines_fr/databases/
newnew │
├───────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Choisissez une opM-CM-)
ration :
│
│ b Parcourir les personnes dans la
base │
│ s Chercher dans la
base
│
│ a Ajouter une information dans la
base │
│ d Supprimer une information dans la
base │
│
┌────────────────────────────────────────────────────────────────────────────────────────────────┐
│
│ │Information de code de page :
(1/19)) │ │
│ │ >Page de codes interne:
UTF-8 │
│
│ │ UTF-8 en interne :
oui
│ │
│ │ Locales
disponibles.
│ │
│ │ NLS (Support de Langage National)
inclus. │ │
│ │ LocaleDir (default): /usr/local/share/
locale │ │
│ │ LocaleDir
(override):
│ │
│ │ bind_textdomain_codeset:
UTF-8 │ │
│ │ iconv (conversion de code de page)
inclus. │ │
│ │ Collate locale au dM-CM-)marrage :
fr_FR.UTF-8 │ │
│ │ Message locale au dM-CM-)marrage :
fr_FR.UTF-8 │ │
│ │ Collate locale courant :
fr_FR.UTF-8 │ │
│ │ Messages locale courant :
fr_FR.UTF-8 │ │
│ │ Routine de conversion :
strcmp │ │
│ │ Jeu de caractM-CM-(re GUI :
UTF-8 │ │
│ │ Jeu de caractM-CM-(res M-CM-)diteur :
UTF-8 │ │
│ │ Jeu de caractM-CM-(res rapports :
UTF-8 │ │
│ │ Jeu de caractM-CM-(res GEDCOM :
UTF-8 │ │
│ │
TTPATH: .
│ │
│ │ PropriM-CM-)tM-CM-)s UTF-8 non chargM-CM-)
es │ │
│
├────────────────────────────────────────────────────────────────────────────────────────────────┤
│
│ │Commandes : j DM-CM-)pl. bas k DM-CM-)pl. haut i SM-CM-)
lect. q Quitter │ │
│
└────────────────────────────────────────────────────────────────────────────────────────────────┘
et très exactement la même chose sur le second, à ceci près que les
accents sont traduits.
Je suis bien convaincu qu'il faut chercher dans 'gettext' et autres, mais
je ne sais pas par où commencer, et cela risque de durer fort longtemps,
à moins que quelqu'un me mette sur la voie des investigations à
poursuivre.
Merci d'avance pour ton aide.
Bernard
> Le Thu, 26 Nov 2009 17:47:25 +0100, Patrick Texier a écrit :
>
> Merci Patrick pour ces précisions. Je n'ai toujours pas trouvé la
> solution.
>
Après moultes recherches, j'ai finalement questionné la liste de
diffusion "Debian-user", où quelqu'un m'a répondu que, vraisemblablement,
il me manquait :
libncursesw5-dev
Et, en effet, depuis que j'ai installé ce package, puis recompilé
Lifelines-3.0.62, le comportement est devenu normal pour l'interprétation
des caractères accentués du Français.
Patrick Texier
> Que les menus s'affichent en anglais, je m'en moque, et m�me ��
> m'arrange, car j'ai toujours eu cet environnement l� avec Lifelines.
Contrairement � d'autres, j'ai fait le choix de ne pas traduire les
raccourcis menus pour �videmment ne pas p�naliser ceux qui comme nous
utilisent LifeLines depuis la version de Tom Wetmore. On garde nos
father, mother et autre childs.
La seule exception est l'historique (absent de la version de Tom) qui
utilise & � la place de ^, plus accessible.
Patrick Texier
> Apr�s moultes recherches, j'ai finalement questionn� la liste de
> diffusion "Debian-user", o� quelqu'un m'a r�pondu que, vraisemblablement,
> il me manquait :
>
> libncursesw5-dev
>
> Et, en effet, depuis que j'ai install� ce package, puis recompil�
> Lifelines-3.0.62, le comportement est devenu normal pour l'interpr�tation
> des caract�res accentu�s du Fran�ais.
Le r�sultat est impressionnant. Avec un vieux ncurses, on peut avoir des
probl�mes de d�calage � l'affichage, cela ce r�gle en utilisant xterm
qui prend en compte le bogue.
Bernard
> Contrairement à d'autres, j'ai fait le choix de ne pas traduire les
> raccourcis menus pour évidemment ne pas pénaliser ceux qui comme nous
> utilisent LifeLines depuis la version de Tom Wetmore. On garde nos
> father, mother et autre childs.
d'autant que, dans la version francisée, lorsqu'on voit 'père' et 'mère',
on est tenté de taper 'p' et 'm' pour atteindre l'un ou l'autre... je
trouve que c'est un facteur de confusion dans l'utilisation réflexe de LL.
Bernard
> Le 06 Dec 2009 23:48:43 GMT, Bernard a écrit :
>
>> il me manquait :
>>
>> libncursesw5-dev
>>
>> Et, en effet, depuis que j'ai installé ce package, puis recompilé
>> Lifelines-3.0.62, le comportement est devenu normal pour
>> l'interprétation des caractères accentués du Français.
>
> Le résultat est impressionnant. Avec un vieux ncurses, on peut avoir des
> problèmes de décalage à l'affichage, cela ce règle en utilisant xterm
> qui prend en compte le bogue.
Oui mais cela ne résout pas totalement mon problème d'accents. Dans ce
nouveau contexte, mes bases d'affichent bien avec le browse, et certains
'llprograms' (tels que 'Ahnentafel' et autres avec sorties en mode
texte), traduisent également bien les accents. Par contre, d'autres
programmes plus sophistiqués avec sorties en postscript, tels que 'ps-
anc.ll' et dérivés, ne traduisent pas les accents, sauf à me remettre
dans la situation antérieure pour la création des LLdatabases, celle où
les accents du gedcom ne sont pas traduits à l'affichage.
Ainsi, la solution que j'ai trouvée - et que j'espère temporaire - est la
suivante :
pour chaque base de données généalogiques, créer deux lldatabases. Par
exemple, je nomme la première 'vendee_8859-1' et j'y importe un gedcom
dont l'entête comporte ceci :
0 HEAD
1 CHAR ISO-8859-1
et là, dans la config que j'ai (voir mon .linesrc plus bas), les
caractères accentués apparaissent OK dans le browse, mais pas dans les
sorties ps de ps-anc.ll.
Je nomme la seconde base 'vendee_utf-8' et j'y importe le même gedcom,
mais dont la ligne '1 CHAR' a été effacée, ou bien - ce qui donne le même
résultat - remplacée par '1 CHAR UTF-8'. Avec cette base, les accents
n'apparaissent pas dans le browse, mais 'ps-anc.ll' les donne bien dans
ses sorties .ps
A ce stade, je ne sais pas comment procéder pour obtenir mieux, avec une
seule base.
Comment as tu fait pour obtenir, dans 'u', 'c', 'g' (affichage vers
interne) :
1 passage: iconv(CP850,UTF-8) ?
Il est vrai que tu es sous 'MSWIN' et moi sous 'Debian Lenny'. Tout ce
que je puis faire en éditant ces lignes, c'est d'ajouter des caractères
ou des codes ASCII ou HEx pour les transformer ; si je mets autre chose,
par exemple un 'iconv(ISO-8859-1,UTF8)' (ou l'inverse), à la sauvegarde
çà me donne une erreur, précisant que je ne peux mettre que des
'statements' séparés par TAB.
J'ai bien essayé des échanges de caractères. Par exemple :
C #195#169
est bien accepté et, çà va faire que tous les 'C' vont être transformés à
l'affichage par des 'é', y compris ceux du menu. Mais si je mets :
#195#169 é
çà ne donne rien, car il n'est apparemment trouvé aucun 'é' dans la base
interne. A l'affichage du browse, tous les caractères accentués
apparaissent comme un espace, un seul espace, et c'est toujours pareil,
qu'il s'agisse de 'é', 'è', ê, 'ç' ou autre. Pourtant, le système sait
bien où aller chercher les vrais accents lorsqu'il s'agit de générer un
fichier ps avec 'ps-anc.ll'. Les espaces qui apparaissent à l'écran du
browse pour remplacer les caractères accentués, analysés après copié
collé dans un fichier texte, se révèlent être des CHR(32) (espace), rien
d'autre.
J'ai fait de nombreux tests de modification de mon .linesrc, mais sans
résultat concluant. Au fait, en voici une copie ci-après :
http://www.teaser.fr/~bdebreil/pointlinesrc
L'an dernier, lorsque j'avais eu un problème avec 'indiseq', j'avais posé
des questions sur la liste des développeurs de Lifelines. Perry et/ou Tom
m'avaient envoyé un patch qui avait résolu mon problème. Mais, lorsque
j'ai posé des questions concernant les codesets, ils m'ont dit qu'ils ne
se sentaient pas trop compétents en cette matière, et que les
implantations qui étaient faites étaient expérimentales.
Bernard
> Le Tue, 08 Dec 2009 17:43:07 +0100, Patrick Texier a écrit :
>
>> Le 06 Dec 2009 23:48:43 GMT, Bernard a écrit :
>>
>
> J'ai bien essayé des échanges de caractères. Par exemple :
>
> C #195#169
>
> est bien accepté et, çà va faire que tous les 'C' vont être transformés
> à l'affichage par des 'é', y compris ceux du menu. Mais si je mets :
>
> #195#169 é
>
> çà ne donne rien, car il n'est apparemment trouvé aucun 'é' dans la base
> interne.
Je viens de trouver une solution !
Dans la base LL, les caractères accentués ne sont importés sous forme
d'une séquence de caractères (ex. #195#169 pour 'é') que si l'import se
fait en ISO-8859-1. Si l'import se fait en UTF-8, comme il se doit si
l'on veut pouvoir utiliser les LL reports sans souci pour
l'interprétation des caractères dans les sorties, les caractères
accentués sont importés sous forme d'un seul caractère. Quel est son code
ASCII ? C'est 'OpenOffice' qui m'a permis de le trouver : "insérer",
"caractères spéciaux". Le concepteur a eu la bonne idée d'afficher le
code ASCII. Voici ce que j'ai donc trouvé :
é=char233
ê=char234
etc. (voir plus bas)
Alors j'ai ré-essayé avec ces codes dans Lifelines, sur une base importée
en UTF-8 (caractères accentués non interprétés au browse) :
't' (Modify character translation table)
'd' (Internal to Display)
et là, après 'i' pour 'insert' (si éditeur = vi), j'écris le fichier
suivant :
#233 é
#234 ê
#235 è
#224 à
#226 â
#238 î
#231 ç
#249 ù
#251 û
#244 ô
(pour chaque ligne:code ASCII précédé par '#' sans espace [TAB] caractère)
Et çà fonctionne ! Avec ce système, les bases sont importées en UTF-8 à
partir de gedcom (ou créées par saisies en mode UTF-8 pour les NewDb), au
browse les données s'affichent avec les caractères accentués, et
l'utilisation des LL reports (même ps-anc.ll) donne des sorties sans
problème de caractères.
Inconvénient : pour chaque nouvelle base saisie ou importée, il faut re-
saisir les 7 lignes de correspondance ('t','d')
Peut-être peut-on mettre cela dans le fichier de config ? A ce stade je
n'ai pas trouvé comment faire.
Patrick Texier
> Peut-�tre peut-on mettre cela dans le fichier de config ? A ce stade je
> n'ai pas trouv� comment faire.
Je vais r�pondre plus en d�tail plus tard. Normalement, on n'utilise
plus les tables de caract�res.
Les sorties PostScript et PDFLatex, doivent se faire en ISO-8859-1. Il
faut mettre
ReportCodeset=ISO-8859-1
Je suppose que tu parles de vi, c'est Vim. Le vrai vi issu des sources
Unix pass� dans le domaine public vers 2002 est aussi compatible UTF-8
avec les modifs de Gritter <http://ex-vi.sourceforge.net/>. Ce programme
est indispensable si on travaille sur d'autres Unix, tellement Vim est
am�lior� par rapport � Vi : set compatible ne sert qu'� adopter un
comportement vi mais ne bloque aucunement les am�liorations, dans un
vrai vi, on ne se d�place pas dans le texte en mode insertion.