905869 - [Email][l10n] Localize XLIST/SPECIAL-USE Starred/Important/All Mail folder names on IMAP, English fall-back on lesser IMAP, ActiveSync servers

Status: RESOLVED WONTFIX

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

Description

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

Goal: Support localizing all automatically named e-mail folders regardless of the origin locale.  This is 1 of 2 clones of bug 893458 relating to the localization of e-mail folder names, created so the goal of the bug is very clear and people don't need to read through a lot of debate.  This is the "easy" bug which does not require building a database of all possible localizations of given folder names.

Here's what we will do:

- Create localized strings for Starred[1], Important, and All Mail folders.  (We already have localized strings for Inbox, Sent, Drafts, Trash, Unsent, Junk, Archives, and Local Drafts.  Local Drafts is an us-only thing.)  The current localized string prefix is "folder-".

- For all folder types but 'archive' (indicated by the \Archive SPECIAL-USE flag) we will always use our localized string name for the given folder type unless the folder's parent has the same type as it.

The reason for the parent constraint is that it's conceivable that clients or servers may decide that any sub-folders of the root 'Sent' folder should themselves be marked as sent folders.  Same for drafts, etc.  Because we flatten the folder hierarchy when sending data to the front-end, this needs to be somewhat pre-computed; it might be best to distil; this to a 'don't auto-localize' flag.

The reason for not localizing 'archive' folders is that all other folder types are reasonably well defined and can be expected to be singleton folders or hierarchies.  More specifically, gmail does not use the \Archive flag (their \All folder is their archive folder), so there's no one leading the way/defining the idiom.  In Thunderbird we do time-based archiving (except on gmail) for scaling reasons; and it's known that there are users who archive based on sender, etc.  It would be particularly bad if we displayed those time-based folders or person-based folders all as "Archive".

- For IMAP servers not supporting XLIST/SPECIAL-USE or showing no indication of having SPECIAL-USE flags applied, we will guess folder types based on a hard-coded list of English strings.  We already do this for drafts/junk/sent/trash/queue based on Thunderbird's behaviour in ImapAccount._determineFolderType.  This would mainly mean adding more strings and potentially changing our fallback inference to not trigger when we believe we have good typing available.

- For ActiveSync servers, do the English-detection thing to detect folder names that do not have an explicitly defined 'Type'.  The only folder type that ActiveSync seems to provide that lacks an enumeration is the 'Junk' folder, and we definitely know what that is.  We'll want to make sure that if Exchange servers surface any other special folders that we add hard-coded strings.

(For comparison, our current approach is basically what Thunderbird does.  We try and use the XLIST/SPECIAL-USE type information if it exists.  If there is no explicit type, we use hard-coded english strings to infer a type.  Then at run-time we only localize the string (using MailAPI.l10n_folder_name) if the folder folder's name matches a short-list of hard-coded english strings and that is consistent with the type we decided the folder was.  This works out better than you would think because the set of English folder names to use became a de facto standard pretty quick.)


1: Starred is a complicated issue for what actual string to use.  Google calls their folder "Starred" in English, but it is for messages carrying the \Flagged keyword/flag.  gmail uses the 'star' nomenclature everywhere.  Under the hood, our implementation refers to everything as stars because that's how Thunderbird's UI surfaces things and what our initial UX wire-frames called for.  We now use a "flag" iconography in the e-mail app.  Since we are going to change to forcing the localization of the string, it seems like no matter what we do, there's going to be a problem with it.  I'm needinfo-ing robmac to make a decision on what the English string should be which should also inform our L10n note.

Comment 2

[Rob MacDonald [:robmac]]

Hi Andrew - Please IRC me on this one as I'm not completely sure I understand the issue. Thanks!

Comment 3

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

Discussed with :robmac on IRC.  The conclusion is that we will call the folder "Flagged".

I created a wiki page at https://wiki.mozilla.org/Gaia/Email/UX/Decisions to document axiomatic decisions like this.  (Axiomatic in the sense that there's no obvious correct answer on using stars versus flags, but once we make that decision, a lot of other decisions flow from that.)

For the time being I think we'll keep the back-end using isStarred/etc. in the code because there is inherent terminology ambiguity around flags since \Flagged itself is a "system flag" per RFC 5301 (like \Seen) whereas if you refer to starred messages, people will probably know what you're saying thanks to the ubiquity of stars in mail UIs like gmail and Thunderbird.

Comment 4

[Josh Schmitt [Joshs]]

Attachment: Yahoo.png

Issue also occurs on a Yahoo.com account in the email app. The word "Notes" is not localized in Bengali however other words are localized correctly. I have included a screenshot of the issue called "Yahoo.png"

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140204004001
Gaia: f9a37c77efb4621a1f57e4695b497d18601fe134
Gecko: 3d9d920ca43b
Version: 28.0a2
Firmware Version: V1.2-device.cfg

Comment 5

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

(In reply to Josh Schmitt from comment #4)
> Issue also occurs on a Yahoo.com account in the email app. The word "Notes"
> is not localized in Bengali however other words are localized correctly. I
> have included a screenshot of the issue called "Yahoo.png"

This sounds like the Yahoo.com account was used with an iOS device where the "Notes" sync option was enabled for the account.  While Yahoo Mail does expose a "notepad" app, it does not sound like it uses IMAP for storage itself.  I definitely don't see a Notes folder in my Yahoo IMAP account, even after I use the notepad app from the webmail interface to create some notes.

Since iOS devices are ubiquitous it could make sense to localize this too, but there's no SPECIAL-USE flags that would cover it, so it'd always have to be a specialized fallback case.  As such we probably want to treat that as a separate enhancement request to handle Apple products using IMAP as a storage medium for Notes and anything else they do.  (There's unlikely to be a situation where localizing a folder named "Notes" to another language will be exceedingly bad, but it would need its own code-path and could also merit other special treatment, so it's out of scope for this bug.)

Comment 6

[Andrew Stole [:astole]]

Attachment: Bulgarian_Outlook.png

This issue also occurs in Bulgarian on an Outlook.com account. The words "Archive" and "Junk" are not localized like the other folder names. I have attached the screenshot "Bulgarian_Outlook.png"

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140205004002
Gaia: 3405c205cfb5625073b9db1e12ed5d173bdcc78c
Gecko: 2c7f237ba88b
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 7

[Bingqing Li]

This issue also occurs in Simplified Chinese on gmail account and outlook account.

[Gmail] 
The words "Starred", "Important", "Sent Mail" and "All mail" are not localized.

[Outlook]
The word "Junk" is not localized.


Environment:
Gaia      f9a37c77efb4621a1f57e4695b497d18601fe134                         
Gecko     http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b   
BuildID   20140203004001                                                   
Version   28.0a2

Comment 8

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

Note: I just discussed some of this with :awiss in the context of bug 1005760 and the relevant (lightly edited) excerpt is:


So, I think in summary we want to do the following 3 things:

1) introduce a new folder type "all" and stop conflating it with "archive".  map "all"/"allmail" to "all" and leave "archive" as "archive"

2) make determineFolderType have slightly more expansive heuristics to cover what mailapi.js is already doing.  This may need to be partially factored out so ActiveSync can use it too

3) If it's a special type (other than "archive"), we should just use a localized string.  (But leave "archive" alone since at least Thunderbird uses it in a way that would be wrong for us to show "Archive")

Comment 9

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

As an addendum to comment 8, also see my comments in https://bugzilla.mozilla.org/show_bug.cgi?id=855198#c14

Those comments primarily relate to point 3; instead of it being an always-used string, we should have a boolean that decides whether we use it.  Currently we'd use the existing heuristics.  Note that that bug may take care of most of these points.

Comment 10

[BMO Automation]

Firefox OS is not being worked on