I thought your were going to do this "gradually", adding new strings and changing some calls each day.

In fact, now that all them are "correct" print_error() calls it's more difficult to find them, when it was trivial to do before your commit. Also be prevented about those BIG commits because they use to make more difficult to merge things (sometimes, not now, I guess) and to revert and so on. Just a recommendation.

And yes, next step is about to creating error strings and replace them in current calls to print_error(), that's a huge task (I'd recommend to make that "gradually" )

Ciao

just saw you latest gradual changes about this issue and have found that here:

http://cvs.moodle.org/moodle/backup/backup.php?r1=1.48&r2=1.49

You've used the same error string "cannotusepage" in THREE places. If you look at this carefully you'll see that the second replacement is incorrect, only admins can use that page (whereas the rest are admins and teachers).

I'd suggesto you to fix this by:

1) Adding some different lang strings like:

cannotuseadmin
cannotuseadminadminorteacher
...

(i.e. all them will start by "cannotuse" followed by the list of roles allowed to use the page). Just a example proposal, feel free to improve it.

2) Apply then where necessary.

That way, always you find one error message, you can resuse those langs strings safely in future changes of this gradual task.

Ciao

Why using the error string
cannotuseadminadminorteacher (cannotuse admin admin or teacher)
at http://cvs.moodle.org/moodle/backup/backup.php?r1=1.50&r2=1.48 ?

• print_error("Unable to recognize questiontype of question part #$positionkey.");
  + print_error('unknownquestiontype', 'question');
  break;
  }
  echo "</label>"; // MDL-7497
  @@ -672,7 +672,7 @@
  $answer = $exploded[1];
  // $sequence is an ordered array of the question ids.
  if (!$sequence = get_field('question_multianswer', 'sequence', 'question', $state->question)) { - print_error("The cloze question $state->question is missing its options"); + print_error('missingoption', 'question', '', $state->question); }
  $sequence = explode(',', $sequence);
  // The id of the current question.
  @@ -799,7 +799,7 @@
  $wrapped->partiallycorrectfeedback = '';
  $wrapped->incorrectfeedback = '';
  } else { - print_error("Cannot identify qtype $answerregs[2]"); + print_error('unknownquestiontype', 'question', '', $answerregs[2]); return false; }
  The multianswer being the only one of its type in the actual question bank, identifying which subquestion have a problem needs specific infos.
  So I propose to create specific message in lang qtype_multianswer.php and refer to them in the print_erro call.
  If you agree, I will do the necessary work so that you can continue on the 620 left ...

they can be found by searching ->error in question files.
I will take care of them

This command will help you find them:
grep "print_error([$ ]" --color -rn .

Please reopen it if you find more unfixed print_error calls or hidden ones, TIA.

Thanks for your hardworking
I fixed some of your new strings as below.

[error.php]
-$string['csvloaderror'] = 'Error occur during loading vcs file!';
+$string['csvloaderror'] = 'Error occur during loading CSV file!';

[scorm.php]
-$string['cannotfindsco'] = 'Cannot found SCO';
+$string['cannotfindsco'] = 'Could not find SCO';

And we need to add one more string $string['secretalreadyused'] to error.php.
This string is used for login/forget_password.php.

Mits

It is ugly, do you have any better idea?
I found more indirect error in other modules, I made a "TODO" mark in source code.

there are still calls to error() in the HEAD versions of mod/data/lib.php and mod/data/preset.php

I just replaced "invildpreset" by the proper wording "invalidpreset" introduced by your last commit.