Exceptions translation mess

Exceptions translation mess

by Dan Poltawski -
Number of replies: 10

Hi,

We've had a long standing problem since Moodle 2.0 where by the default behaviour of moodle_exception is to translate the errorcode passed to it.

I really don't like this situation because:

  • Its wasting translators time, translating obscure exception messages. Our translators time is precious, we shouldn't be wasting it on 'exceptional' situations.
  • Incomprehensible error messages for multilingual sites. If the admins of a Moodle site only speak one language and the error message is in another, the error message printed in the log is the language of the user who experienced it
  • Non-searchable error messages presented to users. If an error message is in a different language to english, its often impossible to search for on google or docs.moodle.org

I would like to see us change this behaviour so that we don't encourage the creation of new strings with exceptions.

I haven't thought particularly hard about solutions in code, but I would like to get discussion about this problem and potential solutions.

My thought is that we could have a default exception handler that handles the translation so that:

  • Webpages do something like: 'An error occurred: ($a)' error message which is translated (with $a being the english 'errorcode'). Perhaps adding the ability for an exception class to be more specific
  • Web services/CLI scripts do english errors
Average of ratings: Useful (1)
In reply to Dan Poltawski

Re: Exceptions translation mess

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

We used to only use English for these in 1.x.  

We added translatability in 2.x but it was always supposed to be a low-priority thing for translators.

If this isn't obvious then is this just a question of making AMOS indicate this better?

Average of ratings: -
In reply to Dan Poltawski

Re: Exceptions translation mess

by Jérôme Mouneyrac -
At the moment the web service exception format is:
- errorcode
- translated message
- debuginfo

I agree with you Dan. Web service exceptions don't need to be translated. They just need an errorcode and debug info, not even a message at all.

But at the end, web service exception are exceptions thrown by externallib.php functions. And externallib.php functions can be used by something else than web services, like a local plugin. We don't have any web service exception properly speaking - except the servers ones but it's peanuts for the translators.

I think if we translate web page exceptions, then it makes sens to translate externallib.php exceptions as it could end up in the web page.
Average of ratings: -
In reply to Dan Poltawski

Re: Exceptions translation mess

by Frédéric Massart ⭐ -
Picture of Core developers Picture of Plugin developers Picture of Testers

I tend to lean towards Dan's opinion here.

I think we should never remove the errorcode/errormessage (however we call it) from the exception output at all. As mentioned above, it is quite useful to be able to Google the 'original' errorcode, or to mention it to a developer (who will be able to grep it), or to mention it somewhere (docs, forums, tracker, ...) without having to wonder what the translation is.

But I'm not convinced that we should translate them.

Fred

Average of ratings: -
In reply to Dan Poltawski

Re: Exceptions translation mess

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, before we start talking in code terms - exceptions - let us talk in people terms.

There are two things that are jumbled up in Moodle's exception handline.

1. Reporting meaningful error messages to users when something has gone wrong that the user might be expected to understand and expect. This is the kind of situation where we have a require_capability in the code, but in users terms, we need to tell them that they are not allowed to do that.

2. Internal, technical errors that we never expect users to see. A good example of this would be anything that is currently a coding_exception.

Between these two, there is a grey area.

1. is an important part of usability, and must be localised. I think the require_capability makes the case that a good way to implement a localised error like that is what we have now: an exception throw that displays a nice localised error message if it is not caught.

However, it is also clear that type 2. error messages should not be localised.

So, overall, Dan has identified a problem, but his proposed solution is too simplistic.

Average of ratings: Useful (2)
In reply to Tim Hunt

Re: Exceptions translation mess

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Tim: your point 1. is not valid because Moodle should ideally never show those "meaningful error messages". It should happen only if somebody bookmarks some random page or if somebody modifies moodle settings while other users are logged in - no error message is going to help with these, sorry.
Average of ratings: -
In reply to Petr Skoda

Re: Exceptions translation mess

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

OK, so I did not use a very good example. Though people do ocasionally have their permissions edited by another user while they are logged in, or do sometimes log in as a different user in a different browser tab, then come back to the first tab and click a link.

Another similar case is when you get a sesskey error after your session has expired, then you have logged in in another tab. That does happen, and we should make it comprehensible to the user.

The best example I can think of right now is in qtype_stack or qbehaviour_opaque. Both of these make a web-service call as part of processing a student's quiz/question submission. Obviously, it is possible that the other server is down, and which point the question type needs to generate some comprehensible description of what the problem is, which can then be displayed to the student in the quiz UI. The student probably already quite stressed because they are taking a test. They last thing they want is an incomprehensible error. In terms of getting that explanation from deep in the question plugin code to the quiz UI, and exception throw seems to work quite well.

Average of ratings: -
In reply to Petr Skoda

Re: Exceptions translation mess

by Hubert Chathi -

How about the case where a teacher links (maybe by accident) to a page that students don't have access to?

Average of ratings: Useful (1)
In reply to Hubert Chathi

Re: Exceptions translation mess

by Damyon Wiese -

A new exception class for truely exceptional errors would help - exceptions that should not normally happen so do not require translation. The new exception class should not do any lookup on the error code passed to it - just print a generic error and the code. 

 

Average of ratings: -
In reply to Hubert Chathi

Re: Exceptions translation mess

by Aparup Banerjee -

Hm, how about we have an exception message with a (translate this) somewhere linking to a configurable external translation service like google?

Average of ratings: -