Taxonomy Terms via API or CSV export

39 views
Skip to first unread message

Ad Axem

unread,
Jan 7, 2019, 8:46:49 AM1/7/19
to AtoM Users
Hi everyone and Happy New Year!

We have run across an issue while experimenting with the Browse Taxonomy Terms API endpoint as well as the Taxonomy Terms Export to CSV functionality for cultures other than English (Greek to be specific).

The observed behaviour is that, regardless of the sf_culture API parameter or the corresponding parameter of the csv:export-term-usage CSV command, all the Terms are returned in the English language only.

Are there any other available commands that actually return the Terms in their Greek translation, either via API or in a CSV export? Or are we doing something incorrectly?

Many thanks in advance for your help!

Dan Gillean

unread,
Jan 9, 2019, 10:55:38 AM1/9/19
to ICA-AtoM Users
Hi Efthimios, 

A couple of clarifications. First, there is no separate CSV export for AtoM terms at the moment - currently, SKOS RDF/XML is the only export option for terms. 

You can export an archival description CSV, and any linked terms should be included - however, there are known i18n issues with this, captured in the following ticket (which I think might have been filed following one of your previous posts?): 
We've also captured some suggestions for improvements in the following Wishlist ticket: 
These tickets will require some analysis for us to be able to implement, meaning we will require community support to be able to address them in a future release. 

As for the Taxonomy terms API endpoint, I have tested this in our qa/2.5.x environment using my local Vagrant box. I first added Greek as a UI language in Admin > Settings > i18n languages, re-indexed, and then I went to the Subjects taxonomy and added some Greek translations for existing English terms. I also added one term only in Greek (not a translation of an existing term - in the screenshot below, it is the one that says "GREEK ONLY" in English after the term, so I could identify it. I apologize for bad translations - I was using Google Translate just to test with some Greek terms!). Then I enabled the API, and tried querying the terms endpoint. 

I had no problem seeing my Greek only term, translated terms, or source English terms provided as a fallback where there were no Greek translations added in the browser: 

taxonomies-api.png

In the command-line using cURL, the special characters are not properly rendered (unicode or UTF-8 values are shown instead), but still appear to be correct (based on what the browser returned, at least):

taxonomies-api-curl.png

I looked up one of the codes and it does seem to be correct: 

u03bf.png

Additionally, when I searched the same thing on Google, I could see many other API endpoint responses that display Greek characters the same way when not rendered: 

u03bf-google.png
Is this what you were expecting to see? Have you entered the query's i18n parameter in the same way I have? 

If yes, I'm not sure why you are not seeing your terms in the selected culture using the API endpoint. It's possible that one of the bug fixes in the 2.4.1 release may have also resolved an issue in earlier releases, but we have no tickets in 2.4.1 or 2.5 that specifically address the API endpoint. My default installation culture is en, but I would be surprised if this is what was contributing to the difference in what we are seeing. 

Any further information that you can provide about your installation, how you are querying, etc. that might help us resolve this issue for you is welcome. 

Regards, 

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


--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4e9df919-886f-4aa9-a109-86577c919703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ad Axem

unread,
Jan 10, 2019, 5:26:41 AM1/10/19
to AtoM Users
Hi Dan,

Thank you very much for the clarifications!

It seems the REST client used for API testing wasn't passing the sf_culture parameter properly, but passing it according to your example syntax worked correctly (returns Greek translations and English fallback when Greek translations are not available).

Regarding the csv:export-term-usage command, I understand that it is not a CSV export for AtoM terms per se, but can still be used as a workaround for us, as we have already deleted all unused terms from that AtoM installation.

Isn't there any parameter for the csv:export-term-usage command to use the Greek versions of the terms for the CSV?

Dan Gillean

unread,
Jan 10, 2019, 11:04:18 AM1/10/19
to ICA-AtoM Users
Hi again Efthimios, 

I'm sorry, I misunderstood which export task you meant! I see now that you meant this one: 
It took me a while to figure it out, but it seems that right now, this task will **only** export terms in the language of the default installation culture. You should be able to export your terms, but you will need to temporarily change the default installation culture in apps/qubit/config/settings.yml, still use the --taxonomy-name-culture parameter, perform the export, and then change it back. 

Looking back at the history of the related ticket (#11082), it seems I raised this problem at the time (see for example comments 8-13 on the ticket). However, this task was being created to solve a particular need during a client data migration project, and there was no time budgeted to solve or improve the behavior for multilingual use cases. I meant to file a bug report so we could follow up later, as well as add a clarification in the docs, but it looks like I forgot - sorry!

I have filed a ticket now so that we can revisit this task in the future, and improve its behavior. See: 
I have also added this to an internal list of community-reported bugs for our team to try to address between client projects before the next release. This is not a guarantee that it will be addressed (as you know, we depend on community support to guarantee fixes and feature development), but we'll do what we can. 

In the meantime, here is a workaround that should help. Remember, following this method, only terms that are linked to descriptions will be exported, so make sure any terms you want to find in the export have Greek translations (or were created in the Greek interface), and are linked to at least one description. 

First, let's change the default installation culture of your application temporarily, to Greek. We can change this in apps/qubit/config/settings.yml: 
  • sudo nano apps/qubit/config/settings.yml
Once we've made this change, we need to restart PHP-FPM and memcached, clear the application cache, and re-index our site before continuing. Here are example commands for this in an Ubuntu 16.04 / PHP 7 installation: 
  • sudo systemctl restart php7.0-fpm
  • sudo systemctl restart memcached
  • php symfony cc
  • php symfony search:populate
Now we are ready to export! 

The command I used to export my Greek terms was: 
  • php symfony csv:export-term-usage --taxonomy-id="35" --taxonomy-name-culture="el" --taxonomy-name="Subjects" /vagrant/greek-subjects.csv
Note that if there was a Greek translation of the Subjects taxonomy in AtoM's fixture files, I would have to use that for the --taxonomy-name parameter (i.e. --taxonomy-name="Θέματα" for example). However, at this time there is not. 

With this command, I was able to see Greek translations of English terms, as well as terms created in the Greek interface, in my export. Where there were no translations, terms were displayed in their source culture (English): 

greek-terms.png

This is obviously not ideal, and very inconvenient for multilingual installations. Now that we have issue #12696 filed, I hope we can improve this in the future! In the meantime, I hope this workaround helps you. Let us know how it goes! 

Cheers, 

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

--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Ad Axem

unread,
Jan 14, 2019, 7:00:23 AM1/14/19
to AtoM Users
Hi Dan,

This is extremely helpful, thank you very much!
Reply all
Reply to author
Forward
0 new messages