Skip to first unread message

Nicolas Souchon

unread,
Nov 22, 2023, 11:43:31 AM11/22/23
to AtoM Users
Dear all,

I work with EAD files in French (/profiledesc/langusage/language[@langcode="fre" and .="Français"]) but using lowercase English terms to describe levels of archival description.

Consequently, when importing XML files into AtoM, the terms used to define the description levels are created because they do not exist in French and removed during EAD export to be replaced by the Otherlevel level.

Is there a way to allow during import that the English terms used in the EAD are understood as being the equivalent of the French terms recorded in AtoM?

I thought about using the "Use for" field in the definition of terms but that doesn't seem to work.

Thank you in advance for your help.

Best regards,

Nicolas

Dan Gillean

unread,
Nov 29, 2023, 8:35:25 AM11/29/23
to ica-ato...@googlegroups.com
Nicolas, 

Sorry for the delay - I have been trying to get some of our developers to help look at your request (since I suspect that it may require development to change the current behavior), but it's a very busy period for us. 

In the meantime: have you tried adding French translations to the existing taxonomy terms for the levels of description? i.e. navigate to the Levels of description taxonomy, make sure the user interface is flipped to French, enter edit mode, and if there was not already a translation present at installation, then you should see the English terms presented above the edit field as references for your translation. 

If that doesn't work (and I suspect it probably won't, unfortunately), then I did poke around the code myself a bit and found this function, that seems to map the EAD level terms to AtoM's English levels of description: 
Notice in particular the $variations variable parameters on lines 391-395, as well as the fact that the culture it is explicitly checking against is set to en (English) in line 402. 

If you wanted to try modifying the code, this is where I would start. A solution that will work just for your particular needs might involve changing line 402 to fr (French), and replacing the mapped LOD terms in lines 392-395 with your default matching French level terms. 

A solution that might work for all and be something to contribute back to the public project would be more complex. I'm not a developer, but I suspect that line 402 would need to be replaced with something that would check the default installation culture of the application as a start. 

Anyway, hope this helps. Good luck!

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/ef7a104e-9370-4936-a70d-7a33a2e03ba5n%40googlegroups.com.
Message has been deleted

Nicolas Souchon

unread,
Dec 5, 2023, 4:07:20 AM12/5/23
to AtoM Users
Dear Dan,

Thanks for your answer.

The terms in our taxonomy are written in French and English. For each slug, there is a French term and an English term.

I tried to modify the  sfEadPlugin.class.php document as you suggested.

Changing the culture from "en" to "fr" and adding 'item' => array("pièce", piece"), to the $variations variable allows to export "Pièce" as "item".

But I didn't find how to link the imported levels of description to those in AtoM. When importing EAD files, no link is created between the EAD terms in the file and those existing in AtoM, so "item" is not linked to "Pièce" (slug "item") and "file" is not linked to "Dossier" (slug "file").

The aim would be for "item" in the imported EAD to be linked to "Pièce", the term to be displayed in AtoM, and exported as "item", the correct EAD term.

Thanks for your help,

Best regards,

Nicolas

Dan Gillean

unread,
Dec 5, 2023, 10:44:59 AM12/5/23
to ica-ato...@googlegroups.com
Hi Nicolas, 

One of our developers has pointed out the following in our YAML mapping document, which indicates which function is used for level of description mapping during EAD import: 
So according to this, we are using a function called setLevelOfDescriptionByName. We can then find that function defined here: 
Two observations about this block of code, which I think is what you will want to modify to achieve a proper mapping: 

First, Radda (the developer who assisted me in tracking this down) pointed out that on line 1785, we set the query to only look at the terms from a single culture - the current culture of the user / UI. He suggests that it's possible that commenting out that line may already achieve what you want. 

I also noticed that the beginning of the function adds some special rules to ensure that the "Record Group" level of description (used more commonly in the United States) gets special consideration, since it is used in the DACS templates. This block may also show you how you can add your own custom rules if attempting to modify the culture check fails. 

I hope this helps - good luck!

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.

Nicolas Souchon

unread,
Dec 10, 2023, 4:43:34 AM12/10/23
to AtoM Users
Dear Dan,

Thank you for your help.

Commenting the line 1785 in the QubitInformationObject.php file, as suggested, corrected the problem.

If I understand correctly, this allows AtoM to look in all languages to display or export the term in the language required (French for display in AtoM and English in EAD export)?

Best regards,

Nicolas

Dan Gillean

unread,
Dec 11, 2023, 9:44:07 AM12/11/23
to ica-ato...@googlegroups.com
Great! Glad to hear it, Nicolas. 

From what our developer told me, yes - commenting out this line will allow checks across all currently available and indexed languages. I am guessing now, but I suspect part of the reason we apply this is to avoid cases where the term is identical in multiple languages - in which case, I am not sure what AtoM would do (likely either throw an error, or just add the term to the first culture it finds with a matching term, which would be rather unpredictable). Dealing with that properly would require more analysis, testing, and development. 

For now, I am glad we were able to identify a modification that will work for your needs!

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.
Reply all
Reply to author
Forward
0 new messages