How to report validation errors in user friendly way

Hi Using schema.validate(tree) shows errors in english. To my users it is not very friendly way of problem reporting. What is the clever way to talk to user in his native language from validation routines? Or maybe I ask in other way: how to parse xml file after its validation, where validator told me where the errors are and I'd like to say to the user that the person xx has bad yy child (for example date). Assuming such xml structure: <persons> <person> <name>John</name> <date>2012-03-</date> - error </person> .... </persons> For me just printing the schema.error_log is ok, but not for the end user. Now I'm using validate() method but maybe assertValid() is the way to go? I'm not a programmer, the task I have done so far is take csv file translate it to xml file, write it and then validate it. And it is working fine. But doing user friendly program is tough task. So some guidelines are welcome. Thanx and regards Piotr

Piotr Oh, 11.04.2012 11:58:
Using schema.validate(tree) shows errors in english. To my users it is not very friendly way of problem reporting.
Agreed. However, there is a reason this has not been translated yet: it doesn't come for free.
What is the clever way to talk to user in his native language from validation routines?
Or maybe I ask in other way: how to parse xml file after its validation, where validator told me where the errors are and I'd like to say to the user that the person xx has bad yy child (for example date). Assuming such xml structure: <persons> <person> <name>John</name> <date>2012-03-</date> - error </person> .... </persons>
For me just printing the schema.error_log is ok, but not for the end user. Now I'm using validate() method but maybe assertValid() is the way to go?
Both are equivalent with respect to your problem above.
I'm not a programmer, the task I have done so far is take csv file translate it to xml file, write it and then validate it. And it is working fine. But doing user friendly program is tough task. So some guidelines are welcome.
I don't have a list of all the error messages available - they come straight out of libxml2. What you could do is to take the error codes that the error log gives you and write your own message for each of them, or rather a message template that formats a log entry (with line number etc.). There is a list of all error codes in http://xmlsoft.org/html/libxml-xmlerror.html#xmlParserErrors and also a copy in lxml's sources (available through the API). However, the corresponding error texts that you would have to translate are only in libxml2's sources, so you have to go through those manually to know what to actually translate. And specifically the XMLSchema validation code is tricky here, because it builds up the error messages from node information, so it's not like there's one message per error type... See xmlSchemaFormatNodeForError() in xmlschemas.c, for example: http://git.gnome.org/browse/libxml2/tree/xmlschemas.c#n2149 Note that the whole error reporting code below that function is several hundred lines long - error reporting is obviously the most important part of validation. The up side of the constructed messages is that they are nicely regular, so you could also use regular expressions to find e.g. the node names in them and use those in your translated message. Once you have all messages translated (and that's the true bulk of the work), put all error codes and their corresponding templates into a dict (preferably read from a resource file), look up the right one for each log entry and format it, e.g. with vars(log_line) for the fields. Stefan

On 04/11/12 14:11, Stefan Behnel wrote:
Once you have all messages translated (and that's the true bulk of the work), put all error codes and their corresponding templates into a dict (preferably read from a resource file), look up the right one for each log entry and format it, e.g. with vars(log_line) for the fields.
And it'd be very nice if were to have this work happen in the open, as we many people would step in to maintain it, or do translations, etc.
participants (3)
-
Burak Arslan
-
Piotr Oh
-
Stefan Behnel