Skip to first unread message
Markus Hemprich
Oct 28, 2021, 2:47:37 PM10/28/21
to AtoM Users
Hello AtoM users,
in my (vagrant) installation, it seems that finding aids are always generated in English and are not translated to the selected language.
From the command line feedback, I recognized that an EAD-xml file is generated first; afterwards, the xml file is tranferred to the output with xsl-transformation.
Is there a possibility to translate finding aids, which I have not found?
Keep archiving,
Markus
Dan Gillean
Oct 28, 2021, 4:53:23 PM10/28/21
to ICA-AtoM Users
Hi Markus,
Good question!
In terms of the content of the finding aid itself, I did a bit of testing on the current behavior. In the public demo site, where the default installation culture is set to English:
- Adding French translations to an existing English description led to English being in the finding aid
- Creating a new French description (i.e. flip the UI to French then create) and then generating led to the French being used in the Finding aid. Unsurprising since there is no English content available at this point
- Adding English translations to my French-first description and then generating a finding aid used the English content in the finding aid - regardless of what language the user interface was set to when I began the finding aid generation
From this, my theory is that the installation culture will determine what language is used when a finding aid is generated. I have not yet tested what would happen if there were multiple translations and none that matched the installation culture (e.g. create the source record in French in an English installation, then add Spanish translations), but I suspect the source culture (in my example, French) would be used. There's a small chance that the whole thing is hardcoded to favor English when it is available (since the XSLTs are in English), but I'm hoping the original developers didn't go that route in an international application, and I would consider it a bug if English were favored over installation culture and description source culture.
Interestingly, when I use the French UI and click the EAD export button for my description created in French but with English translations, the French is used in the resulting XML. Meaning - I *think* there is something in the finding aid generation code that is favoring the English (or the default installation culture), rather than the issue being with the EAD export.
So: likely more tests to do and possibly some bug tickets to file, but as a simple workaround - if you wanted your finding aids in French (or whatever over language) and have a record that will be described in both French and English, then I would suggest:
- Flip the user interface to French, and create the French descriptions first
- Generate the finding aid
- Then you can add your English translations
At present, AtoM doesn't have the ability to have multiple XSLTs for different languages, nor does it currently support the ability to generate multiple finding aids per archival unit. EAD 2002 doesn't really have a mechanism to contain translations in a single XML file that I'm aware of either - there is a @langcode attribute used in the XML header to indicate the language of the finding aid (aka the EAD), not all elements can be repeated, and not all elements have their own @language attribute that might allow for say, two scope and contents where one is in English and the other French. All this to say, a single multilingual finding aid is probably not an option right now either, unless we stopped using XSLTs to generate the finding aid and pulled from the database instead.
In terms of the labels used in the finding aid itself, AtoM currently only has English XSL files. However, it is possible to create your own versions and replace the existing XSLs. Les Archives de Montreal created French XSLTs and has shared them with the community - you can find them, as well as basic instructions on how to swap XSLT files, on our wiki here:
All told, probably not the answers you were wanting, but I hope at least they were informative.
Cheers,
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/e9535e98-706a-4c87-ab49-7060ce92e253n%40googlegroups.com.
Markus Hemprich
Oct 30, 2021, 7:35:17 AM10/30/21
to AtoM Users
Hi Dan,
thanks for the very detailed feeback.
What I have tested is to change the xsl file. First I loaded one of the current xsl files from the following folder: lib/task/pdf/ead-pdf-inventory-summary.xsl
Then I patched some of the phrases and loaded the changed xsl file back to atom.
Afterwards, the new phrases showed up in generated finding aids. This seems to work.
However, I was not able to change the content generated by atom into the ead (or xml) file. I tried to set up a test archive and archival descriptions in German and in French and generated a finding aid. The result was always that the content was generated in English, e.g. on the first page of the finding book it said: "Language of description: English".
You mentioned the "installation culture". Do you mean the culture while creating an archive or an archival description? Or do you mean the culture while installing AtoM itself? Is there a possibility to change that? Or in the settings after installation?
Thanks again
Markus
Dan Gillean
Nov 1, 2021, 9:27:16 AM11/1/21
to ICA-AtoM Users
Hi Markus,
It can be confusing trying to talk through language and culture in a multilingual application like AtoM - I try to use the terms like so:
- installation culture: the language used when installing AtoM
- source culture: the language used in the user interface when creating a description, or in the culture column when using CSV import
- translation culture: any additional language translation added to the original source culture record
In terms of changing the default installation culture: yes, this can be done post-installation. It is stored in a configuration file - specifically, in apps/qubit/config/settings.yml. You can edit this with a text editor from the command line (e.g. nano app/qubit/config/settings.yml) to change the two-letter ISO 639-1 language code used as the installation culture. If you change this value, you will need to:
- Clear the application cache: php symfony cc
- Restart PHP-FPM: In version 2.6, this is sudo systemctl restart php7.2-fpm
- Re-index your content: php symfony search:populate
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4ea47c09-bb21-4a92-a0e9-cc226e996118n%40googlegroups.com.
Markus Hemprich
Nov 1, 2021, 2:29:11 PM11/1/21
to AtoM Users
Hi Dan,
thanks for the further hints. With the provided information, I was able to sucessfully change the installation language.
Regarding the finding aids, there seem to be several sources with different aspects of language management:
- Labels from the xsl file
- Labels from the EAD xml file
- Labels from general EAD tags (e.g. ead:unittitle, ead:unitid, ead:physdesc, )
1.) can be managed by translating the relevant parts of the xsl file. This works fine. As you have already explained, there is no standard mechanism to switch between xsl files. Therefore, one has to decide for a certain xsl file and load it to the directory. This is not a good solution, but it works.
For 2.), it seems that the language in the frontend is chosen at the time when xml-files or finding aids are generated. As an example, the "publication status" is generated into the xml file (e.g. French "Publié") and then used in the finding aid.
Snippet from EAD xml:
<odd type="publicationStatus">
<p>Publié</p>
</odd>
For 3), it seems that there is no translation regardless of the installation language, the frontend language, and the archival record. It seems that some default English labels are taken for the finding aid.
Do You have any hints, if an translation of the mentioned EAD tags of 3.) is possible. In the translations at https://translations.artefactual.com/projects/atom/27/, I could not find the labels.
Best regards,
Markus
Dan Gillean
Nov 2, 2021, 9:17:29 AM11/2/21
to ICA-AtoM Users
Hi Markus,
EAD is a standard that was created using English, so as far as I'm aware there are no translations of the elements themselves.
There are many fields in AtoM, particularly in the Canadian RAD template, that did not have 1:1 mappings in EAD. For these, we have used the general catchall tag in EAD of <odd> - i.e. other descriptive data - and defined our own type values for these fields.
In the case of the publication status example you provided, a term translation came through because your AtoM instance included a translation for the default "Published" term - so one way to get more translation coverage in your finding aids will be to ensure that all taxonomy terms used in your descriptions have translations added.
If I recall correctly, there are also some cases where the type attribute values are used as labels in the finding aids for some of these elements without clear 1:1 mappings in EAD 2002. These could be changed by an experienced developer, but you would need to modify all the code in AtoM that generates the EAD to use different labels. It's beyond the level of support we can offer here on the forum, but if this is something you want to investigate, I would recommend starting by looking at the files in the sfEadPlugin:
Regards,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ec7ea5d2-c505-4b98-98fa-79c2ae6b6069n%40googlegroups.com.
Markus Hemprich
Nov 9, 2021, 12:25:12 AM11/9/21
to AtoM Users
Hi Dan,
thank You for the further detailed explanation. With further work on the xsl file and a deeper check of the taxonomy terms translation, I manage to get a translation coverage of 70-80%. Like mentioned by you, further improvement will need a deep dive into the code and xslt transformation, which is beyond my possibilities.
I think I will change my approach. In AtoM, I will keep the finding in English. After exporting, I will run a short Visual Basic program in WORD (based on RTF export) and translate the finding aid. This seems to work and is achievable with less effort.
Thanks again for the great support and the provided insight!
Markus
Reply all
Reply to author
Forward
0 new messages