Home / FAQ / False language detection and correction / False language detection and correction: Details

False language detection and correction: Details

This workflow aims to identify translated project fields in keep.eu that may have been assigned the wrong language.

The workflow applies to translated project fields stored in Django Admin and concerns all programming periods and programmes available in keep.eu. It combines:

  • Automatic language detection;
  • Manual validation;
  • Excel-based operational review;
  • And semi-automatic correction processing.

The false language detection and correctionworkflow is part of keep.eu’s multilingual quality-assurance processes. It is currently performed twice a year:

  • January
  • June

Additional checks may also be performed whenever considered necessary by the data manager or technical manager.

Step F1. Automatic language detection

Whenever a translated project field changes or a new translated field is created, the system (Django Admin) automatically analyses the content of the translated field and attempts to identify the language used in the text. The workflow currently checks the following translated project fields:

  • Name
  • Description
  • Expected results
  • Achievements

Additional fields may be added in future versions of the workflow if considered relevant.

F2. Creation of false translation objects

After automatically detecting the language of the translated field, the system compares the automatically detected language with the language currently assigned to the translated field. If the two languages differ, the system creates a record in the Django Admin table that can be retrieved under Django Admin’s main menu item ‘Project false translations’.

Each record corresponds to one suspected false translation. The table therefore functions as the operational review environment for this workflow. It allows the data manager to:

  • Review suspected false translations individually;
  • Export suspected false translations into an Excel file;
  • Validate language corrections;
  • Reject corrections;
  • And process corrections automatically through reimports.

The Excel export generated from the table currently includes the following columns:

  • Programme: Title of the programme to which the project belongs.
  • Project ID: Internal keep.eu project identifier.
  • Acronym: Project acronym.
  • Suspected field and suspected language, which indicates: The translated field concerned; and the language automatically detected by the system. Examples of fields include project name, description, expected results, achievements.
  • Suspected field content: Content of the translated field itself. This allows the reviewer to assess whether the automatically detected language appears correct.
  • Checked language: Language currently assigned to the translated field and being checked by the workflow.
  • Use suspected language: Operational validation column. If the reviewer inserts ‘x’, the language currently assigned to the translated field is replaced with the language automatically suggested by the system.
  • Insert language manually: Operational manual-correction column. The reviewer may manually insert a language code (ISO 639-1) in this field. The manually inserted language then replaces the currently assigned language.
  • Keep existing: Operational rejection/confirmation column. If the reviewer inserts ‘x’, the existing language assignment is maintained. The record is then removed from the workflow and will no longer appear in future exports unless detected again later.

Not all automatically detected languages are currently operationally supported within keep.eu. If the system detects a language not currently supported in the workflow, the ‘Suspected language’ field may contain ‘und-‘ followed by a numerical identifier. These cases require particular attention during manual review. In such situations, the Use suspected language column should not automatically be used, and manual verification is necessary before validating corrections.

The languages currently available in this workflow are listed here.

F3. Direct manual review in Django Admin’s administration

If only a limited number of records require review and the issue concerns mainly project names, the data manager may review and process the records directly in Project false translations without generating an Excel export.

The reviewer analyses each row and decides whether to:

  • Use the automatically detected language;
  • Manually insert another language;
  • Or keep the current language assignment.

Once processed, the corrected record disappears from the operational review table.

F4. Exporting the operational Excel file

If many records require review, the data manager exports the records into an operational Excel file. To generate the export:

  1. Open Project false translations
  2. Select at least one row in the table, up to All.
  3. In the ‘Action’ dropdown menu, select ‘Export all’ and then click ‘Go’.

The system then generates and downloads the operational Excel review file.

The export includes all rows currently available in the table, not only the selected rows.

F5. Manual review of the exported Excel file

The exported Excel file is reviewed manually by the data manager, by analysing each suspected false translation and deciding whether to accept the automatically detected language, manually assign another language, or keep the current language assignment unchanged.

The review process is performed using the operational columns:

  • Use suspected language: Inserting ‘x’ in this column replaces the currently assigned language with the automatically detected language proposed by the system.
  • Insert language manually: Typing a language code (ISO 639-1, please refer to list in Wikipedia) into this column manually assigns another language to the translated field.
  • Keep existing: Inserting ‘x’ in this column keeps the current language assignment unchanged while removing the record from future workflow exports.

If none of the three operational columns receives a value, no change is applied during reimport.

F6. Reuploading the reviewed Excel file

Once the review is completed, the edited Excel file is uploaded again into Django Admin’s Project false translations. The upload functionality automatically processes all validated changes.

During processing, validated corrections are applied, manually inserted languages are assigned, records marked as Keep existing are removed from the workflow, and processed rows disappear from the operational review table.

This phase is semi-automatic: The validation decisions remain manual, while the processing of the corrections is automatic.

Roles and responsibilities

Technical manager

Responsible for:

  • Maintaining the automatic detection mechanism;
  • Ensuring exports and imports function correctly;
  • Maintaining workflow stability.

Data manager

Responsible for:

  • Reviewing suspected false translations;
  • Validating corrections;
  • Exporting and reimporting Excel files;
  • Ensuring multilingual consistency of project data.

Project and product manager

Responsible for:

  • Overseeing workflow usefulness and consistency;
  • Ensuring alignment with keep.eu quality objectives;
  • Coordinating workflow evolution and documentation.