Randy Kuehn Maggie Hughes saron tran | https://archivesspace.atlassian.net/browse/ANW-886 https://archivesspace.atlassian.net/browse/ANW-1157 https://archivesspace.atlassian.net/browse/ANW-961
| Recommend Thumbnail: will change to a more standard thumbnail with https://archivesspace.atlassian.net/browse/ANW-907 Control of digital object display dimensions:
Pass - think this would be useful
Will not do at this time, potentially outside the scope of ArchivesSpace, may revisit after larger community decisions are made regarding digital objects Responsive digital object display: Pass
See b above
Fully support. (Reminds me of recent ANW-942.) Icon at each level of the heirarchy that contains a digital object (collection, series, file) – inherited from lowest level. Recommend tagging Usability sub-team before passing. I like this one. In the PUI archival objects show the hierarchy up to the different series and then to the collection (resource) and then to the repository-- and I think digital objects should function the same.
input from colleagues: I’m with Miloche on 1 and 2—I wonder with #3 if there’d be a way to distinguish digital objects that are digitized from analog collections vs. born digital objects that really are part of hybrid analog and digital or solely digital collections, and if institutions and researchers would find that distinction useful or not. I definitely understand where the user is coming from who made the request, though I appreciate that once you click on an individual digital object you get the full contextual information. Marcella Here are my comments: I agree with your idea of having an outside team work on the translations. This is something that would be nice to have but I'm sure there are other bugs and or enhancements that are a higher priority.
I don't think this is a bug, instead it should be changed to an enhancement request. I can't find it in the manual but I know as an ASpace trainer, we tell people that diacritics are WYSIWYG. In other words, they should be entering it directly rather than as hex keys. I agree it would be great if both worked but I believe ASpace is working as expected.
I think the Found in: label should only include the repository. Instead, for a digital object you can have a new label of something like Linked to: [name of resource/identifier/series that digital object is linked to]. The digital object isn't actually "in" the analog collection, instead the digital object is its own collection, and is just related to the resource record it's linked to. This will make it easier to identify digital objects that are linked to resource records vs. those that stand on their own.
--Miloche
My take on #1 isn't so much who is doing i18n, but rather that if some team wanted to, it's really difficult when strings are baked in the XSLTs. If someone copies the whole XSLT template over to a copy and translates all the strings to French, it'd also be really a pain to keep it in sync going forward. There also isn't a provision for easily finding and extracting all the translatables.
Pulling all the translatables to one file of variables (https://stackoverflow.com/questions/12086231/how-to-do-i18n-with-xsl-and-xml) would at least get people thinking about translateable strings, and at least to some degree would mean a change to the XSL layouts could happen once, not in every language's copy. It's not pretty work to pull all those out as vars in XSLT, and even then it's still not in something nice like a .po ('gettext') file. But, if someone really wants a different language, they can translate the XSLT files we have now. So, I don't think it's a very high priority. (God help us if someone wanted to print out the PDF in an right-to-left language like Arabic or Urdu). Tom |
|
Daniel Michelson | https://archivesspace.atlassian.net/browse/ANW-970 https://archivesspace.atlassian.net/browse/ANW-883 https://archivesspace.atlassian.net/browse/ANW-944 https://archivesspace.atlassian.net/browse/ANW-1119
| Request for specific reordering of the elements in the collection overview view of the PUI. Part of this was already rejected at our January 5 meeting (https://archivesspace.atlassian.net/browse/ANW-298 ). Recommend closing as repository specific. Ticket wants a conservation note (defined in DACS) added as a type of note. Note types are determined by EAD, not DACS, so this ticket should be closed. This ticket wants the publish status of agent records set by whether they are linked to a published record, rather than a checkbox in the agent record. Strongly recommend closing this ticket, there are good reasons (particularly with the launch of 3.0) that it may be desirable for an unlinked agent to be viewable in the PUI. I’m biased, since I submitted this, but I think having the merge top container function act differently than the other functions in the “manage top containers” screen should be avoided unless there is a good reason.
|
|