You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if our automapping function could read column names more broadly.
Perhaps CSV Import could read "Title|comment comment comment" as "Title" to maintain automapping convenience while allowing users to use column names as a reference for further modifying.
Alternatively, we could allow users to flag the second row of the spreadsheet as comments that get displayed in the mapping table.
A third option would be to offer batch-mapping in the table alongside batch-options. Then, if automap doesn't work because you have a bunch of columns with similar names that need to be set up differently, you can still get them mapped efficiently.
In this specific instance, I suggested "dcterms:title.en" might map the dcterms:title part and the language could then be set manually. It would be great if we could create our own syntax to do things like language, data type, privacy, etc. but that's probably a lot to ask.
The text was updated successfully, but these errors were encountered:
Re: https://forum.omeka.org/t/import-of-multilingual-text/20006
It would be nice if our automapping function could read column names more broadly.
Perhaps CSV Import could read "Title|comment comment comment" as "Title" to maintain automapping convenience while allowing users to use column names as a reference for further modifying.
Alternatively, we could allow users to flag the second row of the spreadsheet as comments that get displayed in the mapping table.
A third option would be to offer batch-mapping in the table alongside batch-options. Then, if automap doesn't work because you have a bunch of columns with similar names that need to be set up differently, you can still get them mapped efficiently.
In this specific instance, I suggested "dcterms:title.en" might map the dcterms:title part and the language could then be set manually. It would be great if we could create our own syntax to do things like language, data type, privacy, etc. but that's probably a lot to ask.
The text was updated successfully, but these errors were encountered: