906569 - [Buri][Email/UI] settings_account card: The strings "IMAP settings", "SMTP settings", and "ActiveSync settings" are not dynamically re-translated on language change

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
 Firefox os  v1.1
 Mozilla build ID:20130806071254
 
 Created an attachment (id=459600)
 PR pic
 
 DEFECT DESCRIPTION:
 The word "IMAP settings" and "SMTP settings" do not  be translated
 
  REPRODUCING PROCEDURES:
 1.There have created a account
 2.Go to Email settings->select the account->press center key
 3. Go to Settings->Language->Fransh->OK->press center key
 4.Go to Email,you will find "IMAP settings" and "SMTP settings" do not be translated->KO
   
  EXPECTED BEHAVIOUR:
 The word "IMAP settings" and "SMTP settings" should be translated
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 mid
  REPRODUCING RATE:
 5/5
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: PR log

Comment 2

[sync-1]

Clone from brother

Comment 3

[sync-1]

Attachment: PR pic

Comment 4

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

The strings are localized, they just don't get dynamically relocalized.  If you close the e-mail app before changing the language, then re-open the e-mail app, you'll see the strings are properly localized.

I've created a meta bug to track this general problem and set this bug to block it.  There's no need to create bugs to track all of the other string uses at this time, but if they get created, they should also blog the meta bug 906580.

Comment 5

[buri.blff]

Hi,
I found it's need to set the data-l10n-id value for the node.There are many dynamic updating nodes at Email app. Can you give a patch about the problem!
such as:
  node.textContent = mozL10n.get("settings-id");
  node.setAttribute('data-l10n-id', 'settings-id'); //!!!it's need to add this line

Comment 6

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

As noted on bug 906580, we should just be using localize/localizeNode directly.  Dynamic language changes are currently lower down the list of priorities since the operation is not critical to the operation of the e-mail and we've got a lot of functionality bugs open right now, so if you can provide patches, that would be ideal.

Comment 7

[sync-1]

Hi,
   I found we should not just be using localize/localizeNode directly when the localize string contains "{{xxx}}". In the case, we can only update the text of node by the "mozL10n.get()" interface.
   Many apps have the same problem on FFOS. It's poor at experience of user. We should find a good approach to deal with it.
   Could you give some suggestion about the problem.Thanks!

Comment 8

[sync-1]

Hi,
   I found we should not just be using localize/localizeNode directly when the localize string contains "{{xxx}}". In the case, we can only update the text of node by the "mozL10n.get()" interface.
   Many apps have the same problem on FFOS. It's poor at experience of user. We should find a good approach to deal with it.
   Could you give some suggestion about the problem.Thanks!

Comment 9

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

Thanks for your interest in helping fix this problem!

The signature for localizeElement is: function localizeElement(element, id, args) 

The code in question is here:
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/l10n.js#L1118

So if our bad code looks like this:
  elem.textContent = mozL10n.get(id, args);
or this:
  elem.textContent = mozL10n.get(id);

Then we would want to convert it to:
  mozL10n.localize(elem, id, args);
or (as appropriate):
  mozL10n.localize(elem, id);


Note that the method is a somewhat newer addition (landed on v1-train and master at the end of June) made in bug 882591.

Comment 10

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

At some point in other bugs we changed to dynamically compute and set a data-l10n-id so the l10n logic will dynamically re-localize these on language change.