Access to Memory (AtoM)

It seems that culture fallback does not work expected for multilingual term records with Use For labels added (UF labels will not display in the view pages of other cultures at all), and that translations of UF labels are not showing up on view pages. However, if you try to work around this and add separate source and translation culture UF labels, adding the secondary culture UF label can cause the original source culture UF label to be lost.

So: there are 3 main issues, though I'm not sure if the 1st one is a bug or just a design choice so I will leave out a detailed description. As a summary though, the issues are:

#. UF labels will not display in other culture view pages (no culture fallback)
#. UF label translations do not display
#. Adding a new UF label in a secondary culture (i.e. translation) can cause a source culture UF label to be lost

Details on how to reproduce issues 2 and 3 below.

Issue 2 - translations of UF labels do not display on term view pages¶

To reproduce

• Create a new term or find an existing one
• Add a Use For label and save
• Flip the UI to a secondary language (e.g. French in an English installation). Note that the UF label doesn't display on the view page in French (see issue 1).
• Enter edit mode
• Add a translation for the English UF label and save

Resulting error

• UF label does not display in French, despite translation being avaiable and translation string being saved in edit page

Expected result

• Either UF labels should not be translatable, or they should display when translated

Adding a new UF label in a secondary culture can cause a source culture UF label to be lost¶

To reproduce

• Create a new term or find an existing one
• Add a Use For label and save
• Flip the UI to a secondary language (e.g. French in an English installation). Note that the UF label doesn't display on the view page in French (see issue 1).
• Enter edit mode
• Skip the field provided to add a translation for the source culture UF label (e.g. the one below the yellow text showing the original source culture string). Instead, add an new UF label in the translation culture / secondary language. Save.
• Flip the UI back to the original source culture

Resulting error

• Source culture UF label is lost (not present in either view or edit pages)

Expected result

• No data loss

Notes¶

This feels very related to #13563. There the problem was the JS used with the particular field types, which attempts to automatically remove blank ones. We fixed this for #13563 by replacing the field types with the more UX friendly multi-row fields that feature separate add/remove buttons. However, a multirow field feels incorrect for a UF label.