Translations for submission form labels and hints

[bram-atmire]

Traditionally, labels for the submission forms were managed in input-forms.xml, outside of the general message catalog. It's not 100% clear to me how we are going to tackle i18n for the submission forms in DSpace 7.

Are we continuing keeping this separate?
Or is there a plan to add the input forms messages to the main catalog?

[tdonohue]

At this time, Submission labels/hints are managed in the submission-forms.xml (the replacement for input-forms.xml) in a similar manner to DSpace 6. See https://github.com/DSpace/DSpace/blob/main/dspace/config/submission-forms.xml#L56-L57

So, as far as I'm aware, they will be manages similar to DSpace 6, unless we find a volunteer to create a different approach.

At a simple level, if anyone is interested, it might be relatively simple to have submission-forms.xml just specify an i18n key (rather than translated text) to the frontend, where it could then be translated. However, I have not dug into this in any great detail, and it's not currently scheduled for the 7.0 dev team to tackle.

[kshepherd]

I am strongly in favour of adding i18n keys to submission forms! From what I've seen in my recent work, there wouldn't be any problems implementing this and it would make multilingual submission form management much easier.

Right now, if I change some config for a few fields in my submission form, I have to repeat or sync the same change across all the languages I support which is cumbersome, prone to error, and essentially is storing i18n in the DSpace REST app even though it's displayed in angular.

If we moved to i18n keys that are piped to translate in dspace-angular a single submission-forms.xml could be maintained and the i18n messages could be kept in dspace-angular along with other submission components.

As far as I'm aware, the REST API doesn't use the values from label / hint / required except in logging.

[kshepherd]

A further note here that all the form components pass label through a translate pipe, so this is already possible, all we're missing is to make keys and move the text across to en.json5

[kshepherd]

As per notes on #1670 the above approach was rejected. The changes in DSpace/DSpace#8322 (also closed) may or may not be useful to somebody else who implements translation in the REST response.