[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KIO/KHTML Error Handling Update
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-27 14:50:29
[Download RAW message or body]

>The problem / the part that annoyed me is that I can not revert it anymore
>because the i18n-extraction was just running at the time you committed so it
>was immediately picked up.

Sorry, this won't happen again.

>> important and interesting things to do. As I see it, kio will only produce
>> more useful and specific error messages when the meaning of errorText can
>> be better defined than it is now (be that a per-error definition or a
>> general "additional information about the error" definition).
>
>Yes, but KIO can not give them a better meaning. Only the application and
>the specific protocol slave could.

In that case, we could either:
1) define more specific error codes, in addition to the current list, or
2) require the ioslave to use ERR_SLAVE_DEFINED for the more obscure errors. I 
think this error will define errorText to be a % separated list of 
description, causes and solutions, to be compatible with the current scheme.

sound good?

>> translated... in the end I think the i18n() calls are a much better
>> solution because of the high rate of repetition.
>
>Yes, no doubt about that. but they're in kdelibs, and its about 980 lines of
>new fuzzys two days before a release. same i18n strings are combined anyway
>by gettext btw.

Here's where my brain wasn't turned on. I was under the impression that the 
translators had about a month before the release, ie. I was thinking it only 
had to be done in time for the final release :(  I think I got this idea from 
the no-new-i18n-commits after RC1.

I can think of two ways around this:

* The new error messages could be turned back off for this release to the old 
messages with a very small patch (possibly unless english is the selected 
language), and the translators could be informed that they do not have to 
translate these strings for this release.

* I could add a i18n( "TRANSLATORS: delete this string if you have translated 
these error messages" ), and fall back to the pre-existing, translated error 
messages if it is still length() > 1. I guess the extraction would have to be 
re-run however. 

>> Good point, I tried to avoid most of the braindamage and that's one of the
>> things I missed. Another is the use of the word server, as KIO isn't
>> necessarily talking to a server all of the time, though mostly it is.
>
>Yes. Your second patch doesn't make that much better. For one you hardcoded
>the amount of networking protocols in it - unacceptable.

David and I worked out a better solution for this in the .protocol files.

>Also I'm personally not so happy about the reasonings and solution advices,
>namely:
>
>- claiming its a hardware failure.

yes, that's gone in most of the cases in the latest patch, except for when a 
read or write failed, where the string details that it is an unlikely event.

>- claiming that starting konqueror as root will help in any way

These are cases where root privileges have a significant chance of being 
required, and it is explained why that is the case (low port numbers) and 
that it should only be done if the security implications are understood. I 
would expect these error messages to be rare though.

>- claiming that telling the remote server administrator will help
>  (who knows if its remote ? can be your local service as well)

I removed most of these and the rest will be determined from the protocol file 
flag about whether it was a remote/network service or not.

>while there are much simpler and more likely advises missing, like "try it
>again". IE has that nice refresh-link embedded in the page, I personally
>like that.
>of course you can only do that in khtml and not in the KIO error
>messageboxes.

I will check through for that. I will put the refreshes in however it will 
have to wait until the error routine knows which job it was performing. 
Refreshing only really makes sense for http get, and probably a few other 
protocols' gets aswell.

Hamish
[prev in list] [next in list] [prev in thread] [next in thread]