Copied from https://ideas.exlibrisgroup.com/forums/308179-rosetta/suggestions/31088020-upgrade-internal-xslt-processor

Currently ALMA seems to accept only XSLT 1.0 syntax for XSLT custom letter configuration files. This means we are deprived of the many goodies of XSLT 2.0 and 3.0:

• strong typing and XSD types


• XPATH 2.0 sequences


• XSL functions


• range variables


• regular expression matching and grouping


• URL encoding and decoding


• better value comparison

EXSLT 1.0 is not supported either, so whenever I try to do something more intelligent that some simple markup and string replacing, I hit the limits of XSLT 1.0. Trying to make decisions in your XSLT based on element values without regular expressions is a big PITA - if possible at all - and leads to huge XSLTs that nobody can read afterwards, not even the author.

And don't get me started on the nice things that XSLT 3.0 provides like JSON, attribute and text value templates, dynamic evaluation, packages and tons of extra/enhanced XPATH 3.0 functions.

Dear support

While creating the non-english versions of the powerpoint presentations for SLSP training, I ran into some concerning mistranslations. It almost looks like you used Google Translations to translate the English Terms in Alma to other languages.

For example, the English homonym "pass" was erroneously translated to "succeed" instead of "go by". This happened while translating to Italian and German (see attachement). I can only imagine how annoying that will be for librarians all over Switzerland when we go live with Alma this coming December.

I can imagine it's a known issue to the libraries you have been using Alma for a while already.

Can you fix this and make sure to have actual native or proficient speakers of the target languages translating Alma's vocabulary instead of people who have to use Google to find the words, please?

Thank you.
Kind regards

Stefan
E-Media Zentralbibliothek Zürich
FEx IZ7 (UZB)

In some cases it would be helpful to be able to enter a dynamic value rather than a static text in a configuration field.

My current use case is configuration of FTP import profiles, where it would help with two different needs: avoid repeatedly having to adjust all import profiles after a sandbox refresh, and avoid having to create separate import profiles for each operator with the only difference being a personal Input directory.

As the import profile configuration doesn't use the centrally defined FTP profiles (another idea ...), after reloading the sandbox from the production environment all FTP import profiles will need to be adjusted to point to servers/directories that should be used with the sandbox. If there was some sort of variable that could be used in the configuration value, this could be avoided; Instead of having to change "Input directory" from "MYIMPORTDIR/PRODUCTION" to "MYIMPORTDIR/SANDBOX" for each import profile, I would specify something like "MY_IMPORTDIR/${ENVIRONMENT}" and have it automatically point to the correct directory.

And as our catalogers want to import only their own records from one of our source systems, I currently need to create a different import profile for each one of them, with the only difference being the Input directory: "MYIMPORTPROFILE/PRODUCTION/USERA", "MYIMPORTPROFILE/PRODUCTION/USERB" etc.

With a user variable I would be able to have just one profile with this input directory:
"MYIMPORTPROFILE/${ENVIRONMENT}/${CURRENT_USER}"

(For a scheduled job, ${CURRENT_USER} would probably expand as "System".)

But the feature could be applied more generally than just FTP-configuration:

• https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/10194222-configure-alma-letters-to-use-the-operator-s-from (E.g. ${CURRENTUSEREMAIL} with fallback to library/institution email)




• https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/18430366-configuring-different-sender-e-mail-addresses-smp (E.g. ${CURRENTLYATEMAIL} with fallback to library/institution email.)