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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: sync-1, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

328.21 KB, text/plain
Details
70.26 KB, image/x-png
Details
(Reporter)

Description

5 years ago
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:
(Reporter)

Comment 1

5 years ago
Created attachment 792006 [details]
PR log
(Reporter)

Comment 2

5 years ago
Clone from brother
(Reporter)

Comment 3

5 years ago
Created attachment 792007 [details]
PR pic
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.
Blocks: 906580
Priority: P1 → --
Summary: [Buri][Translation][Email]The word "IMAP settings" and "SMTP settings" do not be translated → [Buri][Email/UI] settings_account card: The strings "IMAP settings", "SMTP settings", and "ActiveSync settings" are not dynamically re-translated on language change

Comment 5

5 years ago
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
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.
(Reporter)

Comment 7

5 years ago
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!
(Reporter)

Comment 8

5 years ago
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!
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.
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.