Benjamin Janssens
Hello all,
I’m new to AtoM and the forum and I couldn't find an answer to my question. So I’m trying here.
I’m currently working on a master thesis over the ability of ArchivesSpace and AtoM software to deal with the known implementation problems of the EAD (in Belgium). It’s maybe a question a bit naïve. But is there a way in AtoM to modify easily the description of the titles (and the titles themselves) in the modules and to change their order (without going through the software code)?
For instance, the module for the creation of a new archival description refers to the ISAD(G) rules. I would like to delete them and to reorder the structure of the module in a way closer to some of my original finding aids. The actual descriptions and titles pose also a problem in terms of language because they are unilingual. However in Belgium we must have bilingual titles and descriptions (in French and Dutch).
Thank you in advance!
Benjamin
Dan Gillean
Inconsistently used. Because they are not standards-based fields and there is usually no strong guidelines about how to use the custom fields, the fields are used in different ways by different users. Often a custom field is introduced by one member of an institution, is only used by that member, and then its use is abandoned after that member leaves the institution.
Filled with inconsistent data. Once again, because there are usually no clear guidelines about what data should go in the field, custom fields often contain inconsistent types of data. This makes mapping the data to a new descriptive system very difficult.
Difficult to export. Adding a custom field for AtoM does not automatically add that field to the export templates (EAD XML, DC XML, MODS XML, CSV, etc) so unless custom development work is done to allow export of this custom data it is effectively trapped in AtoM. Depending on the nature of your custom field, there may be no good mapping to an existing metadata standard that will allow you to export your data in a way that could be recognized and imported into another system at a future date.
Difficult to maintain. Artefactual, and by extension the AtoM project, is committed to standards-based description and access - AtoM was originally developed with support from the International Council on Archives, and its goal was to make standards-based description and access more easily achievable by small and medium-sized institutions without the resources for a proprietary solution. We remain committed to this vision of the application, and will not be accepting custom modifications of templates in the public project. This means that it will be up to your institution to maintain your custom fields over time - meaning you will likely need to have developers available every time you want to upgrade the application to the newest public release, to resolve conflicts, fix bugs, and successfully re-merge your customizations into your local instance. Many institutions do not have the resources to support this level of ongoing maintenance, which can leave you stuck on a legacy version of the application.
We strongly believe that using open source software and descriptive standards are the best thing you can do for long term continuity of your institutional data. Your descriptive metadata represents a significant investment of time and effort on the part of your institution. We urge all our AtoM users to protect that investment by making sure you have a plan to get your data out of AtoM if necessary. We'd love you to use AtoM forever, but the reality is that your institution will probably outlast AtoM in its current form. :)
If you are mainly interested in relabelling and reordering (and perhaps hiding or removing some fields), it *may* be possible to do this via a custom theme plugin. At Artefactual we have successfully changed some of the view and edit template field labels this way. The advantage of this is that all the code to customize AtoM is kept in a separate plugin - making it easier to upgrade to newer versions and reapply your custom theme.- Don't forget that any field you don't populate won't show up on the view page of your descriptions. It might be inconvenient to have a bunch of edit fields you don't use, but I personally think this would be less inconvenient than having to maintain a custom fork of AtoM just to hide them!
- If you are trying to describe legacy descriptions for which you already have finding aids, one approach might be to provide minimal descriptions in AtoM and simply upload the existing finding aid directly. See: https://www.accesstomemory.org/docs/latest/user-manual/reports-printing/print-finding-aid/#generate-or-upload-a-finding-aid
From AtoM’s initial planning and development, one of the core project goals has always been multilingual support at all levels of the application. In AtoM, both user interface elements and user data can be translated into multiple languages - this international design is built right into the data model itself.
For user interface elements, Artefactual maintains an open source web-based translation platform (Weblate) and detailed documentation for our strong community of volunteer translators. Community translators supply translations, which are then reviewed by peers before being incorporated into subsequent public releases. Additionally, users can make local changes to the supplied translations via AtoM’s built-in translation bar.
For user metadata, the same standards-based templates can be used to supply translations. Users with sufficient permissions simply use the Language menu to change the interface to the selected translation language, and then enter edit mode on a record. The original language source string is then displayed for context above the related edit field, and translators add their content directly to the same edit forms, without altering the source strings. Here are some example screenshots:
Adding a translation for a menu item:
You can of course do the same with your descriptions. See: Translate content in our documentation for more information.
A couple further notes on this:
As you'll notice from the screenshots, you may need to translate terms that appear in drop-down menus in the templates separately. For example, the levels of description terms shown above appear in the Level of description drop-down in the ISAD(G) template - so you'll need to translate the terms directly in the source taxonomy (which you can find by going to Manage > Taxonomies). The same is true for menu elements!
Before you can translate locally, you need to make sure your language is added in AtoM. Navigate to Admin > Settings > i18n languages, and add your language via the autocomplete menu there. You will need to reindex the site after doing so. After that, your selected language will appear as an option in the global Language menu.
Finally, it's also possible to change the default installation culture of AtoM. You can do so by modifying one of the installation configuration files - see:
Dan Gillean, MAS, MLIS
--
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/7030ed2b-7e05-4ecc-9623-a4cc0edb38dd%40googlegroups.com.
Benjamin Janssens
Benjamin
Rachael Gilg
To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.
