Hi, i'm writing to express the following situation. I'm the ICT Administrator of the Carabobo University in Venezuela. We are using moodle since the 1.4 version. Now we have installed and working 10 moodle 1.6.3+ platforms (one or more by each faculty). The spanish package works perfectly but in some cases the system is still showing error messages in english. I looked in the code and found that those errors are write directly into the page that generate the error. My question is, is this a programming directive? i mean, is it necessary to maintain the moodle coding philosophy? or we can modifiy it adding a file that contains all those untranslated strings and modificating those messages dynamically.
If i do this, how can i publish my modification to moodle.org consider to add it into a stable release?
Is anybody there interested to help me in this job?
Thanks...
P.S. Sorry about my poor english
Manuel A. García
ICT Administrator
Universidad de Carabobo - Venezuela
Hi Manuel,
As far as I understand it, the Moodle point of view on non-translation of error messages is as follows. Error messages which are "serious" and need administration consideration are hard-coded (in English). The reason seems to be that Moodle site administrators are computer-knowledgeable people who ought to be also knowledgeable in English
and, when reporting serious errors or bugs in the Moodle bug tracker, will do so in English. I think this is a wise policy in general. However, it can make it difficult for "ordinary" , non-English-speaking users of Moodle when such an error occurs and they are confronted to an error message in English which they don't understand and may find difficult to note down in order to report it to their admin.
I would advise against translating such messages.
On the other hand, there still remain a number of hard-coded messages of warning, etc. in some places in Moodle, which ought to be translated.
You should really try to differentiate between those messages which should remain in English and those which might be translated.
Joseph
I agree with Joseph's reasoning that some "serious" error messages should be hard coded, because they are only triggered when there is some fundamental problem with file access, or database access, and that if there is such a problem then the translating of messages is also probably not going to work, because to translate a message, Moodle has to access the language files and the database.
If you would like to identify specific messages which you think should be translated, then please suggest them here, or on the Moodle tracker.
Perhaps we could also set up a Moodle glossary for the translating the English serious error messages into other languages?
regards
Gordon
If you would like to identify specific messages which you think should be translated, then please suggest them here, or on the Moodle tracker.
Perhaps we could also set up a Moodle glossary for the translating the English serious error messages into other languages?
regards
Gordon
My understanding is that any error message that might be seen be a user should be localised.
It is only with developer focussed error messages (for example, reporting errors from the database that probably result from you having screwed up your SQL syntax) that you are allowed to be lazy and hard code them.
It is only with developer focussed error messages (for example, reporting errors from the database that probably result from you having screwed up your SQL syntax) that you are allowed to be lazy and hard code them.
So are you saying Tim that you think all hard-coded error messages should be replaced with a message from the language files?
Well, that would be quite a large and boring job. Bet certainly in any new development, I put all error messages in the language file, unless they are really reporting really obscure, this-should-never-happen, errors.
Yes they should! That's a big job, but it's a great intro job for new people. And a great excuse for new people to have a "tour" of the codebase.
(Internally, at catalyst, I often ask newcomers to the Moodle team to do exactly this kind of stuff. Diagnose and fix a few trivial moodle bugs. It's not the most exciting job of all, but a week later, they _know_ where everything is. Magic!)
And together with the cleanup, reject new code without proper localised errors...
(Internally, at catalyst, I often ask newcomers to the Moodle team to do exactly this kind of stuff. Diagnose and fix a few trivial moodle bugs. It's not the most exciting job of all, but a week later, they _know_ where everything is. Magic!)
And together with the cleanup, reject new code without proper localised errors...
I would agree to have all the error messages localised if developers can be provided with some sort of meaningful code (the string key, for example) to know quickly what error is being showed in an language-independent way.
I think we had one plan about this some Moodle iterations back (but I haven't been able to find it). Anyone remember that? (or perhaps I've dreamed it).
Ciao
I think we had one plan about this some Moodle iterations back (but I haven't been able to find it). Anyone remember that? (or perhaps I've dreamed it).
Ciao
Should we have a new lang file?
errormessages.php
errormessages.php
Hi Eloy,
Perhaps you were thinking of the error pages in Moodle Docs http://docs.moodle.org/en/Category:Error?
Perhaps you were thinking of the error pages in Moodle Docs http://docs.moodle.org/en/Category:Error?
That is what I meant by "Additional information can also be possibly displayed.". The string key could be it.
Hi Eloy, currently I'll solve this situation making a glossary with the translation. But in the future moodle could include an error code (or something like that) that let the administrator to identify quickly the nature of the error.
For example error 500 in web server. You can go to a table and know inmediatly what about this error, maybe creating an error borwser block just for admins and developers use, in this block we could include a brief description about the error, maybe the causes and possible solutions.
We only need the coding table guidelines (how to construct standardized codes) and... let's move on
P.S. this post is also in the spanish developers forum and i know that you speak spanish.. just for understandable things...
P.S.(2) I'm agree with the errormessages.php thing, parsing the strings by the code...
Thanks.
Manuel A. García
For example error 500 in web server. You can go to a table and know inmediatly what about this error, maybe creating an error borwser block just for admins and developers use, in this block we could include a brief description about the error, maybe the causes and possible solutions.
We only need the coding table guidelines (how to construct standardized codes) and... let's move on
P.S. this post is also in the spanish developers forum and i know that you speak spanish.. just for understandable things...
P.S.(2) I'm agree with the errormessages.php thing, parsing the strings by the code...
Thanks.
Manuel A. García
I think we have both print_error() which I understand takes parameters for get_string(), and the Wiki error pages links.
Now, I'll say the same thing I said in the spanish forums (where we started with this). Give us patches! Maybe open just one tracker bug, and feed it with patches! This is one of those so-easy things to fix if you are starting to hack on Moodle.
Get on board, help us.
Now, I'll say the same thing I said in the spanish forums (where we started with this). Give us patches! Maybe open just one tracker bug, and feed it with patches! This is one of those so-easy things to fix if you are starting to hack on Moodle.
Get on board, help us.
Exactly. print_error() is THE way to do all error messages in all new code. It not only prints a nice string in your own language (usually from the error.php language file) but it contains a link to the wiki for more information/feedback etc. I've added this to the coding guide.
If anyone wants to help convert any of the old error() calls to use print_error() instead, we'd love you to help!
If anyone wants to help convert any of the old error() calls to use print_error() instead, we'd love you to help!
Ok now everything is clear. Thanks for your answers, i was thinking something but a lot of people thought the same thing before than me... 
. Indeed that is the sense of this kind of forums, discuss and inform... I 'll look for the way to help with this job:
Thanks again...
Manuel A. García
Dirección de Tecnología Avanzada
Universidad de Carabobo - Venezuela
. Indeed that is the sense of this kind of forums, discuss and inform... I 'll look for the way to help with this job:"If anyone wants to help convert any of the old error() calls to use print_error() instead, we'd love you to help!"
Thanks again...
Manuel A. García
Dirección de Tecnología Avanzada
Universidad de Carabobo - Venezuela
I have a little problem with the print_error function. It always redirect the user to the english documentation site. It is not correct because moodle is being used by people on different languages and we should have the posibility of showing text in their natural language. I propose to make a few modification into the print_error function adding the capability of determinate the platform local language and redirect to that documentation site.
I created this issue in the tracker (MDL-8763). Although i send you the patch that i'm proposing.
thanks...
I created this issue in the tracker (MDL-8763). Although i send you the patch that i'm proposing.
thanks...
Manuel A. Garcia
ICT Administrator
Universidad de Carabobo - Venzuela
ICT Administrator
Universidad de Carabobo - Venzuela
Great start! Two things about the patch...
- We normally use unified diffs (try with cvs diff -u path/to/file.php ) which make it easy to spot where the changes are.
- I agree with idea in the the patch, but there is a larger problem behind this. The Wiki doesn't do any kind of "fallback" the way our string handling libs do. A langpack like es_ar has an entry that points to the 'parent', so it will check es_ar, es, and eventually en.
MediaWiki does not know a thing about this fallback, and the rules it follows. Perhaps we can pass them in the url (add a ?try=es_ar,es,en parameter) and have a custom "not found" handler for the /error/ subdirectory.
- We normally use unified diffs (try with cvs diff -u path/to/file.php ) which make it easy to spot where the changes are.
- I agree with idea in the the patch, but there is a larger problem behind this. The Wiki doesn't do any kind of "fallback" the way our string handling libs do. A langpack like es_ar has an entry that points to the 'parent', so it will check es_ar, es, and eventually en.
MediaWiki does not know a thing about this fallback, and the rules it follows. Perhaps we can pass them in the url (add a ?try=es_ar,es,en parameter) and have a custom "not found" handler for the /error/ subdirectory.
Hi Martin thanks for consider my propuse. I think that fallback is not necesary in this situation, maybe is an idiomatic thing but i'm missing something in your explanation (i don't understand something here). I will say something about my propuse:
the original print_error function contains this lines:
$message = '<p class="errormessage">'.get_string($errorcode, $module, $a).'</p>'.
'<p class="errorcode">'.
'<a href="'.$errordocroot.'/en/error/'.$modulelink.'/'.$errorcode.'">'.
get_string('moreinformation').'</a></p>';
error($message, $link);
the remarked section redirect me to the english documentation Wiki.
Now if i get the local language configuration from the database
$lang = get_record('config', 'name', 'lang');
And truncate it over the two first positions
$lang = substr($lang->value,0,2);
I'm getting the prefix that i need to go to the right local language Wiki, because if the local platform language pack is es_ar or es_utf8 or en_utf8 i will always get the correct prefix: es, en in this case. This have no dependence with the fallback process.
Now to get a little more robust method i will look if this entry exists in the mencioned wiki, trying this:
if(!fopen($errordocroot.'/'.$lang.'/error/'.$modulelink.'/'.$errorcode)) $lang = 'en';
If i get no reponse from the local wiki i redirect to the english one to provide some information (not in the rigth language but...). If there is neither in local language nor english any entry for the error we will get a "not found".
$message = '<p class="errormessage">'.get_string($errorcode, $module, $a).'</p>'.
'<p class="errorcode">'.
'<a href="'.$errordocroot.'/'.$lang.'/error/'.$modulelink.'/'.$errorcode.'">'.
get_string('moreinformation').'</a></p>';
error($message, $link);
Then this is part of the conversion process mentioned by Martin D (error() by print_error()). in his post. It will be a developer responsability to include the error entry to the english Wiki, and if he/she is not english spoken then include a translated entry in his/her local language error wiki.
the original print_error function contains this lines:
$message = '<p class="errormessage">'.get_string($errorcode, $module, $a).'</p>'.
'<p class="errorcode">'.
'<a href="'.$errordocroot.'/en/error/'.$modulelink.'/'.$errorcode.'">'.
get_string('moreinformation').'</a></p>';
error($message, $link);
the remarked section redirect me to the english documentation Wiki.
Now if i get the local language configuration from the database
$lang = get_record('config', 'name', 'lang');
And truncate it over the two first positions
$lang = substr($lang->value,0,2);
I'm getting the prefix that i need to go to the right local language Wiki, because if the local platform language pack is es_ar or es_utf8 or en_utf8 i will always get the correct prefix: es, en in this case. This have no dependence with the fallback process.
Now to get a little more robust method i will look if this entry exists in the mencioned wiki, trying this:
if(!fopen($errordocroot.'/'.$lang.'/error/'.$modulelink.'/'.$errorcode)) $lang = 'en';
If i get no reponse from the local wiki i redirect to the english one to provide some information (not in the rigth language but...). If there is neither in local language nor english any entry for the error we will get a "not found".
$message = '<p class="errormessage">'.get_string($errorcode, $module, $a).'</p>'.
'<p class="errorcode">'.
'<a href="'.$errordocroot.'/'.$lang.'/error/'.$modulelink.'/'.$errorcode.'">'.
get_string('moreinformation').'</a></p>';
error($message, $link);
Then this is part of the conversion process mentioned by Martin D (error() by print_error()). in his post. It will be a developer responsability to include the error entry to the english Wiki, and if he/she is not english spoken then include a translated entry in his/her local language error wiki.
Manuel A. Garcia
Dirección de Tecnología Avanzada
Universidad de Carabobo - Venezuela
Dirección de Tecnología Avanzada
Universidad de Carabobo - Venezuela
I don't think this is a good idea. We already have the language strings INSIDE Moodle which print the basic description of the error, with all the fallback etc.
The link to the wiki is just for EXTRA information that the community may want to create, perhaps links to HOW TOs on the internet etc. I don't see a lot of these being necessary, as usually the error message is enough.
If we have a separate wiki page FOR EVERY LANGUAGE then I think it all gets too spread out and a lot of people will miss nuggets of information.
The link to the wiki is just for EXTRA information that the community may want to create, perhaps links to HOW TOs on the internet etc. I don't see a lot of these being necessary, as usually the error message is enough.
If we have a separate wiki page FOR EVERY LANGUAGE then I think it all gets too spread out and a lot of people will miss nuggets of information.
Ok is true. It was just an idea.
Manuel A. García
Dirección de Tecniología Avanzada
Universidad de Carabobo - Venezuela
Dirección de Tecniología Avanzada
Universidad de Carabobo - Venezuela
Hi, thanks Joseph, Gordon and Tim for your fast answers. This is the first time that i post in any moodle english forum and i like so much the presice answer that you give to me.
I'm agree with Joseph when he said:
It supose that those kind of messages will be showed to the admins (in a good configurated platform). But i have to give an answer to my boss, he wants ALL moodle in spanish, for that i'll make a mix between all your answers, first than all i'll look for the hard-coded messages of warning and translate it. Then i will create a glossary with the translation of the serious error messages.
Now i have another question for you. After i took all this actions, how can i let the community to know it??
Thanks again
Manuel A. Garcia
I'm agree with Joseph when he said:
"Moodle site administrators are computer-knowledgeable people who ought to be also knowledgeable in English
and, when reporting serious errors or bugs in the Moodle bug tracker, will do so in English. I think this is a wise policy in general. However, it can make it difficult for "ordinary" , non-English-speaking users of Moodle when such an error occurs and they are confronted to an error message in English which they don't understand and may find difficult to note down in order to report it to their admin"
and, when reporting serious errors or bugs in the Moodle bug tracker, will do so in English. I think this is a wise policy in general. However, it can make it difficult for "ordinary" , non-English-speaking users of Moodle when such an error occurs and they are confronted to an error message in English which they don't understand and may find difficult to note down in order to report it to their admin"It supose that those kind of messages will be showed to the admins (in a good configurated platform). But i have to give an answer to my boss, he wants ALL moodle in spanish, for that i'll make a mix between all your answers, first than all i'll look for the hard-coded messages of warning and translate it. Then i will create a glossary with the translation of the serious error messages.
Now i have another question for you. After i took all this actions, how can i let the community to know it??
Thanks again
Manuel A. Garcia
Hi Manuel,
> how can i let the community know
You could make a "feature request" on the Moodle tracker and then try to get people to vote for it. If a lot of people vote for it, then the feature has a better chance of being added.
You could also make a post on the "language forum":
http://moodle.org/mod/forum/view.php?f=26
regards
Gordon
> how can i let the community know
You could make a "feature request" on the Moodle tracker and then try to get people to vote for it. If a lot of people vote for it, then the feature has a better chance of being added.
You could also make a post on the "language forum":
http://moodle.org/mod/forum/view.php?f=26
regards
Gordon
Here is an example of a hardcoded error that is seen more or less regularly by teachers but hardcoded in English: MDL-4294 (when student has no activity entries in the log, Moodle says that logs are not found -- not only it is always in English but also misleading).
I suspect that unless there is a major effort to weed these en masse, reporting individual instances is rather futile.
In terms of developer-specific errors, they indeed should be the only ones seeing them and only in rare circumstance; however, by nature of things, they are often enough seen also by end users not only site administrators.
As things are now, it is never clear whether such an error report is hardcoded as a result of lazines, oversight, or purposefully. What about if developers have to use a special function for reporting such errors once the module is going public?
a) it would be a clear indication from the programmer that the error is expected to be rare and causual user is not expected to see it, and
b) we can customize the reporting; for example, have the errors reported in the current language, if translation exists, but also always in English, and an annotation can be automatically inserted to suggest passing this error to site administrator. Additional information can also be possibly displayed.
c) having the erorr texts in separate language file would let translators use more technical language, if appropriate, when translating
This would also make the cleanup effort simpler.
I suspect that unless there is a major effort to weed these en masse, reporting individual instances is rather futile.
In terms of developer-specific errors, they indeed should be the only ones seeing them and only in rare circumstance; however, by nature of things, they are often enough seen also by end users not only site administrators.
As things are now, it is never clear whether such an error report is hardcoded as a result of lazines, oversight, or purposefully. What about if developers have to use a special function for reporting such errors once the module is going public?
a) it would be a clear indication from the programmer that the error is expected to be rare and causual user is not expected to see it, and
b) we can customize the reporting; for example, have the errors reported in the current language, if translation exists, but also always in English, and an annotation can be automatically inserted to suggest passing this error to site administrator. Additional information can also be possibly displayed.
c) having the erorr texts in separate language file would let translators use more technical language, if appropriate, when translating
This would also make the cleanup effort simpler.
If in doubt, the message should be translatable. I am sure that laziness has a lot to d with it.