RCP: 0.7.2, Lexical table, export/import scenario, ergonomy

The export/import scenario is wrong and leads to misunderstanding.

Solution

Set 2 ways to import a lexical table :

• In a corpus : -> This creates a new table not linked to other results
  • in the main menu "File > Import > ‘Import lexical table…"
  • in corpus view menu : Import > ‘Import lexical table…’
  • in the main toolbar in the statistical commands area (AFC, etc.)
• In an existing lexical table : (the reverse icon of the export data command) this updates the table and keep a certain logical hierarchy between results
  • in the main menu : "File > Import > Data..."
  • in the corpus view menu : Import > ‘Data…’
  • in the main toolbar "Import Data..." before ‘Send to R’ to the Corpus object contextual menu (and toolbar and main menu)
  • in the contextual menu of the lexical table editor "Import Data..."

External format : table format (XLSX, ODS, CSV, TSV)

• the file format is R TSV, English language (for floating point representation conventions)
• create a lexical table:
  • named from the file name
  • descendant of the corpus
  • with the columns and rows from the file content
  • R table encoding conventions:
    • first line encodes columns names
    • each following line, begins with its name C1 C2 C3 L1 11 12 13 L2 21 22 23 L3 31 32 33

Table format

• in external file

word	part1	part2	part3
A	1	2	3
B	2	3	4
C	3	4	5

• in TXM

(from redmine: issue id 228, created on 2013/07/09 by Matthieu Decorde)

Validation test

• Lexical table export/import
  • create a lexical table from VOEUX@texts
  • Export the lexical table content into a new spreadsheet file "test.ods" (Export > Data...)
  • change the content of the first cell of the first part (part1)
  • Import the lexical table data from the spreadsheet file "test.ods" into the lexical table (Import > Data...)
  • check that the value of the first cell has been updated
• Lexical table from external file
  • create a lexical table in VOEUX by importing its content from file "test.ods" (Import > Lexical table...)

added status::in progress type::bug ui + 1 deleted label

changed milestone to %TXM 0.X.X

• BP (2013-01-30) : L’export de la table lexicale ne semble pas prendre en compte les Préférences sur les séparateurs de texte et de champs.
  • MD (2013-07-08) : OK peut-être il y a confusion entre “l’export pour réimport” et l’export tout court. De toute façon cette interface va changer.

(from redmine: written on 2013/07/09 by Matthieu Decorde)

changed milestone to %TXM 0.8.4

changed the description

removed status::in progress label

added status::feedback label

changed the description

0.8.4 (2024-10-29 10h41), Ubuntu 20.04

• Compatibilité avec tables exportées pour sauvegarde dans une version antérieure de TXM : ça c'est top :-)
• Quand je sélectionne la table dans la vue corpus et que je veux exporter les données, la boîte de dialogue est tronquée à droite si bien que je n'arrive pas à choisir le répertoire ni à visualiser la fin de mon nom de fichier. Quand je lance la commande d'export par clic-droit dans les lignes de la table elle-même, là j'ai une interface différente et plus fonctionnelle.
• Cependant les données exportées ainsi ne semblent pas convenir au réimport : "LexicalTable data import : no column found in: /home/bpincemi/area/data/2024/projet/textometrie/2developpement/2recette/bureau/241024txm084alpha/benedicte/241029/data/nov13-221011_table_survivants_temoins112-sexe-age4_personne6.csv". De fait, la table qui s'importe bien a des colonnes séparées par des virgules, celle que je viens d'exporter pour sauvegarde dans TXM 084a a des tabulations (pas de virgules), tout en se déclarant .csv.
• Du coup je n'ai pas bien compris si un des buts du ticket était d'unifier l'export pour réutilisation en dehors de TXM et l'export pour sauvegarde et réimport -ce que je pensais être le plus crucial du point de vue ergonomique pour cette commande ?
• Ca pourrait être commode de mémoriser et représenter le chemin précédemment utilisé (vs. redéfinir à chaque fois le chemin complet).
• quand on importe des données dans une table existante, le nom du fichier n'est pas utilisé pour nommer la table dans l'onglet et la vue corpus.
• l'import fonctionne quand je lance la commande depuis la vue corpus mais pas quand je passe par le menu contextuel en cliquant dans une table lexicale existante (message de refus dans la console : "Import file format is not managed: '*.csv'.").

assigned to @mdecorde

il y avait un soucis sur le test de l'extension du fichier importé

il y avait des traitements différents en fonction de où était appelé l'export et l'import (il y a avait 2 chemins mémorisés aussi)

le séparateur de colonne des préférence n'était pas utilisé à l'import

0.8.4 (2024-11-12 07h05) Ubuntu 20.04

Rétrocompatibilité des tables sauvegardées : Pour importer la sauvegarde d'une table lexicale faite dans un TXM antérieur, le réglage par défaut de la préférence d'import sur séparateur de colonnes (tabulation) doit préalablement être modifié (remplacement par virgule), sinon l'import échoue ("LexicalTable data import : no column found in: /home/..."). Ce n'est pas évident à gérer, il faudra aider les utilisateurs pour la rétro-compatibilité de TXM avec leurs tables sauvegardées.

Une solution est de faire remonter des paramètres d'import dans la boite de dialogue d'import (même chose pour l'export).

closed

reopened

removed status::à tester label

added status::à préciser label

Dans l'état actuel des widgets d'import&export n'ont pas d'options (à part le nom du fichier et le format à utiliser). Si on veut faire évoluer ces widgets avec la possibilité d'avoir des options supplémentaires&différentes entre résultat, je propose plutôt de faire un nouveau ticket pour la prochaine version de TXM

Il me semble que le widget d'export de données de résultats a évolué et propose maintenant 3 paramètres :

• le dossier
• le nom du fichier
• le format (qui est plutôt un mélange entre un pattern de nom de fichier et une extension : genre "*.csv")

Une première idée pourrait déjà être d'utiliser ce widget pour l'export de table lexicale (à moins que ce soit déjà le cas ?).

Et comme l'export de données de résultats pourrait également bénéficier de paramètres 'séparateur de colonne' et 'séparateur de texte', on pourrait faire évoluer ce seul widget pour que l'export de table lexicale puisse en profiter dans la foulée.

Puis prévoir un développement symétrique pour l'import de table lexicale.

Oui, il faut faire cela plutôt dans une version suivante.

il y a un ticket qui regroupe un peu tout sur le sujet : #2163

Nouveau ticket pour l'ajout de paramètres en fonction du résultat et du format de sortie : #4107

changed the description

changed the description

TXM 0.8.4 (2024-12-10 10h06) Linux

1. L'interface est beaucoup plus fluide et plus riche (dommage qu'il n'y ai pas encore le format .XLSX, je l'ai ajouté au ticket).

2. J'ai ajouté un exemple de tableau pour expliciter le format du fichier externe et pour alimenter une recette plus complète.

3. Le message d'erreur quand le fichier .ods ne peut pas être exploité est un peu maigre :

LexicalTable data import : error.

-> Ce serait bien si on pouvait avoir un minimum de diagnostic sur ce qui se passe.

4. En lisant le message dans la console Ré-ouvrir le tableau lexical pour voir les modifications après avoir importé le contenu d'un tableau depuis un spreadsheet, on se rend compte qu'on doit réouvrir le tableau pour voir son contenu.

-> Pourquoi ne pas réouvrir le tableau lexical automatiquement ?

Nouveau ticket pour le format Excel : #4106 (closed)

Il y a ce message parce que je n'ai pas pu re-ouvrir l'éditeur sans avoir d'erreur

J'ai ajouté le détail de l'erreur (exception Java, faudra voir si ça suffit)

changed the description

marked this issue as related to #4106 (closed)

added status::à tester label and removed status::à préciser label

added status::à préciser label and removed status::à tester label

added status::à tester label and removed status::à préciser label

marked this issue as related to #4122

Nouveau test d'import direct dans TXM version: 0.8.4 (2025-01-21 07h06)

Une table lexicale est bien créée à partir d'un fichier .ods, mais l'éditeur de la TL n'est pas ouvert dans la foulée alors que la création d'une TL à partir d'une partition ouvre son éditeur dans la foulée, pourquoi ?

[j'ai l'impression que tu n'as pas répondu à mon commentaire précédent : "Pourquoi ne pas réouvrir le tableau lexical automatiquement ?"]

Remarque : je n'arrive pas à joindre mon fichier exemple TL-import.ods au ticket (refusé).

pour la fermeture de la TL puis la ré-ouverture de la TL importée, j'ai créé un ticket : #4122 les causes ne sont pas encore définies

foo.ods test glissé déposé depuis nautilus -> l'upload dans les commentaires semble cassé ou alors limité aux images

Il ne s'agit pas de "fermeture de la TL puis la ré-ouverture de la TL importée", il s'agit "d'import direct dans TXM" (pas de TL pré-existante).

Je reformule ma question du coup : "Pourquoi ne pas [ré]ouvrir [l'éditeur du] tableau lexical automatiquement [lors d'un d'import direct dans TXM] ?"

ah ok j'avais pas compris en effet, c'est bon pour l'ouverture de la table importée :D

closed

removed status::à tester label