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.

[tdonohue]

Per discussions above, we all agree this would be nice to have, but would prefer a solution where the "submission-forms.xml" uses the Messages.properties on the backend. That way, the translation occurs on the backend, and Angular just displays whatever language is sent to it.

In the meantime, it is possible to support multiple languages in the submission form, but it requires unnecessary duplication of the "submission-forms.xml" config. For example:

• submission-forms_de.xml would be used for German
• submission-forms_fr.xml would be used for French
• submission-forms.xml would be the default

[michdyk]

I and my team currently working on this case and we are able to contribute to this issue.
In practice, we are using the method that Bram mentioned. For me, it is more clear to use existing translation on the frontend than add a new method on the backend because most of the translations are stored on the frontend.
I propose to store them in the i18n catalogue for each language and add keys for labels and hints in the submission-forms.xml.
We are currently using a pattern for naming translation keys: "submission.sections.forms.x.label" or "submission.sections.forms.x.hint" where x = name of metadata, i.e. "submission.sections.forms.dc.title.label".
It works well for us, so if you accept that way, we can contribute that easily.
Furthermore, we are able to also add Polish translation for hints and labels because we already have it implemented locally.

[michdyk]

@tdonohue What I mentioned above, I could be assigned to this task, if the method described there is acceptable

[tdonohue]

@michdyk : Please be aware of the discussion that occurred in this previous (now rejected) PR: #1670 In there, it was noted by several that passing keys from the REST API to the Angular UI is very problematic.

The biggest issue is that adding a new key to the frontend requires a full rebuild of the frontend... it's not a simple config like on the backend. But, it was also pointed out that this model is bad for other clients. If someone is using our REST API for a different client and reading this endpoint, they won't know what submission.sections.forms.dc.title.label means. Basically the client must have extra knowledge about the meaning of each key.

So, if you'd like to volunteer to look at this, please feel free. However, I'd stress that you should review the past discussions, as several of us feel that it'd be better to do translations via Messages.properties on the backend, rather than have the REST API return an i18n key, which you then need to translate in the UI.

[michdyk]

@tdonohue I understand your point. If the community and your previous discussions indicate that translations should be added via Messages.properties on the backend, I will try to do it that way.
However, I need some time to examine this method and give you a confirmation of an assignment as a volunteer

[tdonohue]

@michdyk : Sounds fine. For the past discussions regarding moving these translations to Messages.properties, see the discussion in this older PR #1670 That PR had a solution similar to your proposal, as it created these new i18n keys in the Angular UI en.json5. But, as you'll see, that PR was closed/rejected because several of us were worried about that solution (including the original developer).

An initial approach at moving the i18n keys to Messages.properties was also started in this other PR DSpace/DSpace#8322 However, the developer mentioned that he didn't get it completely working & didn't have time to move it forward and therefore closed the PR.

[paulo-graca]

I think this discussion should be reopen, considering the new DS9...

Things I consider disadvantages of not having translatable keys in the UI:

• prone to errors: most of our institutions don't rely on the default DSpace submission forms. Having multiple forms (with the language sufix), considering the complexity of maintain it, also considering the staff rotation, will be more prone to errors. Imagine if you, by mistake, just add or remove a field in one of the .xml files and forget, or don't know you need to add to all. You will be introducing errors or unwanted data in the database, and another person has to detect and fix them. Unnecessary work and complexity if we just had one form to maintain.
• complexity of project maintenance: having translations on Messages.properties will add complexity to project maintenance and deployment process since translations requires an external library - https://github.com/DSpace/dspace-api-lang. And, to me, it doesn't make much sense to maintain my own dspace-api-lang project when I just want to have a translated field label to appear to that user. The submissions definitions are structured elements that will be rendered in the UI and will appear to the user as html forms. Submission forms are for users, not for machines or logging. It doesn't make sense to having those translations at the server side.
• We already have a translation mechanism in the UI, a mechanism that is extendable that allow you to add your own keys. That mechanism is perfect to help you if you want to custom your submission forms. It is currently used for Submissions Step's label and would be a waste not to use it for the rest of the submission process.