I’m importing into TB an excel sheet exported from our IT system. It has a number of columns with various fields (each row is a person, so we have names, company, etc…). The system is in French so I have, for example, the field “Prénom”, which can be populated by “René”.
When I copy/paste the Excel data into TB, the field becomes an attribute, as expected, and - for this particular note - gets populated with the expected value.
BUT : the attribute name is “Pr__nom”, and the value is “René”
Accents get correctly pulled over for the actual data, but not for the attribute names.
Which means I have to have an agent that pulls the value of “Pr__nom” into a new attribute called “Prénom” every time I import data … Which is not optimal, as I’d like to be able to pull in data with minimal fuss …
I can reproduce this with Excel and Numbers. However, this is a case where it would probably be best to send a sample Excel file to Eastgate so they can evaluate the issue while working with actual data.
The é is not a valid character for an attribute name (at present anyway). In addition to the A-Z, a-z, 0-9 character range cited, the underscore also got added in order to facilitate importing from databases where older systems often use underscores in field/column names (I need to update the aTbRef page). So, the ‘error’ is in fact correct behaviour as currently implemented, except that I just did a test and managed to make this attribute, $My_Tèst:
So although not formally supported in documentation (the app’s Help doesn’t cover this subject and my aTbRef notes are gleaned from ongoing release notes and beta testing), it appears Tinderbox may support a wider character set for attribute names. But, as the Excel data import shows, not all part of the attribute-handling code support the wider character set.
Thus, it seems you could make an attribute $Prénom via the Document Inspector and then import. Not tested but the import might then match. However, the issue is whether/where such an attribute name might not work within the guts of the app if the accented characters aren’t supported.
Edit:
On further checking in v5 RNs, underscore support was added (or improved) in v4.6.3 ($seq 1773). The underscore was primarily envisaged as a fix for (then) newly added spreadsheet table import.
I tested this earlier. It is possible to create a user attribute $Prénom, and it will appear and be used in the KA list, but a spreadsheet or CSV with a column header Prénom has that column’s values imported to an attribute $Pr__nom that Tinderbox creates on the fly.
It would seem that for localization purposes (if not common sense) that the limitations @mwra describe - which I don’t doubt - should be addressed in some future version.
I’ve just updated my aTbRef page on attribute naming to reflect underscore usage. I’ve not included accented characters as allowed pending clarification of the current design intent (which I’ve raised elsewhere).
I can confirm that I can make $Prénom, $Société etc as attributes. And in fact I do as part of the import/clean up set of agents I’m using currently.
I’m fine with my current setting, and I’m sure once design intent is clarified aTbRef will be very clear on how it all works. I’ll revert back to non-accented attributes if something breaks …
