[Archivesspace_Users_Group] language plugin implementation 2.7.1

Lora Woodford Lora.Woodford at lyrasis.org
Fri Sep 18 10:08:41 EDT 2020


Hi Ashley,

Wanted to follow up and see if you are still curious about this.  Yes, what you’re describing seems normal.  The database migration related to the new language/script of description fields in resource records was written to be very conservative in terms of deleting existing data from what was previously the free text “finding aid language” field.  Indeed, the software specification provided for the work (linked to from https://archivesspace.atlassian.net/browse/ANW-382) stated that: “REQ-6: The system shall migrate existing Language of Description content to the new Language of Description Note free-text note field during system migration.”  The only time it removed/cleaned up data as part of the migration is when language/script of description codes were already encoded in the body of that free text field.  So, for example, a pre-2.7.1 finding aid language field like:

Description is in <language langcode="eng" scriptcode="latn">English.</language>

Would become the following in 2.7.1+:

Description is in English.

with the appropriate enumeration values for English and Latin provided in the new finding_aid_language and finding_aid_script fields in 2.7.1.  The text, however, remains.

In your case, it sounds like you had the following in pre-2.7.1:

English

Which, post-migration, resulted in an identical string in the finding_aid_language_note:

English

Since no language CODE was provided, nothing was removed or altered and no enumeration_ids were added to finding_aid_language and finding_aid_script.  Since you then went along and ran the plugin to assign languages and scripts to your resource records, the default language and script codes that were added from the 2.7.1 migration (codes for unknown language/script) were updated to the selections you made in the plugin.  The note (as migrated during the 2.7.1 upgrade process) wouldn’t change from using the plugin.

My understanding is that keeping the former finding_aid_language content in the new finding_aid_language_note field is an intentional decision since it is the value of that finding_aid_language_note field that is exported into the <langusage> field in EAD 2002 exports.  (EAD3 exports are handled differently and details can be found int eh specification linked to in the ticket above).

If you did really want to wipe away all the “English” entries now in finding_aid_language_note that could be done directly in the database (after testing thoroughly on a non-production system first!), with a statement along the lines of:

UPDATE resource
SET
    finding_aid_language_note = REPLACE(finding_aid_language_note,
        'English',
        null)
WHERE
    finding_aid_language_note LIKE 'English';

Just be sure that you are comfortable with the fact that removing these notes will remove language information from your EAD 2002 exports (if you use them) since the mapping in the specification maps language of description note to <langusage>.

Happy to answer any additional questions.

Best,

Lora

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of "Knox, Ashley M." <knoxa at uncw.edu>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Tuesday, September 8, 2020 at 8:01 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] language plugin implementation 2.7.1

I’d like to clarify my earlier post. After migrating from 2.6.0 to 2.7.1, we saw the new ‘language of description note’ populated with a language, where it was not before the migration. We only had ‘language of description’ populated while in 2.6.0. So, my question is just that did anyone else experience this when they migrated. Initially, I thought it was purposeful and that one of the plugins would rectify it, but that was not the case. We now have ‘language of description’ and ‘Script of description’ populated correctly, thanks to the plugins. The new and unexpected/unwanted ‘language of description note’ remained the same after implementing the plugins.


--earlier post--
We implemented the first two of the three language plugins on a 2.7.1 dev instance and for the most part, we got what was expected. What was unexpected to us is that in the Finding Aid Data section, Language of description (English) became language of description/script of description (English/Latin) PLUS language of description note (English). The extra/new lang of desc. note feels a little redundant and we are at a loss as to why it appears? Did this happen for anyone else? Was this intentional?  Are we missing something obvious?

Ashley

Ashley Knox
Digital Initiatives Librarian
Randall Library
University of North Carolina Wilmington
knoxa at uncw.edu<mailto:knoxa at uncw.edu>
http://library.uncw.edu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibrary.uncw.edu%2F&data=01%7C01%7Cknoxa%40uncw.edu%7Caaea34565f8b4a39607c08d688608ce1%7C2213678197534c75af2868a078871ebf%7C1&sdata=aRhVgXWgwdJlJOfuBYOP3WNbHoTSgORkJqFFZUHLGIE%3D&reserved=0>
http://digitalcollections.uncw.edu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdigitalcollections.uncw.edu&data=01%7C01%7Cknoxa%40uncw.edu%7Caaea34565f8b4a39607c08d688608ce1%7C2213678197534c75af2868a078871ebf%7C1&sdata=FWqWw29Sqtnu6xGB77IrgKaz7guhzKGCcvKcBZYGx4U%3D&reserved=0>


From: Knox, Ashley M.
Sent: Tuesday, September 8, 2020 1:29 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: language plugin implementation 2.7.1

We implemented the first two of the three language plugins on a 2.7.1 dev instance and for the most part, we got what was expected. What was unexpected to us is that in the Finding Aid Data section, Language of description (English) became language of description/script of description (English/Latin) PLUS language of description note (English). The extra/new lang of desc. note feels a little redundant and we are at a loss as to why it appears? Did this happen for anyone else? Was this intentional?  Are we missing something obvious?

Ashley

Ashley Knox
Digital Initiatives Librarian
Randall Library
University of North Carolina Wilmington
knoxa at uncw.edu<mailto:knoxa at uncw.edu>
http://library.uncw.edu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibrary.uncw.edu%2F&data=01%7C01%7Cknoxa%40uncw.edu%7Caaea34565f8b4a39607c08d688608ce1%7C2213678197534c75af2868a078871ebf%7C1&sdata=aRhVgXWgwdJlJOfuBYOP3WNbHoTSgORkJqFFZUHLGIE%3D&reserved=0>
http://digitalcollections.uncw.edu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdigitalcollections.uncw.edu&data=01%7C01%7Cknoxa%40uncw.edu%7Caaea34565f8b4a39607c08d688608ce1%7C2213678197534c75af2868a078871ebf%7C1&sdata=FWqWw29Sqtnu6xGB77IrgKaz7guhzKGCcvKcBZYGx4U%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200918/27589a4d/attachment.html>


More information about the Archivesspace_Users_Group mailing list