Show Advanced KnowledgeHide Advanced Knowledge

Multilingual Input Element

 

1 Initial Problem

Multilinguality is an issue for nearly all object types in ILIAS and even global properties (like instalation title, etc). It is a lot of hard work to implement this.

We observe that content in ILIAS is often organized in complex structures which can have sub items and a lot of data fields (text/dates/numbers/...).
 
We can find two strategies for translation of these structures:

1. duplication of whole structures (like the page editor and learning module does)
2. sharing a common structure + translation of individual fields (like categories do with title/description)

 There are use cases for both strategies and combinations thereof. We will now concentrate on improving approach (2).
 
Our primary goal is to solve this problem "once" and turn multilinguality via approach (2) effectively into a zero-cost-feature for future use cases.

1.1 Possible Use Cases

• course/group information
• course/group relevant user data
• advanced metadata
• custom user properties (currently known as 'user defined fields')
• ... and many more

2 Conceptual Summary

We suggest to introduce an input field, which offers translation capability. The implementation should be as centralized as possible to make its reuse easy. 

2.1 What to start with

The implementation of the multilingual input element should be accompanied by some initial use cases. We suggest to start with the following (list is still up to change):

• migration of title/description
• metadata for course, e.g. course information (easy)

2.2 Input Modes

The initial implementation will have exactly two input modes.

1. single-line Text-Input
2. multi-line Textarea

Note: The implementation should be prepared to be extended in the future, e.g. to support a TinyMCE input mode or something like it.

2.3 Managing available + default languages

The multilingual inputelement may appear in different contexts. If it is used to translate custom user properties (aka user defined fields), then we can infer the available languages and the default language from the global ILIAS client settings (administration > languages).
 
Content objects have a different story. An installation may be predominently English (global default language for that client), but some category in the repository may contain German content. If we translate the German content, we may want to treat German as the default language for that object. And we may want to choose a different set of available languages for translation (e.g. we will only translate to French, since there is dedicated English content for everyone else).
 
This is basically how multilinguality for categories works *right now* (category > settings > multilingualism). You define the available languages and set a default one (independent of the client settings). The new multilingual input element should respect this object-specific override.
 
Alternatively we could discuss, if object-specific overrides could be reduced to only picking a new default language and infer the available languages from the installation. At least for the page editor this controls the fallback behaviour (only _unavailable_ languages have fallback to the default language). The setting of available languages (object override) could be exchanged for a setting to control the fallback rules.

2.4 Fallback rules and mandatory fields

This appears to be very tricky!

• E. g. the title of an object is a mandatory field. It appears that we need a fallback rule, if a translation is left empty.
• On the other hand there could be use cases for empty fields (e.g. contact information only in certain languages, since the contact person only understands those, or the page editor). We don't want a fallback rule everywhere.

How can we solve this?

1. We force the user to enter all translations for mandatory fields.
2. We have fallback mechanism for mandatory fields. But voluntary fields could individually opt-out of that fallback mechanism (or opt-into).

2.5 Search

It should be possible to search/index translations if the field itself is meant to be searchable (e.g. 'course information', 'advanced metadata', etc.).
 
However it is unclear, whether search results should depend on the users preferred language. If we only search in the users language, this _will_ lead to different results for different users (A telling B to search for "time managament" might not work, if B prefers German over English). However you could argue this to be expected behaviour. The alternative to search in all translations has additional problems: (i) intransparency what caused a match of a search result, if the user can not see all translations. (ii) collisions of different meanings of words in different languages (a rare acronym in language A could be a very common word in language B, e.g. searching for 'AND' would pollute the results with a lot of meaningless matches of english translations). It seems to be more conservative to only search in the users language, but this appears also more difficult to implement. Further discussion is needed.

2.6 A Side Note about Metadata

• Advanced Metadata don't support translation
• LOM-Metadata are capable of translation
• LOM-Metadata always mirror title and description (but only the primary language for ILIAS learning modules)
• LOM-Metadata could be improved by not saving title/description redundantly (compare categorization of taxonomies)

2.7 Possible Implementations (WIP)

We currently see two interesting approaches:

• traditional DB-model and abstraction via ADTs (preferred)
• key-value-store

This needs an in-depth technical concept. Our current pre-analysis is as follows.

2.7.1 Preferred Approach: Traditional DB-Model via Advanced Data Types (ADT)

• additional dedicated lang-tables per use case (traditional database table layout)
• abstraction e.g. via Advanced Data Types

=> This promises a good balance between performance and ease of implementation. However we don't have enough experience with ADTs.

2.7.2 Alternative: Key-Value-Store

• two global lang-tables (variants: CLOB + TEXT)
  • component_id (e.g. Wiki/Kurs/..)
  • object_id (useful in most cases, but not all)
  • secondary_id (text)
  • lang_key
  • value (CLOB / TEXT)

=> The initial implementation appears easier. But this approach might result in more complex SQL queries, due to an increased number of JOINs. Also this table would grow much more quickly.

2.8 Open Questions

• data storage (see alternatives above)
• API
• deleting/copying objects
• object specific overrides
• fallback mechanism
  • for mandatory values (like labels of custom fields, formerly known as user defined fields)
  • for optional values (like description)
• search
• what do we start with?
• UI Proposal[1]

[1] Timon Amstutz supports the general idea and is willing to comment on any UI suggestions, but he will not make proposals himself.

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

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 Outlook and Exclusion

• support tiny editor as input mode
• learning goal oriented view (complex pages)
• course/group relevant user data
• the implementation of page editor and learning module will not be switched to the new multilingual input element (there is no 1:1 relation between the structures per language).
• explore the 'orthogonal approach' to duplicate whole structures like ILIAS Tests, SCORM learning modules, etc.

7.1 Related Feature Requests

• Multilingual Titles and Descriptions for All Object Types + Plugins
• Multilingual Page Editor for Container Objects

8 Discussion

Suittenpointner, Florian [suittenpointner] 2016: Here is an overview of functionality in repository objects possibly relevant to multilinguality

Killing, Alexander [alex], 8 Feb 2017: What is the scope of the feature request? Its title is "Multilingual Input Element" and I thought this would be mainly about the UI element. But it contains search/metadata/persistence related discussions which are separate issues. The important part of a UI element would be chapter 3 here and some mockups imo. But maybe I am just confused. Since the new UI framework is missing input elements completely, the proposal could be to "just" extend the existing ilTextInputGUI and ilTextareaInputGUI classes. However how values are stored and searched is not handled by these UI classes.

Kiegel, Colin [kiegel] 2017-02-10: Thank you. I agree that the title of the feature request may be misleading. :-)

We want to close the gap of implementation costs between mono- and multilingual. I.e. the scope should be to centralize as much as makes sense technically.

Of course this could easily be more than a regular "UI" or "input" element. E.g. in the JF workshop we already discussed two different approaches to centralize the persistence aspect.

Search may be a thing to exclude from centralizing. I would expect the technical concept to answer exactly these questions: how far can we go technically with centralizing the aspects discussed in this request and the JF workshop. The technical concept is allowed to suggest not to centralize a certain aspect - but it should then discuss why or give some outlook how to proceed in the future.

Does that answer your question?

Kiegel, Colin [kiegel] 2017-02-22: I stumbled upon a new open question: What should happen if a new language is activated and e.g. custom fields (formerly UDF) use this feature to be translated. Since CFs require a label, they should always fallback to the default language. But if the default language is changed too, we need a clever fallback mechanism. Will it be possible to create a new CF without entering all translations?

On a technical level: Should this fallback happen (a) when the translation is queried, or (b) when the translation is saved? (a) is transparent about what the user really entered, but (b) may be more performant for most requests (except when a new language is activated and a bulk of mandatory translations need to be copied).

On the other hand there will also be fields which don't require a value (e.g. optional description). There it would be legitimate to have a description in the default language, but not in another language. A fallback may not be what we want here.

I think these questions around fallback rules are among the toughest open questions of this feature request. One aspect that makes this complicated is that we have both optional and mandatory values, which may need different fallback rules.

Schmid, Fabian [fschmid] We use a multilingual input field in some of our installations. The concept of this Inputfield is based on a tabbed implementation and allows the usage without overlays/modal-dialogues. In the background a service is storing the multi-language-inputs in an abstract database model. The service currently acts as Multilanguage Advanced Metadata and Multilanguage Custom Fields (former User Defined Fields):

JourFixe, ILIAS [jourfixe], 04 DEC 2017: We discussed the proposal by Stefan Wanzenried, especially the screen 'Meta Data' with the tabs for different language versions.  We would like to know more about form validation, esp. when several multi-lingual inputs are existing. Important for us is that the offered languages can be set in the related object and are not determined by the activated system languages. Additionally, a master language should always be defined - at least to have a fallback when an active system language is not supported by the form. We rejected the idea of a modal that offers all translatable text inputs in a table. We discussed if language selection tabs are offered for each supported input field or for the form itself and voted for input elements - even if more than one is offered. In general, we see that the idea is going in the right direction but would like that our remarks are taken into consideration for a future proposal.

9 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}.