Grazie a tutti!
Ho risolto il problema partendo dal file CSV esportato da TB. Sono andato infatti nella rubrica personale (vuota), ho creato un contatto (molto velocemente scrivendo "Io" nel campo nome) e poi ho esportato la rubrica. Ho provveduto quindi ad aprirla in Calc e lì ho incollato le varie colonne di dati, anche la colonna AK (quella delle note che TB visualizza per ultima) in cui avevo qualcosa da immettere.
Il problema è che partendo dal file CSV di libero.it, simile a TB per quel che riguarda la successione dei campi (perlomeno fino ad un certo punto), il campo delle note viene messo anche da libero per ultimo, ma alla colonna AU e non AK come invece fa TB. Che significa questo? Significa che i campi da AK ad AU vengono ignorati da TB nella procedura di importazione perché TB ha un numero di campi più limitato (rispetto ai campi riportati nel file CSV di libero.it, di outlook.com e, credo di poter affermare, di molti altri provider, se non tutti).
Questo spiega il fatto che importando la rubrica da outlook.com non vengono visualizzati nella colonna di destra (vedasi le immagini che ho caricato sopra) i record relativi agli indirizzi e-mail. Nel file CSV di outlook.com infatti gli indirizzi e-mail vengono riportati verso la fine (e comunque dopo la colonna AK, l'ultima ammessa da TB). Questo obbliga a mettere mano al file CSV, copiando la colonna (o, meglio, le colonne) degli indirizzi e-mail (che si trova nel file csv di outlook.com) nel relativo campo all'interno del file CSV di TB.
Per carità, 37 campi di TB (se non ho contato male) sono parecchi e non credo che ci sia qualcuno che li sfrutti tutti ma tale limite pone dei problemi proprio in fase di importazione (come ho spiegato sopra): dopo il 37°, chi è fuori è fuori, chi è dentro è dentro!
Il campo Note dal file csv di libero.it è fuori, addirittura i campi degli indirizzi di posta elettronica dal file csv di outlook.com sono fuori. Ciò obbliga ad esportare un file CSV di TB e a metterci dentro tutto ciò che uno vuol metterci (come ho fatto io).
Se non ci fosse quel limite, si risparmierebbe tempo. Basterebbe infatti spostare su e giù i campi della rubrica per farli coincidere con i record da importare.
Boh, forse sono esagerati i vari provider che concepiscono rubriche chilometriche... in effetti, tanti campi non servono. E poi mi sembra di capire che non ci sia uno standard di rubrica a cui si rifanno tutti. Voglio dire, la successione dei primi campi è quasi sempre uguale ma quello che viene dopo non segue un ordine prestabilito.
Un'ultima osservazione. Il campo "Titolo" non viene riportato in TB. In genere, è il primissimo campo (e comunque prima di nome e cognome) e nei form a livello internazionale si riempie con Mr. Mrs. Prof. etc.
Credo che sarebbe utile avere un campo "Titolo" all'inizio, specie quando si hanno rubriche di centinaia di contatti. Spesso ci si può confondere tra diverse persone e il campo titolo aiuta a distinguere una persona dall'altra. Pensiamo a due persone con lo stesso cognome, ma una ingegnere e l'altra avvocato. Se ho centinaia di contatti e non ricordo chi tra quelle due è avvocato, il campo titolo mi torna utile. Mi torna utile anche quando in ambito lavorativo debbono essere contattate persone che hanno un titolo generico come quello di "Dottore".
Il campo "qualifica" nella sezione lavoro non risponde alle stesse esigenze, sia perché non si trova all'inizio ma nella sezione lavoro appunto, sia perché lì ci vedrei meglio l'inquadramento contrattuale (magazziniere, operaio, impiegato, quadro, dirigente o altri tipi). Non a caso, tale campo è seguito dai campi "reparto" e "organizzazione", che sono il naturale complemento della qualifica contrattuale.
Chissà se nella versione inglese di TB c'è il campo "title" all'inizio. Lo stesso file CSV di outlook.com lo prevede come primo, quindi a livello internazionale dovrebbe essere piuttosto comune avere questo campo per primo. E ho fatto caso che anche libero.it genera un file csv con il campo "titolo" per primo.
Non capisco come TB (perlomeno la versione italiana) non lo preveda, mettendo invece al suo posto "nome visualizzato". Questa anomalia andrebbe segnalata agli sviluppatori (se non è già stato fatto), in quanto non rispondente ai canoni internazionali.
Andrebbe segnalato, sempre se non è stato già fatto, anche il limite del numero dei campi importabili e l'esclusione di quelli che si trovano oltre tale limite. Si potrebbe inoltre suggerire di mettere a disposizione nel processo di importazione della rubrica un file csv da salvare in locale e da riempire a piacimento, come ho fatto io. Voglio dire, sarebbe preferibile che questa possibilità fosse prevista e illustrata come alternativa rispetto alle altre opzioni attivabili quando si deve importare una rubrica. Questo per facilitare il compito anche agli utenti meno esperti.
Topic: Difficoltà di importazione contatti con file .csv in Thunderbird 38.04 (Letto 14667 volte)