CSV Export

[cassi...@gmail.com]

Hi everyone

We recently upgraded AtoM from version 2.6.4 to 2.7.3. Since then, the CSV exports of Dublin Core records have many empty fields and the culture is "en" and not our default culture (pt_BR). 

Columns like "Title", "extentAndMedium", "scopeAndContent" and "Coverage" are blank. The "culture" column have the value "en", but the default culture is "pt_BR". Before the upgrade, the CSV exports had the value "pt_BR" at the "culture" column.

Is this an AtoM setting that we are missing? How can I export a CSV with all the record's information?

Cheers

[Dan Gillean]

Hi there, 

Without knowing more, it sounds to me like perhaps pt_BR was set as the default installation culture in your old site, but perhaps you forgot to set this in the new one (in which case, it would default to en)? You can check and change this in the apps/qubit/config/settings.yml configuration file. See: 

• https://www.accesstomemory.org/docs/2.7/user-manual/administer/default-language/
  
• https://www.accesstomemory.org/docs/2.7/admin-manual/customization/config-files/#apps-qubit-config-settings-yml
  

You will need to clear the application cache, restart PHP-FPM, and repopulate the search index after making this change: 

• php symfony cc
• sudo systemctl restart php7.4-fpm
• php symfony search:populate

Hopefully that will resolve the issue. Otherwise - did you use the local translation bar to add custom local user interface translations in your AtoM instance prior to upgrading? If yes, then... you will need to manually redo all those translations. Unfortunately, AtoM does not currently have any way of preserving local translations done via the translation bar. The best way to ensure translations are preserved is to add translations via Weblate, since these translations are shared with the community and included in each release. See: 

• https://wiki.accesstomemory.org/Resources/Translation
  

Otherwise, making local translations for content should help - for example, any English terms in taxonomies that are coming out blank. You can go to the related term, make sure the user interface culture is set to Brazilian Portuguese (i.e. make sure that you have added pt_BR in Admin > Settings > i18n languages, and then reindexed - and then use the language menu to flip to Brazilian Portuguese), and then enter edit mode. If there is not already a Brazilian Portuguese translation for the English term, then the English term should appear in a yellow box above the edit field - add your translation into the edit field below, and save. Repeat as needed. See: 

• https://www.accesstomemory.org/docs/2.7/user-manual/translate/translate-content/
  

More broadly, AtoM definitely has some problems with exporting non-English content - see for example this issue ticket: 

• https://projects.artefactual.com/issues/12155
  

However, I don't know of any major changes between 2.6 and 2.7 that should affect the export of non-English content, so hopefully this is something that the suggestions above will help resolve. 

Cheers, 

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/9f385fd0-fd7d-4751-9f60-6b64d0a81762n%40googlegroups.com.

[Cássio Pires]

Hi, Dan

I already followed those steps related to the settings.yml . The default culture is pt_BR . 

It seems to be a very similar issue to this one that you indicated (https://projects.artefactual.com/issues/12155), except the language is pt_BR instead of FR: "Issue 3: No way to export records that are not created in the same culture as the default install culture from the user interface [...] For a description created in the FR interface, the only user-added values populated on export are the identifier, and any controlled values that exist in English. All other metadata is excluded from the export, regardless of the language of the interface at the time of export".

However, before the database migration and upgrade from 2.6.4 to 2.7.3 this issue did not happen. Is there a way to work around the issue to get the information into a CSV file, even if it is not in ISAD columns? From the CLI, is it possible to set the "culture" of the CSV export?

Thank you.

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/fGxy1xMzSE8/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAC1FhZ%2BnjohBJx%2Bx9x4iPPGarJT9v6Og63LM%3D7ZgXJCNqX9Gjg%40mail.gmail.com.

--

Cássio de Oliveira Pires.

[Dan Gillean]

Hi Cássio, 

I'm really sorry to hear that this issue is affecting you. I am not sure what has changed between 2.6 and 2.7, but I will bring this thread and the related issue ticket to the Maintainers, so hopefully they can give it some further investigation and improvement for the next release. 

In the meantime: if you run a full CSV export from the command-line, it SHOULD include all data, both en and pt_BR. Let us know if that helps!

Regards, 

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAA4CbwKR56rivSfrC7%3DHsQ5xhv6J-R4AWEvAUuy_eQw7Y0e_SQ%40mail.gmail.com.

[Cássio Pires]

Dan

Exporting from the CLI works and the "culture" is correct. I've used just the "--single-slug" option.

Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLFWB1qHuwy-Mg1T8wTLoEWFB2wxUbuKCu0s6%2Bmre2YpA%40mail.gmail.com.