[ILIAS 10] [FIX] TestQuestionPool: Translate plugin question types

[Saaweel]

Fix: Plugin question type is not translated in question pool

Mantis: #0047758

Problem

The question list in a question pool was not translating the type name of plugin questions. The ilAssQuestionList::load function was calling $this->lng->txt($row['question_type']) directly, bypassing the plugin's own translation mechanism. The same issue existed in assQuestionGUI::outQuestionType(), used by ilTestCorrectionsGUI::populatePageTitleAndDescription.

Solution

Added a getQuestionTypeTranslation() helper method in both ilAssQuestionList and assQuestionGUI that checks whether the question belongs to a plugin and, if so, delegates to $plugin->getQuestionTypeTranslation(). Otherwise it falls back to the standard language translation.

Files changed

• components/ILIAS/TestQuestionPool/classes/class.ilAssQuestionList.php
• components/ILIAS/TestQuestionPool/classes/class.assQuestionGUI.php

How to test

1. Install a question type plugin.
2. Add a question of that plugin to a question pool.
3. Open the question list in the pool — the type column should now show the plugin's translated type name.
4. Also verify the question type label in the test corrections view (ilTestCorrectionsGUI).

[dsstrassner]

PR for 11: #11643 Trunk: #11644

[kergomard]

Hi @Saaweel

Thank you very much for the PR. I would kindly ask you to implement the following changes:

• Please do not introduce any variable in lowerCamelCase. All variables MUST be in snake_case.
• Please do not introduce any usages of the $DIC in classes that fully rely on dependency injection and never introduce a usage of the $DIC in the middle of the class (if there absolutely needs to be a usage of the $DIC it must be in the constructor). In this case it should be injected between ilComponentsRepository and ?ilNotesService.

Thanks again and best,
@kergomard

[Saaweel]

Hi @kergomard, thanks for the feedback!

• Renamed $questionData to $question_data in the new method to follow snake_case convention.
• Removed the global $DIC usage from getQuestionTypeTranslation() and moved it to the constructor, where ilComponentFactory is now resolved and stored as a private property.

Regarding the injection as a constructor parameter: ilAssQuestionList is instantiated in numerous files across several components, and adding a required parameter would require changes in all of them. Since I am not the maintainer of those components, I preferred to keep the impact minimal and resolve the dependency in the constructor instead.

Regards,
@Saaweel

[matheuszych]

Hello @Saaweel ,

first of all, thank you for analyzing the issue and implementing the fix!

Could we reuse the same implementation that assQuestionGUI::getQuestionTypeTranslation uses inside ilAssQuestionList::getQuestionTypeTranslation as well? That would streamline the approach and keep the translation logic consistent in both places.

Something like this:

    private function getQuestionTypeTranslation(array $question_data): string
    {
        $local_dic = \ILIAS\TestQuestionPool\QuestionPoolDIC::dic();
        $this->questionrepository = $local_dic['question.general_properties.repository'];

        $question_properties = $this->questionrepository->getForQuestionId($question_data['obj_fi']);
        
        $type_name = $question_properties?->getTypeName($this->lng);
        if ($type_name !== null && $type_name !== '') {
            return $type_name;
        }

        return $this->lng->txt($question_data['type_tag']);
    }

Of course without the $local_dic inside of the method itself.

Best regards
@matheuszych

[Saaweel]

Hi @matheuszych,

thank you for the suggestion!

I aligned ilAssQuestionList::getQuestionTypeTranslation() with the implementation in assQuestionGUI by using the GeneralQuestionPropertiesRepository from the local QuestionPoolDIC.

I also removed the ilComponentFactory dependency and the $DIC['component.factory'] usage from ilAssQuestionList.

One important detail: I used $question_data['question_id'] for getForQuestionId(), not $question_data['obj_fi'], because obj_fi points to the parent question pool object. Using obj_fi made all rows resolve to the same type label.

Regards,
@Saaweel

[kergomard]

Hi @Saaweel and @matheuszych

Sorry, the last change is not correct. I had looked into this, but this does make things worse: As far as I can see, this change would cost us one round trip to the database per question. This is f***** lot of round trips for something we already have in our hands. If we want do do this, we would need to move things around quite a bit, but this I would only do for trunk.

If I didn't miss anything: Please revert the last change.

Best,
@kergomard

[Saaweel]

Hi @kergomard,

Right, I've removed that commit from the PR

Best regards,
@Saaweel

[kergomard]

Hi @Saaweel

Sorry, I didn't think far enough this morning, when answering quickly: The other usage of $this->questionrepository->getForQuestionId($this->object->getId()) in assQuestionsGUI is also wrong. We do already have the information about the question type for non plugin questions, why would we call the database to retrieve it? ...but as far as I can see the solution you implemented for ilAssQuestionList should work for assQuestion, too.

Sorry again for missing this before.

Best,
@kergomard

[Saaweel]

Hi @kergomard,

thanks for pointing this out.

I adjusted assQuestionGUI::getQuestionTypeTranslation() accordingly. It no longer calls
$this->questionrepository->getForQuestionId($this->object->getId()).

Instead, it now uses the same approach as ilAssQuestionList: it checks the active qst
plugins via the component factory and returns the plugin translation when the question type
matches. For non-plugin question types it falls back to the regular language translation.

Best,
@Saaweel