Improving language coding scheme

1 Initial Problem

In addition to the normal language file, it is not possible to create a plain language (Einfache Sprache) or easy language (Leichte Sprache) file for German. Language files for different regions like American English and British Englisch are not possible with the current language coding scheme.

2 Conceptual Summary

One means of indicating the language used is by labeling the information content with an identifier or "tag".  Sometimes language tags are used to indicate additional language attributes of content (e. c. the dialect, writing system). Here we can no longer get any further with the current ISO 639 scheme (RFC 1766).

Instead, we should use the RFC 5646 scheme in the future. The more recent standard describes the interaction of language codes (ISO 639), extended language tags , geographic codes (ISO 3166-1) and script codes (ISO 15924). It contains not only individual languages, but also language families. Each language is represented by a two-letter identifier (alpha-2 code). For example, de stands for the German language or fr for the French language. 

With RFC 5646 the following language files will be supported:

1. Previously used language codes like en or de
2. It will be possible to support region subtags like en-GB  (English like it is spoken in Great Britain) and en-US (English like it is spoken in the US). 
3. Sign Languages are discribed by using the extended language subtag as prefix. So sgn-EN stays for English Sign Language. 
4. Different script subtags or writing variations for languages will be supported like sr-Latn (Serbian written using the Latin script.) 

Many users, especially in Germany, for example authorities, need the learning platform in plain language in order to provide the content in an easy-to-understand manner. It can be discussed whether this should even be a separate language or whether it is not enough to write the content in plain language. It's also about controls. If the installation in question was just a shop window, without registration and participation, then labeling the content would probably be sufficient in most cases. Direct link to the learning module or file, click through. But when someone needs to participate, the person is quickly burdened with purely technical usage instructions that are really not easy to understand.

Whatever you decide, with RFC 5646  it is possible to create your own and, above all, transferable language files that could also be incorporated into the core in the future.

3 User Interface Modifications

3.1 List of Affected Views

No views are affected. Feature has only impact on language service backend.

3.2 User Interface Details

No user interface details are affected.

3.3 New User Interface Concepts

No user interface concepts are affected.

3.4 Accessibility Implications

No accessibility implications are affected.

4 Technical Information

Have a look at RFC 5646 . 

5 Privacy

No personal data are affected.

6 Security

No new endpoints or other new possible attack vectors are added.

7 Contact

• Author of the Request: katrin.grosskopf
• Maintainer: kunkel & katrin.grosskopf
• Implementation of the feature is done by: katrin.grosskopf

8 Funding

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

• …

9 Discussion

JourFixe, ILIAS [jourfixe], 15 APR 2024: We highly appreciate this suggestion and schedule the feature for ILIAS 10. This is a first part towards a more flexible language handling. But it requires a concept about how all affected components handle language information in the future and related implementations in the components to handle these new strings (or objects). We kindly ask for a Feature Workshop for a coordinated plan to discuss and decide on the next steps.

10 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}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.