1. Title : Changed Language is not reflecting in the Email App 2. Precondition : Email should be working 3. Tester's Action : Phone Settings -> Languages -> Change to some other language -> Go to Email App -> Email app reflected with modified language -> Press Home Button -> Go to Languages-> Change to English -> Long press Home -> Go to Email App 4. Detailed Symptom (ENG.) :Email App shows in the old language only. It did not reflect to changed languages 5. Expected : Email app should reflect to new language that is modified. 6.Reproducibility: Y 1)Frequency Rate : 100% 7. User Impact: User will not be seen in his lanaguage without killing the email app and relaunch. 8.Gaia Revision: d2a68bc3c26312bbd70c926aedbdef0fc972805e

Hi Andrew, We are listening to 'localized' event while starting the email application and initializing the strings. When we are loading from background we just push the card from stack (Or Memory). I thought of taking the localized event even in the background. But there is no way to update on card as resume did not interface with the application. Please suggest if you find any solution to this issue. Thanks, Praveen.

It seems like there are 4 different sets of possible issues: 1) Localize visible cards with static l10n id's set 2) Localize our template cards with static l10n id's set for future card display 3) Re-computer our mozL10n.get() calls 4) Strings send to the back-end that need to be refreshed. It seems like 1 and 2 should already be working for us, but 3 and 4 are new work, but from your comments, it sounds like nothing is working? To address 3, in many cases we could simply just change our use of mozL10n.get to instead update the dataset on the node in question and have mozL10n re-localize the element instead. In cases where the text to display is somewhat more modal, we may need to either change to having 2 or more span's that are conditionally displayed based on CSS, or have/use/introduce some type of l10n macro to let mozL10n parameterize on a non-numeric argument. Case 4 seems pretty straight-forward; just re-fetch and re-send those string bundles when localized, possibly requiring a small new API call.

It is possible to have the language stuck even when force closing the app if an error message is produced: Repro Steps: 1) Updated Buri/Inari/Leo/Unagi to BuildID: 20131127004001 2) Choose Czech when selecting a language. 3) Go to the email app and enter an invalid name, email, and password (make sure the email is in the correct format something@something.com etc) 4) Observe the error message in Czech 5) Go to settings and change the language back to English. 6) Open the email app again. It will still be in Czech 7) Force close the email app by holding the HOME button and swiping the app up. 8) Re-enter the mail app and observe that the error still displays in Czech. This screen will remain in Czech even when clearing the error or switching to a different page in the app.

The current scenario for this issue is as below. STR: 1. Launch Email 2. Email Compose 3. Home button long press 4. Change the language from settings 5. Relaunch Email 6. Compose screen shown with the new selected language 7. Click back 8. Message box screen shows old language only Expected: Message box locale should be as per the new language selected. Note: even if compose again, compose locale also old language. Is comment #2 is still valid. How do we approach to fix this issue. Please provide your input.

We've landed a bunch of stuff related to this recently, :jrburke and :awiss are best able to further triage this bug.

As I see the recent issues related to language landed on master are https://bugzilla.mozilla.org/show_bug.cgi?id=1005760 https://bugzilla.mozilla.org/show_bug.cgi?id=1022941 The issue mentioned in Comment #4 is still reproducing on Mozilla master. The changed language is not stored anywhere in the application , whenever language is changed the current DOM is getting updated. If any new card is opened, it is getting opened with old languages only. Anyway .. waiting for jrburke comments on this issue.

I tested master with this Gecko/Gaia combo: Gaia dfc4703bb81d1fa4f2087a1a6124b47a80a5d1de Gecko https://hg.mozilla.org/mozilla-central/rev/80431d4fd0da BuildID 20140616040202 Version 33.0a1 and the case in comment 4 is the list of folders used in the email app are not updated by the localization change. The header in the message list shows one of those names, in the case I tested, "Inbox". However, other parts, like "last sync" time, the timestamps on the messages in the message list and the search text box placeholder are localized. So I believe the last part of the work is to get dynamic language changes to affect the default set of folder names used. :awiss, :asuth and I talked briefly about this in IRC, but unfortunately did not save the full results. Will ping :aswiss if he recalls more details, but parts of the story: api.useLocalizedStrings is called to set the localizations: https://github.com/mozilla-b2g/gaia/blob/a37cc0f702a63a9c1a2a6f2fe312571c13c87589/apps/email/js/mail_app.js#L106 and then the model module gets a foldersSlice with the localized names, and those names are used in the UI. So that flow of data, including on the backend, needs some extra work. As I recall, :asuth indicated there is a bit more work than just a manual propagation of a new locale. At the very least, the model module likely would need to account for this change. One possibility is to put the localized names in the localization files, and use mozL10n.get() on the DOM elements for these items instead of using data coded from the back end. However, we likely need to do a bit more work than that, and it would be nice to make it clear to have just one owner of that information.

I did find an issue where the fix in bug 1005760 missed the build case, and I missed that in review. I filed bug 1026296 to fix that issue.

Related secondary folder name bug: bug 905869

I can briefly recall the issue :asuth brought up. I don't remember it perfectly, but I think the basic idea was that translation required a one-to-one relationship between folder type and folder names. This would mess up some edge cases with certain email clients, seen here: https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/d3213027b9db96348fee3e2c5deb11ebf80fea94/data/lib/mailapi/mailapi.js#L3487

Wayne! Please check this issue at triage meeting.

putting this to 2.0? as request by partner. Have we improved on the language switch experience yet? On 1.0/1.1 some apps needs to be killed and launch again for language switch to take effect.

Language switch experience has recently been improved on bug 1022941, bug 1005760, bug 1034227, and bug 1024856. Related bug 1026296 has been mooted by platform changes. This bug, as noted, is only about special localized folder names. Other small improvements probably happened post-1.1; that's a big time span. I think basically all of those bugs have only been fixed on v2.1. It seems like live language change likely constitutes an explicit non-blocker case of "Issues requiring the user to perform extremely uncommon use cases" as listed at https://wiki.mozilla.org/B2G/Triage#Issues_that_Should_Not_Block since a language should be chosen at FTU time that the user can read and restarting the app and/or device. Having said that, 2.0 appears to still be taking approval requests, so we could try to uplift those appropriate for 2.0 and fix this one if this is believed to be an important issue.

(In reply to James Burke [:jrburke] from comment #7) > One possibility is to put the localized names in the localization files, and > use mozL10n.get() on the DOM elements for these items instead of using data > coded from the back end. However, we likely need to do a bit more work than > that, and it would be nice to make it clear to have just one owner of that > information. We want to directly set the data-l10n-id in any case where we would currently be using .get() or using data that previously came from .get() (such as being passed-through useLocalizedStrings.) (In reply to Alex Wissmann [:awiss] from comment #10) > I can briefly recall the issue :asuth brought up. I don't remember it > perfectly, but I think the basic idea was that translation required a > one-to-one relationship between folder type and folder names. This would > mess up some edge cases with certain email clients, seen here: > https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/ > d3213027b9db96348fee3e2c5deb11ebf80fea94/data/lib/mailapi/mailapi.js#L3487 Your memory sounds right (through graphy glasses! ;), but I'll elaborate on my original thoughts since I also have some new ones. * We effectively want to decouple the meta-data about a folder from the desire to use a localized string we provide for the folder. The example scenario I used here was for hierarchies of folders. For example, Thunderbird can produce an Archives Hierarchy of the form "Archives/YYYY/YYYY-MM". Someone very organized might have a bunch of Sent folders (Sent/Work, Sent/Personal, etc.). Someone very organized using a bayesian classifier may have multiple junk folders in a hierarchy or in parallel. Deleting folders of messages is usually mapped by moving the folder (and its children) into the Trash folder, which may or may not mark that folder itself as trash. We want to decouple them because it is counter-productive and frustrating to the user if their intentionally named folders get displayed with the generic localized names. It's also silly to have 5 sibling folders all named "Archives". The mailapi.js#L3487 :awiss links to is our current approach of dealing with this situation; we try and only localize the very generic names. * A lot of the complexity here comes from some servers giving us explicit folder meta-data via XLIST/[LIST SPECIAL-USE]/[ActiveSync's very limited set of enumerated folder types] and from us sometimes just looking at the folder name. Our folder sync logic for IMAP uses both the explicit stuff and the inference stuff, but does not distinguish how it arrived at that. * A related and complicating issue is that we also use the folder types like we assume there will only be one folder with that folder-type, or that at least the first one we find is the right one. We use this logic for moving to trash, appending to the sent folder, and saving to local drafts. This was largely a hack. Thunderbird actually has UI to let you name the specific folder to use for purposes like this. So what do I think we should do about this? * From the UI's perspective (and as discussed on IRC), I think we want to expose a boolean "useLocalizedName" on each MailFolder. I'd probably also suggest that we create a getter called something like "l10nKey" which currently is just an alias to the folder type. * If we want a very baby-steps fix, we just do the above and do it by reusing the l10n_folder_name logic :awiss linked to. We just return the boolean instead of the string type. * A less baby-steps fix is to actually store such a boolean on the folder info and push the l10n_folder_name logic into our folder classification/identification logic in the back-end. * More thoroughly addressing the problem would be to beef up our heuristics in the back-end and potentially address the issue of deciding on target folders by marking canonical folders or an explicit "use this folder map". These are somewhat more non-trivial so I think I'll just call this follow-up bug fodder and we'll worry about it then. (Especially since I don't think we've been running into hierarchies where our current guessing fails. The most likely thing for us to run into is generic folder names in non-English languages, but that requires compiling a bit of a database or finding a license-okay way to use the existing available ones.)

(In reply to Wayne Chang [:wchang] from comment #12) > putting this to 2.0? as request by partner. > > Have we improved on the language switch experience yet? On 1.0/1.1 some apps > needs to be killed and launch again for language switch to take effect. Wayne, given this is a long standing issue and we've shipped with this in past releases I do not think we would block on this for 2.0. If there is a low risk fix available before July 21(FC), we can consider uplift, else we will have to consider this feature request in a future release.

Firefox OS is not being worked on