PO-Files for improving language handling

1 Initial Problem

The language handling mechanism of ILIAS – i.e. the management of all translated interface texts – relies on a very outdated scheme: language variables are maintained in proprietary .lang files and imported into the database at deployment time, from where the application reads them at runtime. This approach is maintenance-intensive, is hardly compatible with common translation tooling, and provides no structured solution for texts that differ depending on quantity (singular/plural) or for language variants such as dialects.

Modern approaches now exist to solve exactly this problem. gettext, a well-established industry standard built around template, translation and compiled files (POT, PO, MO), offers a considerably more future-proof and maintainable foundation for the language service.

2 Conceptual Summary

PO files are to be introduced for the language handling scheme, with their contents read at runtime via PHP's gettext() function family. The database is fully removed as the storage and runtime source for language variables; today's .lang files are replaced by .po/.mo files. The ILIAS GUI for editing language variables remains available and unchanged in its functionality, but internally operates on the new files instead of the database.

2.1 Advantages over the current scheme

2.2 Handling of singular and plural forms

In the current .lang/database approach there is no structured distinction between singular and plural forms; plural handling has to be solved individually in PHP code. gettext solves this via ngettext(): for each language, a plural formula is stored that defines how many plural forms the language has and by which rule a given number is mapped to one of those forms (German/English: 2 forms; languages such as Polish or Arabic: 3–6 forms). For every quantity-dependent string there is a singular and a plural reference, together with one translation per plural form of the target language. At call time, only the quantity is passed; the correct form is then selected automatically based on the plural formula of the respective language – the calling code itself does not need to know the plural rules of that language.

Example (German translation, 2 plural forms):Example (German translation, 2 plural forms):

Every entry consists of the original key (msgid), optionally a context (msgctxt) to distinguish identical keys originating from different modules, and – for quantity-dependent strings – a singular and plural variant (msgid_plural) with one translation per form (msgstr[0], msgstr[1], …). At runtime, gettext automatically selects the matching translation based on the given number. The same mechanism allows dialect languages, language variants, or an "easy language" version to be set up and maintained as a complete, self-contained language.

2.3 Migration of existing language data

Migrating today's .lang files and the language variables maintained in the database into the new PO/MO scheme is an integral part of this FR:

The concrete technical design of the migration tool – timing, execution as a database update step vs. a standalone tool, handling of individual customer customizations to language texts – is detailed in a separate implementation concept.

2.4 Uniqueness of language variables

In the new scheme, language keys must be unique across all components. Through the combination of context (or module-qualified key) and identifier, every key is unambiguously assigned to a module; collisions between modules that use the same identifier are thereby structurally excluded.

Settling on the concrete key variant (see 2.2/2.3) is a prerequisite for implementing this uniqueness concept.

2.5 Consequences for developers

The txt() function is switched to gettext() (or ngettext() for quantity-dependent strings) within the Language component and remains available as a thin wrapper. This results in the following requirements:

2.6 Documentation (language.md)

The existing language.md still fully describes the old .lang/database structure and is revised as part of this FR. Going forward, it is to describe, among other things:

3 User Interface Modifications

3.1 List of Affected Views

No views affected.

3.2 User Interface Details

No UI changes required.

3.3 New User Interface Concepts

No new UI concepts available.

3.4 Accessibility Implications

No changes regarding accessibility.

4 Additional Information

4.1 Involved Authorities

4.2 Technical Aspects

The following are brief explanations of the terms gettext, POT file, PO file and MO file:

As a result, the central function for retrieving language texts (txt()) is switched to gettext() within the Language component (see 2.5).

4.3 Privacy

No changes.

4.4 Security

The following security aspect must be taken into account:

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Auerbach, Jeanine [jeanine.auerbach]

4.6 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 this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

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

6.4 Approval

Approved at {date} by {user}.