Show Advanced KnowledgeHide Advanced Knowledge

Multilingual Titles and Descriptions for All Object Types + Plugins

 

1 Initial Problem

By now (v5.2), multilingual titles are only supported by one container object type (categories) and one other object type (ILIAS learning modules).

It would be extremely helpful to have this feature also available for other objects, especially courses and other container types like groups and folders. But even objects like chats could benefit from multingual titles and descriptions in certain scenarios. In the end it is also a question of consistency to have the same functionality for titles and descriptions across all object types.

Multilinguality is an issue for nearly all object types in general. At least title and description should be multilingual in all object types (and there are a lot of object types which would only need that in order to be multilingual).

2 Conceptual Summary

We propose to enable the multilingual titles and descriptions for all ILIAS objects of the repository (including plugins).

• The implementation should be identical to categories.
• The user interface code of ILIAS should be refactored to implement this only once. We want to introduce a centralized settings section for every ILIAS object. This settings section will at least include title/description and can be extended by other common attributes like availability of objects.
• We want to have Plugin-Support, too. Plugins will have to be rewritten, to make use of it. It is possible to implement legacy support for old plugins. This should be clearly deprecated to allow dropping it in a future release.
• At first each object needs to introduce a tab Multilingualism like categories do, to mirror the current implementation there.
  

Resulting behaviour: If available, title and description is displayed in the selected language of the current user. Otherwise the default values are presented.

Outlook: As soon as we have the Multilingual Input Element we can think about refactoring the translation of title and description.

2.1 Really all objects?

We tend to answer this question with yes – mainly due to consistency and being most flexible. Here are all the arguments for and against it, we could think of.
 
PRO

• streamlined setting screens are easier to understand
• this settings section can be centralized, which makes maintenance easier
• you never know, how content is used (even a chat could be multi-lingual)
• admins are in control, no one is forced to use it

 
CON

• the usefulness of multilingual titles/descriptions is disputable for some objects
• authors could have false expectations about the intention and capabilities of some objects

2.2 Related Feature Requests

• Multilingual Page Editor for Container Objects
• Multilingual Input Element - as soon as we have this, we can go deeper with some objects
• Multilingual Container Objects <- going deeper

3 User Interface Modifications

3.1 List of Affected Views

• Container Object > Settings (new tab multilingualism)
• Container Object > View Content

3.2 User Interface Details

see Multilingual content support and scroll down to implementation.

3.3 New User Interface Concepts

-

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: SIG Language Support
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• ...

7 Discussion

Kiegel, Colin [kiegel] 2016-12-15: Container objects are most important wrt to multilinguality, since their child objects can target different languages already. Multilingual title+description+page editor for container objects should be the top priority / basic package.

However, from an architectural stand point it would be nice to centralize the multilinguality of title and description such that it does not need to be implemented individually by each object. This probably means some refactoring and would require some additional thoughts about plugins. Once done we don't need to worry about multilinguality of title and description even for future objects. This would be really nice, but could be an "optional" stretch goal of the crowd-funding campaign of the SIG Language Support.

Centralizing the title+description settings may also open the door for future extensions/refactoring of settings which should be available for all objects (like online status and availability).

Killing, Alexander [alex], 16 Dec 2016: Title/Description translation is already centralized. However the interface/code should be improved. But before we implement this for all object types, I think we need to provide scenarios that illustrate that this is feasible. E.g. how will a multilingual forum work? I have no idea.

Kiegel, Colin [kiegel] 2017-01-24: The UI component for multilingual inputs would be very useful for custom fields (aka user defined fields) too. Especially if we consider moving some hard-wired user data fields to pre-configured custom ones (as in Personal Profile Social Media and Second email address for user accounts and possibly more to come).

Kiegel, Colin [kiegel] 2017-03-02 Please find the minutes of our virtual jour fixe workshop (2017-01-31) attached below.

Kiegel, Colin [kiegel] 2017-01-31: I split this request and created these additional ones:

• Multilingual Page Editor for Container Objects
• Multilingual Input Element
• Multilingual Container Objects

Killing, Alexander [alex], 8 Feb 2017: I think a precondition of the "centralized settings section" would be the availability of "Multilingual Input Elements" (text and textarea), since the centralized settings would be embedabble into the settings forms of each component. It all depends of how the activation of languages will be implemented, but if this is not done explixitly, consuming components would only need to modify the form logic.

Kiegel, Colin [kiegel] 2017-02-10: Thank you. That's a good point. :-)

We have indeed two alternatives:

1. Wait for multilingual input element (as you point out)
2. Start with centralizing the 'category-implementation' for all objects. Later migrate to multilingual input element as part of that implementation.

The advantage of (1) is reduced costs, the advantage of (2) is early availability (we know we can deliver that for 5.3, right?). IF we manage to get the multilingual input element for 5.3 too, than it's of course obvious to pick (1).

In the current absence of the multilingual input element I would like to ask you to give a costs estimate to centralize the 'category-implementation' now.

Does that answer your question?

Killing, Alexander [alex], 6. Mar 2017: "Start with centralizing the 'category-implementation' for all objects" should mean what exactly? a) Having a general settings section for all object types? Or b) using the existing multilingual handling of categories which is already existing? For b) you need to ask all object maintainers how much effort would be needed to integrate this existing centralization (of the multilingual object and title implementation).

But this integration will completely change, once we have a). And a) makes only sense, if we agree on the UI for the multilang input fields. It would be easier if someone would start with a mockup on this. Should we do it completely "within the form" or are tabs involced (e.g. for setting a default language or adding new languages? This will greatly incluence the way to integrate the whole functionality. The S&R plugin introduces tabs in forms, which is something we do not have in the core.

Up to now we envisaged using a link that opens a modal (with inputs for different languages), which would be more or less on the basis of the existing UI elements.

Kiegel, Colin [kiegel] 2017-10-16: Ok, let's just treat the multilingual input element as a pre-requisite and focus on the remaining questions. :-)

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.