Skip to first unread message

ritactc...@gmail.com

unread,
Dec 7, 2018, 12:30:39 PM12/7/18
to AtoM Users
Hey guy,

I have a big problem, because I do not understand something.
I have a instance AtoM 2.3 and I want to export to another AtoM using EAD export.
Ok.. I export EAD from AtoM 2.3 and the level of description be in english, but  in the interface still in Portuguese.
And when I import to my AtoM 2.4 import in english.

EXAMPLE:
AtoM 2.3:  Level of description: Fundo
EAD export AtoM 2.3:   <archdesc level="fonds" relatedencoding="ISAD(G)v2">

and when I import to my AtoM 2.4
Level of description: fonds

What can I do to make this right?
Thanks

Dan Gillean

unread,
Dec 7, 2018, 12:58:09 PM12/7/18
to ICA-AtoM Users
Hi Rita, 

The easiest way to solve this is to go into the Levels of description taxonomy in your 2.4 instance, and add a translation for the English "Fonds" level of description term. To do so: 
  • Navigate to Mange > Taxonomies
  • Find the Levels of description taxonomy
  • Find the term Fonds
  • Make sure the user interface is in the language you wish to use (e.g. Portuguese, French, Spanish, etc - use the Language menu to change the language of the user interface)
  • Enter edit mode
  • If there is no translation, then the English value should appear in a yellow box above the field - you can add your translation in the edit field and save. Here is an example of translating the English term "Record group":

term-translate.png

For more information, see: 
The other option is to simply edit the Fonds term directly, and change it to "Fundo," regardless of language. 

Any descriptions using this term will be automatically updated to reflected your changes, regardless of which of these methods you use. Adding a translation is the better option though, so try this first! 

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ef46853e-6416-4e11-9283-9c37003d4a76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rita Campos

unread,
Dec 10, 2018, 6:40:34 AM12/10/18
to ica-ato...@googlegroups.com
Thanks Dan! 
this help me, but this make me think... so, It´s not good CREATE a new  level od description?!
Cause I have a problem when I created and tried export.
EXPECTATION: <archdesc otherlevel="fundo" level="otherlevel" relatedencoding="ISAD(G)v2">    
REALITY:<archdesc otherlevel="" level="otherlevel" relatedencoding="ISAD(G)v2">  
 


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/wEnTEKaRUrQ/unsubscribe.
To unsubscribe from this group and all its topics, 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.

For more options, visit https://groups.google.com/d/optout.


--
Rita Campos
Analista e Desenvolvedora de Sistemas

Dan Gillean

unread,
Dec 10, 2018, 1:06:24 PM12/10/18
to ICA-AtoM Users
Hi Rita, 

I think that there may be a couple issues at play here. 

First, I noticed this bug, which is fixed in version 2.4.1: 
If you are not yet using version 2.4.1 then it is possible this bug is adding further complications. 

I have tested creating a new level called "View" in AtoM 2.5 in an English installation, and had no issues: 

<dsc type="combined">
  <c otherlevel="view" level="otherlevel">
   <did>
     <unittitle encodinganalog="3.1.2">View one of this object</unittitle>

I did however manage to recreate the issue you are seeing when using AtoM with a different default installation culture, or even just a different language in the user interface. It seems that currently the EAD level exports are hard-coded to use the English labels. If I add a new term to the levels of description in a language other than English and then export a description using that level, I am able to get the same result. For example: 

First I tried creating a new level using the French interface in my English-installation AtoM. That is, my default installation culture is English, but I flipped the user interface to French using the Language menu before making my new term. The resulting export showed the same issue you are seeing: 

<c otherlevel="" level="otherlevel">
  <did>
    <unittitle encodinganalog="3.1.2">Test en francais de sous-sous fonds</unittitle>

Next, I repeated the test, but FIRST I changed the default installation culture to fr for French in the apps/qubit/config/settings.yml configuration file. I restarted all services, repopulated the index, and cleared my browser cache. Then I repeated the steps, creating a new level of description. In the end, I hit the same issue. 

The easiest workaround for now is to navigate to your new level of description, flip the user inteface to English, and then add the term label again in the English translation field  - for example, if you want to see otherlevel="fundo" on export, then you can just add Fundo again in the English interface for your new term. 

I will file a bug for this, but first I need to work out what the ideal behavior should be. 

At first glance, it seems to me that: 
  • If AtoM's default installation culture is set to another language, then AtoM should use the other language terms in the "otherlevel" attribute whenever they are available
  • If a new term has been created and there is no English translation, AtoM should use the original term to populate the otherlevel, even if the default installation culture is English
However, the EAD 2002 standard was created primarily by English native speakers and has some English-language bias in it. For example, the EAD 2002 Tag Library specifically recommends controlled terms to be used in <c> levels, such as fonds, series, etc. 
So how to ensure that we remain as standards-compliant as possible? Is it better to say that: 
  • If AtoM's default installation culture is set to another language, use the default English term mappings in the EAD <c level'""> attributes, BUT ensure that the display language will show the proper language in the user interface on import. 
  • If a new term has been created and there is no English translation, AtoM should use the original term to populate the otherlevel, even if the default installation culture is English
  • If a new term has been created and there IS an English translation but the default installation culture is NOT English, then AtoM should use the original source term (i.e. the original non-English term) in the <c> @level attribute on export
???

Or something else???

I am quite familiar with EAD 2002 XML overall, but there are aspects such as this, about how to use it properly in a multilingual environment, for which there is little guidance and it is difficult to determine the ideal behavior. I would welcome thoughts and input from our community about this. 

Once we have determined exactly what the ideal behavior should be in various likely use cases, I can file a bug for this issue. In the meantime, I suggest you use the workaround I have suggested: add the label in the English interface as well. 

Cheers, 

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

Gomes Silva

unread,
Jan 4, 2019, 11:03:24 AM1/4/19
to AtoM Users
Hello,

Before importing EAD to AtoM, open the xml file with Notepad++ and replace fonds with fundo, series with série and so on. It will be a little tedious but it will work. With Notepad++ you can also do it with multiple files. The problem is that you will have to do it every time you export something, which also happens with CSV files, I believe.

I wish we could have a setting where we choose to view/export those standards-compliant elements in English or in the Default Culture that is being used.

I also wish we could generate authorities slugs based on Authority record identifier, just like description permalinks are generated on reference code. It would make the import/export task much easier (in fact it would become super easy especially in regard to relations between authorities and between authorities and objects).
Reply all
Reply to author
Forward
0 new messages