Comment 1 Andre Klapper 2009-02-03 16:02:49 UTC

Does this error id also exist in Fremantle (if you have access)?

it was in fremantle sometime this year. but they're abusing a generic error for
a specific thing.

(In reply to comment #0)
> I'm trying to translate modest. Shipping modest doesn't use this string.
> 
> 3244 } else if (error->domain == TNY_ERROR_DOMAIN && 
> 3245 error->code == TNY_SERVICE_ERROR_STATE) { 
> 3246 /* This means that the folder is already in use (a 
> 3247  message is opened for example */ 
> 3248 message = _("emev_ni_internal_error"); 
> 
> I'd much prefer modest include an untranslated error string than this one.

Why? That is the proper error message for this case. Basically because
TNY_SERVICE_ERROR_STATE means that tinymail is still holding a reference to an
internal tinymail object that prevents that operation to happen because that
object could not be unref'ed. Do you think it's better to say this to a final
user?

> I could translate 'Error occurred' as 'Folder in use', although I'm tempted to
> translate it as "Please file a bug, modest sucks".

As I said "folder in use" won't mean anything for the final user because it's
something absolutely tied to the current implementation of tinymail.

BTW: don't see the point of translating something that "sucks". If you really
think that, choose another project.

error messages which end users encounter but can't understand hurt their
ability to use the product.

so do all strings which are impossible to decipher. i'm in the process of
making a translation of the entire product (you can try it, it's in diablo's
extras-devel atm).

if you know what the problem is, and if you know of a solution (e.g. "to fix
this, you will have to restart Modest"), then your string should reflect that.

Does "Internal error" always mean "Restart modest"?

This is a user facing component. And the quality of the error messages
seriously detracts from users' ability to use it and from my ability to improve
their experience.

(In reply to comment #4)
> error messages which end users encounter but can't understand hurt their
> ability to use the product.

internal error means internal error. We only show it when we cannot show
another message. That should never happen, but if it happens, then we prefer
not to show that instead of a message that it's impossible to decipher.

> if you know what the problem is, and if you know of a solution (e.g. "to fix
> this, you will have to restart Modest"), then your string should reflect that.
> 
> Does "Internal error" always mean "Restart modest"?

No. As I said that's an unexpected error. Should never happen but it could.

> This is a user facing component. And the quality of the error messages
> seriously detracts from users' ability to use it and from my ability to improve
> their experience.

Of course, but I repeat again, that error should never happen. If we show it
it's only because we have no other information about what happened, and how to
fix that situation.

Comment 6 Andre Klapper 2009-04-01 15:29:11 UTC

WONTFIX as described by developer.

Comment 7 Andrew Flegg 2009-04-06 10:53:32 UTC

There's still a case for explaining to the user what to do. Is the internal
state brokenness something that *will* be fixed by restarting modest? If so,
the message should state that.

If nothing else, it should probably say something like:

   "Internal error 4. Please raise a bug"

That would allow a bug report to contain enough information to track down
exactly which "Internal error" may be at fault.