[MMS] [Regression] After changing language all strings should be in new language

RESOLVED FIXED in 1.1 QE3 (26jun)

Status

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: borjasalguero, Assigned: gnarf)

Tracking

({regression})

unspecified
1.1 QE3 (26jun)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:koi+)

Details

(Whiteboard: MMS_TEF, )

Attachments

(2 attachments, 1 obsolete attachment)

Posted image Issue
Changing the language is not working properly for the composer-header. Check attachment.
Reporter

Updated

6 years ago
Summary: [MMS] [Regression] MMS Header is not localized → [MMS] [Regression] MMS Header in composer is not localized
Posted file Pull Request (obsolete) —
Attachment #767080 - Flags: review?
Reporter

Updated

6 years ago
Assignee: nobody → fbsc
This is a regression, leo+?
blocking-b2g: --- → leo?
Whiteboard: MMS_TEF, TaipeiWW
Assignee

Updated

6 years ago
Assignee: fbsc → gnarf37
Comment on attachment 767080 [details]
Pull Request

Corey is going to take a look because this is happening in other places as well.
Attachment #767080 - Flags: review?
We have detected that this is happening in more places, so Corey is going to take a look. Dietrich, this is a regression, leo+?
Flags: needinfo?(dietrich)
Summary: [MMS] [Regression] MMS Header in composer is not localized → [MMS] [Regression] Localization is not working properly in some scenarios
Reporter

Updated

6 years ago
Keywords: regression
Assignee

Updated

6 years ago
Summary: [MMS] [Regression] Localization is not working properly in some scenarios → [MMS] [Regression] After changing language all strings should be in new language
Assignee

Comment 5

6 years ago
There are many strings, generally the header in the messages view, the download mms strings, etc are all not properly localized when the language is changed while the app is running. I'm sure there are more as well

Updated

6 years ago
blocking-b2g: leo? → leo+

Updated

6 years ago
Target Milestone: --- → 1.1 QE3 (26jun)
Assignee

Comment 6

6 years ago
I'd like to argue for this not being QE3 - and also not being leo+

Are there many people who will be switching language with open applications and expecting everything to change immediately?  The app fixes itself after changing pages anyway.

Visibility seems pretty low, and complexity of the fix is fairly high (because it affects much more than just the header)

Renominating.
blocking-b2g: leo+ → leo?
Assignee

Comment 7

6 years ago
Comment on attachment 767080 [details]
Pull Request

Only solves one of the problem cases, and there are also better ways to solve.
Attachment #767080 - Attachment is obsolete: true
Assignee

Updated

6 years ago
Status: NEW → ASSIGNED
leo-, as most users will not change languages often, and as comment 6 notes that it can be fixed within itself after changing pages within the app.   renom if you feel otherwise with a comment.
blocking-b2g: leo? → -
Whiteboard: MMS_TEF, TaipeiWW → MMS_TEF,
Flags: needinfo?(dietrich)
Assignee

Updated

6 years ago
Depends on: 882591
This might be solved by the patch I’ve done for bug 898992:
https://github.com/mozilla-b2g/gaia/pull/11304

Corey, please ask me to review your patch if you work on this — or feel free to re-assign this bug to me.
Depends on: 898992
Assignee

Comment 10

6 years ago
(In reply to Fabien Cazenave [:kaze] from comment #9)
> This might be solved by the patch I’ve done for bug 898992:
> https://github.com/mozilla-b2g/gaia/pull/11304
> 
> Corey, please ask me to review your patch if you work on this — or feel free
> to re-assign this bug to me.

I'm using that work to fix this.  The problem is we do a lot of mozL10n.get(string) and stuff innerText with it.  Were we should be instead using .localize or .translate and setting the right l10n properties on the elements.  I'm just doing a giant audit of all our uses of l10n for this ticket to make sure we get all of the places.
Assignee

Comment 11

6 years ago
If you want to take a look at it - I've been pushing up my progress pretty much every major .js file -  https://github.com/gnarf/gaia/compare/886715
Assignee

Updated

6 years ago
Depends on: 902363
Assignee

Comment 12

6 years ago
Looking for feedback from kaze/rick, and review from julien on this pull.

Any other input also welcome - thanks!
Attachment #789138 - Flags: review?(felash)
Attachment #789138 - Flags: feedback?(waldron.rick)
Attachment #789138 - Flags: feedback?(kaze)
Comment on attachment 789138 [details] [review]
pull request on github

made a first pass but I have not looked at the test yet, neither tried it in the device. I keep this for tomorrow.

Reviewint this I've seen a lot of dialogs whose markup is inserted using JS whereas we could have it in index.html instead.
Comment on attachment 789138 [details] [review]
pull request on github

patch works well to me, but still some questions have to be answered regarding some functionality to be moved to l10n.js

Comment 15

6 years ago
Dear mozilla, marked koi? to make sure these issues ok for v1.2
blocking-b2g: - → koi?
Comment on attachment 789138 [details] [review]
pull request on github

r=me with the latest nit

check that the tests still pass locally before merging !
Attachment #789138 - Flags: review?(felash)
Attachment #789138 - Flags: review+
Attachment #789138 - Flags: feedback?(waldron.rick)
Attachment #789138 - Flags: feedback?(kaze)
Assignee

Comment 17

6 years ago
master: https://github.com/mozilla-b2g/gaia/commit/359b24a12724f1f8227e4d5b99a60bc3050846af
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
blocking-b2g: koi? → koi+
FTR, this patch introduces a new user-facing string (“view-attachment”) and should add it to the *.properties file. Filing a follow-up.
Depends on: 911709
Yeah, we eventually renamed it to "view-attachment-other".
Duplicate of this bug: 907551
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.