Joseph Rézeau

Bonjour,
Pourquoi ne pas utiliser l'outil Glossaire de Moodle?
Joseph

See this discussion. I'm afraid I said I would do something about it but never did...

DIFF files of proposed changes.
Joseph

Screenshot of proposed multichoice numbering system based on CSS2 list-style-type options. Using Moodle 1.9, Windows XP, Firefox 2, Formal-white theme.
Joseph

Hi Tim,

Further to your message I have refined my solution in order to offer - hopefully - both simplicity and flexibility.

Going the CSS list-style-type way seems to me the most reasonable (and logical) option. Since CSS2 offers a way to automatically number lists in a variety of styles (including those proper to certain languages) I would not call providing something like 26 answernumberinglang1, answernumberinglang2, etc. language strings opting for simplicity. The CSS option offers the added advantages of providing a wider choice of 'non-language' options, (a. b. c.; A. B. C.; 1. 2. 3.; 01. 02. 03.; i. ii. iii.; I. II. III.) and, in the case of Japanese, a choice of 4 numbering options. The only problem that remained in my previous solution was the vertical misalignment of radio-button, choice text and feedback message. I have now found a solution for this, as shown on attached screen shot. It was a simple matter of setting margin-top and margin-bottom to 0.

As regards simplicity for end-users, I agree that displaying the actual style rendering values (a. b. c. d.) in the drop-down list rather than their CSS names makes selection easier, as does the grouping of the most commonly used values at the top of the list. For language-related styles, however, I prefer to keep their names. This should be no problem to the (few) users who would have to use them, and who know what the names stand for. In the language files (other than English), of course, any other method of display might be adopted, including local variations of lang. files. The solution I propose is both simple (users can concentrate on the most frequent, top-listed styles) and complete.

As regards the feasibility of "hacking the code" for people who want more flexibility. First of all we must bear in mind that, although Moodle is open source, it does not necessarily follow that all moodle users are either a) able or willing to hack the code b) in a position where this is allowed. In large institutions, admins are extremely reluctant to hack the Moodle code at all... and Open source then means... closed.

In my CSS solution, there should normally be no need for hacking the multichoice code, since all foreseeable list-style types would be included... Unless there exist certain languages which rely on list numbering characters not included in the CSS2 types. Can anyone tell us? There is also the MSIE-related problem, but that's not too bad because when MSIE can't display certain list-style types, it reverts to decimal numbering. I don't know about other browsers; could people please check and report?

In your solution, hacking the code (for providing extra flexibility, adding new numbering strings, etc.) involves changes in no less than 4 different places: the answernumbering field in the question_multichoice table; the language file; function get_numbering_styles() and function number_in_style($num, $style) functions in the questiontype.php file. On the other hand, in my CSS solution, hacking the code (if new CSS styles should become available in further CSS specs or if CSS types needed to be removed or re-ordered) only the first two places (the answernumbering field in the question_multichoice table and the language file) would have to be hacked... there should be no need to hack the questiontype.php file at all.

Looking forward to your and fellow Moodlers' views on this new proposal,

ATB

Joseph

PS.- Screenshot and new, slightly modified DIFF files attached to next messages.