Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-37157

Multianswer cloze fails to compare unicode strings correctly

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 2.3.3
    • 2.3.4, 2.4.1
    • Questions
    • MOODLE_23_STABLE
    • MOODLE_23_STABLE, MOODLE_24_STABLE
    • MDLmaster-MDL-37157-2
    • Hide

      To test this, you need to understand about the different ways that you can write accented characters like 'départ'. The options are to either use the single character LATIN SMALL LETTER E WITH ACUTE , or the combination LATIN SMALL LETTER E then COMBINING ACCENT ACUTE. When grading Moodle short-answer questions, we want to consider those the same thing.

      So, you need to create a two short answer questions, one where the right answer is represneted one way, and the other where it is represented the other way.

      Then you need to answer both questions using both representations, and make sure they are all graded correct.

      Show
      To test this, you need to understand about the different ways that you can write accented characters like 'départ'. The options are to either use the single character LATIN SMALL LETTER E WITH ACUTE , or the combination LATIN SMALL LETTER E then COMBINING ACCENT ACUTE. When grading Moodle short-answer questions, we want to consider those the same thing. So, you need to create a two short answer questions, one where the right answer is represneted one way, and the other where it is represented the other way. Then you need to answer both questions using both representations, and make sure they are all graded correct.

    Description

      We received a report that two users filing the (apparently) exact same string in a cloze question were "judged" differently.

      The students were supposed to answer "répondre" (in french).

      • In one case, the equivalent unicode string was "72 65 CC 81 70 6F 6E 64 72 65" (the "é" is represented as "65
        CC 81", which is "e" + "ACUTE"
      • In the other case, the equivalent unicode string was "72 C3 A9 70 6F 6E 64 72 65" (the "é" is represented as "C3 A9", which is "EACUTE"

      This looks like a use case for using Normalizer:

      Normalizer::normalize($string, Normalizer::FORM_D)

      on all strings-to-be-compared (or FORM_C, I'm not quite sure).

      So far I failed to find where this could be tested, a pointer would be helpful.

      Cheers, OdyX

      Attachments

        Issue Links

          Activity

            People

              timhunt Tim Hunt
              odyx Didier Raboud
              Dan Poltawski Dan Poltawski
              David Monllaó David Monllaó
              Safat Shahin, Tim Hunt, Ilya Tregubov, Kevin Percy, Mathew May, Mihail Geshoski, Shamim Rezaie
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                14/Jan/13