batch import (CSV file) descriptions in another language

[André D'Ulisse]

Bonjour!

Is it possible to batch import (CSV file) descriptions in another language? For example, 5 descriptions (whatever the description level) have been described in English and I would like to batch import the same 5 descriptions but in French: is this possible?

Merci d’avance!

André

[Dan Gillean]

Hi André, 

The short answer is: yes! But there are some quirks to be aware of, so I will provide further details below. 

During an import, it is the culture column that determines the source language of the description you are importing. See the second half of this section:

• https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#standards-related-fields
  

In the future, it is easy to do this in one initial import while creating the original English descriptions, if you'd like - you can include both a source / original language row, and one or more translation rows for the same records, if: 

1. The related rows immediately follow each other in the CSV
2. The related rows share the identical legacyId value, and
3. The related rows have different culture values

There are also some more factors to be aware of when importing translations. For example: do not try to translate related entities that might be linked to your description via import - you will need to translate those at their source. This means any fields that are related to authority records, terms, accessions, etc. Terms are the biggest ones - essentially, if it is a drop-down field with controlled values in AtoM's edit page, then that means the controlled values are likely terms in a taxonomy. To translate those, you would go to the relevant taxonomy, flip the user interface to the desired language, enter edit mode, and add or modify the translations for that language directly. 

So, examples of columns that you would NOT want add translations for in a description translation row include: 

• levelOfDescription
• repository
• eventActors, eventActorHistories, etc - any event columns that are stored on the related authority record (or are untranslatable, like the controlled fields for eventStartDates and eventEndDates)
• nameAccessPoints
• subjectAccessPoints
• placeAccesPoints
• genreAccessPoints
• levelOfDetail and related controlled fields found in the Control area
• etc

Instead, if you go to these entities and translate them directly in AtoM (e.g. go to the related creator record, flip the user interface to French, enter edit mode, add your translated authorized form of name and other fields, save), then when you view the related description in French, the creator's name will also be displayed in French. 

Fore more details on working with translations in CSV imports, see:

• https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#importing-translations
  

There's also a list of what fields can and can't be updated via CSV import, here: 

• https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#update-existing-descriptions-via-csv-import

Now, as for your question about importing translations later, to update existing records. 

It is possible, but currently AtoM's update import functionality is not very intuitive or user friendly, so I am going to suggest a workflow that I think will work best. First, if you want to know the context for why the import update matching logic is the way it is, you can read some previous summaries I've added to the forum here: 

• https://groups.google.com/g/ica-atom-users/c/HMoN4tEuJ10/m/n4e1gqftBQAJ
• Similar info, but another version: https://groups.google.com/g/ica-atom-users/c/bCWYFIkLCRs/m/7QTPfLnQAQAJ
  

The TL;DR is: the current matching logic is not very intuitive and doesn't always work great when trying to update records in the same system. Consequently, I am going to suggest that you perform your import via the command-line, using the --roundtrip option available on the CSV import command-line task. When this option is used, the default matching logic is ignored - instead, AtoM looks only for an EXACT match on the legacyId value of a row in the CSV, and tries to match it against the database object IDs. 

On export, AtoM populates the legacyId column of a CSV with the database object ID. Therefore, to ensure that the matching works well, the suggested workflow for importing French translations to existing records would be: 

1. Find the records you want to translate in AtoM, and export them. You can do this by finding them in the UI and exporting via the clipboard, bulk exporting from the command-line and deleting any rows you don't need, or however you want. Just be sure to export from AtoM - you might still have the original English CSV you bulk imported, but we NEED an export to ensure that the legacyId values are not the ones you made up for the initial import, but the database object Ids for those records in AtoM now. 
2. Once you have the CSV with only the records you want to translate, follow the documentation's guidelines for importing translations - that is to say, for each English row you want to translate: 
• Add a new blank row directly beneath it
• Add the exact same legacyId value as the English row above
• Add fr (the ISO 639-1 two-letter language code for French) to the culture column
• Following the docs, add whatever translations you want to the other columns that can be translated
3. Repeat as needed, until all English rows have French translations directly following them in the CSV
4. Save the CSV, and place it on your AtoM server (e.g. even just at the root installation directory, typically at /usr/share/nginx/atom)
5. Consider making a database backup! Just in case things don't work out as expected, and you want to roll back 
6. Use the command-line CSV import task with the following options, but with the proper path and name for your CSV: 

• php symfony csv:import --update='match-and-update' --roundtrip --skip-unmatched --index /usr/share/nginx/atom/my-french-translations

But replacing /usr/share/nginx/atom/my-french-translations with the actual path and name of your import CSV

After this you will want to run a few maintenance tasks to build the nested set, clear the cache, and restart PHP-FPM. Assuming you are using PHP 7.4: 

• php symfony propel:build-nested-set
• php symfony cc
• sudo systemctl restart php7.4-fpm

Further links and details about these commands can be found on the Troubleshooting page. 

If the import appears to have succeeded but the new translations are not visible in AtoM, then the --index option of that task may not have worked as expected, and you may need to manually reindex your site: 

• php symfony search:populate
• See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/populate-search-index/

Let us know how it goes! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/57c501cf-7431-47a4-aade-513dea15bc0fn%40googlegroups.com.

[André D'Ulisse]

Hi Dan,

Thank you so much for all this detailed and accurate information: I'll be reading it with great interest!

Je vous donnerai des nouvelles bientôt.

Have a very good day!

André

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BpU8%2Bz7%2BRu9gJb9tPxc-D2cMruAFDb7Ar%2BZkCU1HU0cA%40mail.gmail.com.