1008904 - [email/UI] Stop showing raw, untranslated/unlocalized account setup error codes

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[yang.zhao]

Attachment: Offline.JPG

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19

Steps to reproduce:

Step1:-Go to setting.
Step2:-Go to Language.
Step3:-Select other languages except en-US,such as Hindi.
Step4:-Go to Email-> enter Email id & password->then click Next
Step5:-the error message dispalys 'offline' in English,not in Hindi.


Actual results:

'offline' doesn't be translated


Expected results:

'offline' should display in language you choose.

Comment 1

[yang.zhao]

I found it is errorCodeNode in setup_account_info.js in email:
showError: function(errName, errDetails) {
    ...
    var errorCodeNode =
      this.domNode.getElementsByClassName('sup-error-code')[0];

    // Attempt to get a user-friendly string for the error we got. If we can't
    // find a match, just show the "unknown" error string.
    var errorStr = mozL10n.get(
      SETUP_ERROR_L10N_ID_MAP.hasOwnProperty(errName) ?
        SETUP_ERROR_L10N_ID_MAP[errName] :
        SETUP_ERROR_L10N_ID_MAP.unknown,
      errDetails);
    errorMessageNode.textContent = errorStr; 

    var errorCodeStr = errName;
    if (errDetails && errDetails.status)
      errorCodeStr += '(' + errDetails.status + ')';
    errorCodeNode.textContent = errorCodeStr; 


hi,Evelyn:
    From the above code ,you'll find 'errorCodeNode' may include 'errDetails.status' content.Do you have any good idea about this issue? Thank you very much and looking forward to your reply ASAP.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

moving to the right component L10n -> Email.

Comment 3

[Evelyn Hung]

(In reply to yang.zhao from comment #1)
> I found it is errorCodeNode in setup_account_info.js in email:
> showError: function(errName, errDetails) {
>     ...
>     var errorCodeNode =
>       this.domNode.getElementsByClassName('sup-error-code')[0];
> 
>     // Attempt to get a user-friendly string for the error we got. If we
> can't
>     // find a match, just show the "unknown" error string.
>     var errorStr = mozL10n.get(
>       SETUP_ERROR_L10N_ID_MAP.hasOwnProperty(errName) ?
>         SETUP_ERROR_L10N_ID_MAP[errName] :
>         SETUP_ERROR_L10N_ID_MAP.unknown,
>       errDetails);
>     errorMessageNode.textContent = errorStr; 
> 
>     var errorCodeStr = errName;
>     if (errDetails && errDetails.status)
>       errorCodeStr += '(' + errDetails.status + ')';
>     errorCodeNode.textContent = errorCodeStr; 
> 
> 
> hi,Evelyn:
>     From the above code ,you'll find 'errorCodeNode' may include
> 'errDetails.status' content.Do you have any good idea about this issue?
> Thank you very much and looking forward to your reply ASAP.

It seems we should localize these errDetails.status.

Comment 4

[James Burke [:jrburke]]

This is coming from the "errName" argument in that showError function, and I believe the idea is that those are more like codes, not meant to be user-readable, but more something to give to support, for looking up a problem in a common set of problems indexed by code name. Asking :asuth for some more background though.

That said, I can see where it would be less confusing for this kind of common error, the user being offline, to have that show up in a different language, even though it is meant to be treated more like a code.

Perhaps we could modify setup_l10n_map to return three sets of translation IDs:

* the set for a pretty message (the set that is in there now)
* a set for errName
* a set for errDetails.status

And the ones that are more numeric, or may come from the mail server for example (which are likely the errDetails.status?), those would not find a match, and would print out as they do today.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

tl;dr: let's just stop displaying the error code.


My original rationale and insistence on having the error code was derived from the following intersection of things:

1) The belief that we would turn off our logcats in production builds eventually and that secret debug logging mode would be onerous for people.  (:cjones had logged a bug about us turning them off for performance.)

2) Bugs kept getting filed where the only information provided with one of: a paraphrasing of the error message; a manually re-typed version of the error message; a screenshot.

3) Account creation failures were much more common initially, especially since typos seemed disturbingly common.

4) The belief that this would be helpful to users trying to figure out what was going on and would be superior than exposing a random numeric error code.  And that it wasn't on the cards for us to hyperlink 

5) Limited screen real estate.  I didn't want us to have to carve things up with a full string like "Error code: offline" since then the font would need to be larger, etc.  If we did it in big parens on the actual string, it would definitely look weird.


The following things have changed.

- At some point it became apparent that logcat logging is our best option for debugging email and so we are never going to turn it off.  This moots point 1 which was a key one.

- Bug-filers are now much better about providing logcats, mooting point 2.

- Account failures are less common now, point 3.

- The on-screen error codes haven't been as useful as I was expecting.  Mainly because we get logcats or the failures we are seeing require more context that only the logcat can provide.

- We are getting a lot of bugs filed about the error codes not being translated.  Which is fair.

- Screen real estate may actually be in shorter supply now.  I think when we originally introduced this mechanism we might have still required the user to hit the back button to go back to the login screen so we had more space available?

- Support requests have started to happen, but they are coming via the support.mozilla.org infrastructure which I think will be able to handle the necessary clustering around the error types.

- We can/should just provide a link that can bring the user to an appropriate support page, possibly with JSON-crammed meta-data.


James, does this seem reasonable to you?

Comment 6

[James Burke [:jrburke]]

That sounds good to me. The suggestion for a longer term ability to just hyperlink the error to a help page is likely better anyway, and as you say, the logcats have been the actual useful thing in practice.

I will take this bug and just remove the sup-error-code div and any code associated with dealing with it as the fix for this bug.

Comment 7

[James Burke [:jrburke]]

Attachment: GitHub pull request

Just remove the error code display.

Comment 8

[James Burke [:jrburke]]

Merged in master:
https://github.com/mozilla-b2g/gaia/commit/50220bbd93b03567bbc18dcc4a381a8c474de339

from pull request:
https://github.com/mozilla-b2g/gaia/pull/19515

Comment 9

[yang.zhao]

v1.3t pull request:
https://github.com/mozilla-b2g/gaia/pull/19518

Wait for the Travis CI build.

Comment 10

[yang.zhao]

v1.3t commit:61ad95a84defe941eb687f94191d57e63aaa007c

Comment 11

[Dylan Oliver [:doliver]]

Marking this 1.3T+ since it was already taken in the  branch.