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.