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.