Abandon Compound Language Variables

1 Explanation of Feature

Whilst the vast majority of language variables consist of a static Language_ID, which can also be found in the code (GUI classes), ILIAS also allows language variables to be assembled with dynamic code variables. These composite language variables are used to reduce the number of language service calls. One example is their use in RBAC, where there are recurring operations for each module and language variables are composed of the component name and the associated operation.

Currently, there are approximately 1,100 locations in the ILIAS core where composite variables are used. In slightly more than half of these cases, fixed suffixes or prefixes are used. This limits the possible translations. In the other cases, it is not possible to determine which variable is being called without examining each instance individually.

Example for big and complex compound variables:

Examples for small and component based variables:

Examples for fully dynamic calls:

2 Reasons to Abandon Feature

2.1 Conceptual Perspective

However convenient the dynamic assembly of language variables may be for developers, this approach poses a problem for language maintenance. This is because it makes it immensely difficult to identify the use of language variables in existing GUI classes.

With monolithic, non-composite language variables, it is straightforward to check whether these variables are still being used in the code or have since become obsolete.

An approach to implementing a check for obsolete language variables was commissioned by the ILIAS Association many years ago, but it did not prove successful in practice and also produced too many false positives, which then had to be manually re-added later.

At the very latest with the switch to PO files for language variables, the approach involving composite language variables has become problematic. When creating PO files, it is mandatory that all language variables in the code are in plain text. The appropriate solution is to phase out the practice of dynamically assembling language variables.

2.2 Technical Perspective

The removal of compound language variables is a precondition for a good implementation of PO-Files for improving language handling.

3 Integration of Stakeholders

The removal of language variables primarily affects the coding authorities responsible for components that use composite language variables. Changes must be made to the code for which these individuals are responsible. The methods used to compose language variables must be replaced with corresponding static language variables, which will need to be created from scratch. To ease the workload on the coding authorities, we would submit the relevant pull requests. The changes to the code and the creation of the new, necessary language variables would be undertaken by the ILIAS Association and overseen by the authorities responsible for language handling. The transfer of existing translations from the composite language variables to the new static Language_IDs is to be implemented via script and, prior to a final merge, approved by the Association following editorial review.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Contact

Person to be contacted in case of questions about the request or for funding offers:  Kunkel, Matthias [mkunkel]

4.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for abandon this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

Use the following discussion section to express your objections against this request or your consent to get rid of this feature.

6 Implementation

{ Short description of the final implementation and possible consequences for existing installations. }

Removed Testcases

The following testcases have been removed from Testrail or modified because the feature is no longer part of the ILIAS core.

Approval

Approved at {date} by {user}.