Enabling translation of collection's/community's names and description

[michdyk]

Is your feature request related to a problem? Please describe.
Collection's and community's names are static in the context of language and users are not able to change their context based on selected language.

Describe the solution you'd like
We want to add a feature that provides a tool to add alternative translation of collection's and community's description. That tool should provide an opportunity to add translation of any language that could be enabled in DSpace. On collection/community view we are planning to add a language switcher which will toggle selected language inputs. That will enable translation on these parts in an easy way from an interface perspective.

Additional context
We consider this feature really important for repositories in a multilingual context. For non-English-centred repositories, it is crucial to have a complete translation in native language, but also it is important to stay as much as possible accessible for English speakers.

Contribution

We, as PCG Academia, want to develop that feature as our contribution to the DSpace 7 project. We are planning to contribute that feature to the 7.6 release.

[tdonohue]

@michdyk : I'd be in favor of this feature & I suspect others would be as well, but could you inform us more about your design?
Several questions come to mind:

• There's already a language switcher in DSpace 7 (see the globe in the header), would you plan to simply show the Community/Collection name/description based on that language switcher?
• Since Communties/Collections use "dc.*" metadata, are you planning on just allowing people to enter the Title (dc.title) and Description (dc.description) with a language tag? This would be similar to how it can be done for Items (on the Edit Item page it's possible to add fields in different languages)

Overall, I think this would be a great feature & I'd welcome you to contribute it. But, you may want to share more of your thoughts/design if you want to obtain feedback on it before you begin development of the feature. This also makes it more likely to get more immediate acceptance into the DSpace codebase.

[mwoodiupui]

I agree that the display of the container's name and description should be made sensitive to the existing language switch.

The Community and Collection edit components could be extended with language code drop-lists. But the current UI design is not set up for multiple values of a single field as the Item edit component is. It might be well to borrow the "Add another value" button approach from the submission interface.

There are other fields on those pages which might also benefit from translation. (But I would talk with a lawyer before extending this to any license or copyright fields!)

[michdyk]

@tdonohue @mwoodiupui
Thanks for your questions. I answer as precisely as it is possible for now.

1. I confirm that we are planning to show the community/collection name/description based on a language chosen from a language list (from the globe)
2. I confirm that we are planning to use current metadata fields from community/collection edit view and add there language tags.
3. We are planning to add this feature, not as a dropdown list, but as an additional switcher (similar to the globe switcher but independent from that one). Our idea is to edit/add a new language by choosing any language from a collection/community view edit switcher, while not changing the language of the whole system (from a globe switcher). If it is ok, I will be able to send the project of our design in a few days to show what exactly we are planning.

[michdyk]

Here is the project of our proposition:

Our assumptions:

1. Any language could be set as the default language
2. Names of sections (Name, introductory text etc.) are based on a general repository language (selected from the globe).
3. Any other DSpace language could be entered in the context of the default language. The default language inactive form will be displayed simultaneously with an active new language form.
   @tdonohue @mwoodiupui Please, let me know if you have any thoughts. Thanks!

[michdyk]

Hi, @tdonohue @mwoodiupui
We want to proceed with this task further and are ready to develop the described function.
Please let me know if you have any questions.
Best,
Michał

[tdonohue]

@michdyk : While I'm not against your team beginning this development, I want to make you aware of a recent decision by our DSpace Steering Group. Simply put, the next release (7.6) will only include new features which existed in 6.x. This is because Steering is transitioning 7.x to a "feature complete" status, which means 7.7 and later will not allow any new features, and will only allow for bug fixes.

That said, 8.0 planning/development will begin as soon as 7.6 is released, and this feature therefore could be considered for the 8.0 release. I don't think it will qualify for 7.6 though, as DSpace 6.x did not include any feature of this sort. That said, I do still believe this is a useful feature for 8.0.

Your overall design above looks reasonable to me. However, I think that the language tabs on the "Edit Collection/Community" page must be configurable in some manner. Currently there are >20 languages under the globe icon in the header, and it would not be possible to list all 20 of those languages as tabs on that page. Therefore, a site likely will need to configure which (subset of) languages they want to support for Communities/Collections.

[michdyk]

@tdonohue: So we are going to develop this feature for 8.0 release.
Our goal is to have configurable languages from the config file. In our practice, no repositories use all >20 languages (most of them use 2-3 languages). In most cases, it will look like the one presented above.
However, I am sure there could be some seldom cases that will use more languages. In that case, we can present these languages using the wrapping method for tabs:

[saschaszott]

@michdyk , is this issue / feature request resolved? I'm not sure, if the Angular changes in PR #3078 are sufficient to resolve this issue?

[michdyk]

@saschaszott my colleague @MMilosz works on issues from the review. It should be ready that week for re-review