Currently, some strings that result from querying/setting of MMI codes through the dialer are only in English. This bug is to track the strings to be localized for MMI codes.

Dietrich, this change adds the properties file for MMI strings. Not sure if I've added the correct reviewer here. Just found someone who's reviewed similar properties file in the past. Please correct the reviewer field if there should be someone else that I should have added.

Comment on attachment 757716 [details] [diff] [review] Add MMI properties file Review of attachment 757716 [details] [diff] [review]: ----------------------------------------------------------------- You probably didn't mean to ask me for review on this.

Needs review from either a l10n or RIL person or both.

Comment on attachment 757716 [details] [diff] [review] Add MMI properties file Or Stas or Kaze might be able to review, so I pinged them as well.

Comment on attachment 757716 [details] [diff] [review] Add MMI properties file Review of attachment 757716 [details] [diff] [review]: ----------------------------------------------------------------- This is OK in principle, but we're not set up to take locale changes on gecko for b2g-18. We wouldn't be able to use these strings until the current gecko version made it through the trains and a fxos release included them. I'm not convinced that setting things up for b2g-18 is in scope for 1.1, and it's a lot of process on various folks like dev infra, hg repos, git mirrors, releng setup, l10n dashboard setup etc to get there. Note, I only see this file existing, but not actually being used, to it's hard to tell what the strings do. I'd also prefer a UX person to review the copy.

Axel, this MMI properties file would be used by commercial RIL and that is why you don't see it being used in b2g-18 code. This change in response to several leo blocking bugs and so should be leo+ as well. Please see the "blocks" field on the top of the CR. Commercial RIL supports various MMI codes which open source RIL doesn't and so we need this file to be localized to meet the requirements set by our Leo partner. So even if open source RIL now adds support for the missing MMI codes, we would still need these translation to be done, if not in this file then in Gaia.

If you can do it in gaia, the chances of making it in the given schedule are better.

Axel, we would need to push a lot of logic from RIL to Gaia to properly handle all the success/error cases for all the MMI codes. And so I feel it is a very risky change to be done in Gaia at this time for 1.1. Just curious, how is localizing this MMI properties file vs the same strings in some Gaia file (perhaps telephony_properties.js) and different in terms of effort and meeting the schedule?

Please see my comment 5. There's nothing yet in terms of infrastructure to take strings on gecko 18.

Carol is looking to see if we can get at the strings from Gecko if we shoved them in Gaia for v1.1. Might not work, and a little backwards. If we agree that gecko is the place for these strings for master, then for v1.1 we could also land the strings in gaia solely for the purpose of localizing and throw together a simple build-time hack to copy the strings from gaia into gecko. So gross but maybe better than comment 5.

Comment on attachment 760020 [details] [diff] [review] Add MMI properties file Review of attachment 760020 [details] [diff] [review]: ----------------------------------------------------------------- I'd really like to help you here, but: 1). I have no idea how localization works in Gecko. Some names come up from git-log often: Unfocused, Jaws, etc. 2). I don't have a list to check whether you have done all the works needed to translate all strings. Besides, the most important of all, there is no reason Gecko should ever host any translations that don't belong to Mozilla (yet). Commertial RIL is Qualcomm's own proprietary re-implementation of Mozilla's. We don't include translation strings of oFono. We don't include translation strings of Samsung Exynos. So applies to Qualcomm.

Blocking since we assume it's required to allow MMI to be sent in various languages based on market.

(In reply to Michael Vines [:m1] [:evilmachines] (PTO till June 16) from comment #10) > If we agree that gecko is the place for these strings for master, then for > v1.1 we could also land the strings in gaia solely for the purpose of > localizing and throw together a simple build-time hack to copy the strings > from gaia into gecko. So gross but maybe better than comment 5. This sounds reasonable to me, given the timeframe. Note that the l10n format we use in Gaia is forward-compatible with Gecko’s *.properties files, so reusing them in Gaia will be straight-forward.

Having a quick glance at the MMI code in Gaia [1], it looks like we display directly the content of the `message' event in the UI (event.data.message / event.data.result). I’d be tempted to handle the whole MMI localization in Gaia (Gecko sending message identifiers, Gaia translating them), but I assume there’s a solid reason for having these strings in Gecko. To handle these additional MMI codes (= codes for which there isn’t any translation in Gecko), could we ensure that when Gecko sends the code itself? Then we could do some regexp matching in Gaia to detect whether event.data.[message|result] is an MMI code rather than a translated string, and translate this code directly in Gaia. Adding Étienne to the loop, as he’s worked on this for the Gaia side. [1] see `handleEvent()' and `showMessage' in apps/communications/dialer/js/mmi_ui.js: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/mmi_ui.js#L155

Redirecting the ni? to Fernando who will know better.

As Kaze suggested in comment 15, if we can send the message ID instead of the message to the gaia UI, that'd be the best solution.

Axel, are you proposing that we assign an unique identifier to the message in the mmi.properties file and sent it to Gaia. Gaia then would look it up and find the corresponding message in the current language file? That would work for us. Please let us know what we need to do.

Yes, to give an example, in your message to gaia, you'd send "scCallBarring" instead of "Call barring". I'd make a semantic to the structure of the message to make that obvious. You could even send both to be safe, the gaia code could try to resolve the semantic name locally, and use the English verbose string as fallback.

(In reply to Fabien Cazenave [:kaze] from comment #15) > Having a quick glance at the MMI code in Gaia [1], it looks like we display > directly the content of the `message' event in the UI (event.data.message / > event.data.result). > > I’d be tempted to handle the whole MMI localization in Gaia (Gecko sending > message identifiers, Gaia translating them), but I assume there’s a solid > reason for having these strings in Gecko. > I'd also prefer to handle these strings in Gaia and keep Gecko sending key (message identifiers) strings. We already do that in the RIL reference implementation [1] for the error cases but we have a lack of status message keys. Most of these error keys are not handled in the Gaia side though :\. IMHO we could probably: 1- Handle all the proposed keys in the Gaia side. 2- Change in the reference RIL the already existing error keys for the ones that Carol proposes in her patch. 3- Add as much as possible the missing error keys and status message keys for the supported MMI codes. I guess 2 and 3 are not really mandatory for leo but will ease the development of the Gaia side considerably. > To handle these additional MMI codes (= codes for which there isn’t any > translation in Gecko), could we ensure that when Gecko sends the code > itself? > Then we could do some regexp matching in Gaia to detect whether > event.data.[message|result] is an MMI code rather than a translated string, > and translate this code directly in Gaia. > event.data.[message|result] won't be triggered for not supported MMI codes. We return a not_supported_error_like key (i.e. [2] and [3]) via the .onerror callback from the DOMRequest returned by the calls to nsIDOMMobileConnection.sendMMI (or cancelMMI). Also "result" and "message" come from different paths, the first one is the DOMRequest.result, the second one is part of the nsIDOMUSSDReceivedEvent [4] that is reserved to USSDs and its content is filled by the USSD application on the carrier side that should always be translated (I guess according to the user's mcc/mnc). So we wouldn't need to worry about "message". We should only take care of Gecko/RIL results (errors or not). I can take a look at this during the next week if needed. [1] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#2166 [2] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#2327 [3] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#2332 [4] https://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMUSSDReceivedEvent.idl#10

(In reply to Anshul from comment #19) > Axel, are you proposing that we assign an unique identifier to the message > in the mmi.properties file and sent it to Gaia. Gaia then would look it up > and find the corresponding message in the current language file? > > That would work for us. Please let us know what we need to do. That's it. As I said in my previous comment, we already do that in the reference implementation for the error cases.

Comment on attachment 760020 [details] [diff] [review] Add MMI properties file Review of attachment 760020 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/locales/en-US/chrome/ril/mmi.properties @@ +58,5 @@ > +emMmiErrorStkCcSsSs=SS request is modified to new SS request > + > +# RIL errno > +rilErrnoRadioNotAvailable=radio not available > +rilErrnoGenericFailure=generic failure Some of these string keys already exists in the reference implementation [1]. We should probably use the same keys. Vicamo, can we change the few existing GECKO_ERROR_* keys and also add the missing ones? For example s/RadioNotAvailable/rilErrnoRadioNotAvailable at [1]. [1] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js#235

Thanks for the input Fernando! We can certainly send unique key strings up and have Gaia handle all the localization. Got a few questions based on the new suggestion though: 1) Currently, for most cases, we format the string to display as: <Service code> <Status/Error/Errno message> Adding the string representation of the service code before the status/error/errno messages helps with identifying which MMI code was just processed. Given Comment 21, can we also accommodate the service code? Perhaps we can send both pieces of information up as separate keys and Gaia appends them together? 2) As #1 stated, most cases are pretty simple in terms of the data to display. There are a few cases that are a bit more complicated. For example, if user is unblocking PIN1 using service code 05 and entered the wrong PUK1, the display would say something like: PIN change The PUK you typed is not correct Attempts Remaining: X Here, X would be a the result of a query down to RIL. Another example is when user queries Call Waiting status using service code 43. The current display would look like: Call waiting Service was enabled for: Voice Data ... What's the suggested method to take care of messages that are more than just service code followed by a status/error/errno message? In the call waiting case, there can be any number of call waiting services that have been enabled.

(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, please) from comment #23) > Add MMI properties file > Review of attachment 760020 [details] [diff] [review]: > ----------------------------------------------------------------- > Some of these string keys already exists in the reference implementation > [1]. We should probably use the same keys. Vicamo, can we change the few > existing GECKO_ERROR_* keys and also add the missing ones? For example > s/RadioNotAvailable/rilErrnoRadioNotAvailable at [1]. I think these aren't translatable strings. GECKO_ERROR_* are supposed to be used to create DOMError objects and should be some well known constant strings as defined in https://developer.mozilla.org/en-US/docs/Web/API/DOMError . But, yes, if there are translatable strings in ril_consts.js, the method Carol has here should apply. Thanks!

(In reply to Carol Yang [:cyang] from comment #24) > Thanks for the input Fernando! We can certainly send unique key strings up > and have Gaia handle all the localization. Got a few questions based on the > new suggestion though: > > 1) Currently, for most cases, we format the string to display as: > <Service code> > <Status/Error/Errno message> > Adding the string representation of the service code before the > status/error/errno messages helps with identifying which MMI code was just > processed. Given Comment 21, can we also accommodate the service code? > Perhaps we can send both pieces of information up as separate keys and Gaia > appends them together? We can do that, but it will require an extra change in Gecko. We'll need to return objects instead of strings in the DOMRequest.result. I'll file a bug for it. > > 2) As #1 stated, most cases are pretty simple in terms of the data to > display. There are a few cases that are a bit more complicated. For example, > if user is unblocking PIN1 using service code 05 and entered the wrong PUK1, > the display would say something like: > PIN change > The PUK you typed is not correct > Attempts Remaining: X > Here, X would be a the result of a query down to RIL. Another example is > when user queries Call Waiting status using service code 43. The current > display would look like: > Call waiting > Service was enabled for: > Voice > Data > ... > What's the suggested method to take care of messages that are more than just > service code followed by a status/error/errno message? In the call waiting > case, there can be any number of call waiting services that have been > enabled. All this information could be returned within the DOMRequest.result object that I mentioned before. For these 2 examples we could return objects like: { serviceCode: "scPin", statusMessage: "emMmiErrorBadPuk", attempsRemaining: 2 } { serviceCode: "scCallWaiting", statusMessage: "smServiceEnabled", serviceClass: ["serviceClassVoice", "serviceClassData"] } Each object would be different depending of the service code associated, but I guess all could have at least serviceCode and statusMessage. What do you think?

(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, please) from comment #26) > All this information could be returned within the DOMRequest.result object > that I mentioned before. For these 2 examples we could return objects like: > > { > serviceCode: "scPin", > statusMessage: "emMmiErrorBadPuk", > attempsRemaining: 2 > } > > { > serviceCode: "scCallWaiting", > statusMessage: "smServiceEnabled", > serviceClass: ["serviceClassVoice", "serviceClassData"] > } > > Each object would be different depending of the service code associated, but > I guess all could have at least serviceCode and statusMessage. > > What do you think? Yup, this sounds perfect!

Fernando, when can you start working on this bug so we can plan RIL side of changes accordingly?

I'll try to get into this early next week.

This patch adds most of the key strings proposed by Carol in her previous patch to ril_consts.js and make use of some of them for certain error cases. Please, note that most of these key strings will be used in some of the bugs blocked by this one.

This patch adds most of the strings proposed by Carol to the Gaia Dialer locales. These strings will be used in the bugs blocked by this one.

Comment on attachment 764783 [details] [diff] [review] Gecko part - v1 Carol, as you can see I added most of the strings that you proposed with these exceptions: 1- rilErrnoInvalidParameter, rilErrnoRejectedByRemote and rilErrnoUnrecognizedRilErrorNumber as they don't seem to be part of the standard RIL errors [1]. 2- I added scPuk and scPuk2. [1] https://www.codeaurora.org/cgit/quic/qrd-android/platform/hardware/ril/tree/include/telephony/ril.h?h=8130_CS&id=refs/heads/ics_qrd#n41

Comment on attachment 764786 [details] [diff] [review] Gaia part - v1 Review of attachment 764786 [details] [diff] [review]: ----------------------------------------------------------------- I don't think my review is needed on these, please get UX to review the copy if needed. See also https://groups.google.com/forum/#!topic/mozilla.dev.gaia/_T_BTvJ4fJk

If the copy follows the style guide, it should be fine: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/UX/Style_guide

fernando, does comment 34 answer your NI?

It does, thank you.

Comment on attachment 764786 [details] [diff] [review] Gaia part - v1 The UX feedback is indeed more important. But no problem landing those strings in gaia :)

Comment on attachment 764783 [details] [diff] [review] Gecko part - v1 Review of attachment 764783 [details] [diff] [review]: ----------------------------------------------------------------- I found there are a lot new symbols introduced in this patch but are actually never referenced. Hope some day we can implement all the things in need. ::: dom/system/gonk/ril_consts.js @@ +2529,5 @@ > this.MMI_SC_BA_ALL = "330"; > this.MMI_SC_BA_MO = "333"; > this.MMI_SC_BA_MT = "353"; > > +// MMI service code key strings. Could you move these new definitions to bug 883178? That's the actual bug that references these symbols.

(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, please) from comment #32) > Comment on attachment 764783 [details] [diff] [review] > Gecko part - v1 > > Carol, as you can see I added most of the strings that you proposed with > these exceptions: > > 1- rilErrnoInvalidParameter, rilErrnoRejectedByRemote and > rilErrnoUnrecognizedRilErrorNumber as they don't seem to be part of the > standard RIL errors [1]. I think the tree you are looking at is old. Please take a look at ril.h from the ics_strawberry tree: https://www.codeaurora.org/cgit/quic/la/platform/hardware/ril/tree/include/telephony/ril.h?h=refs/heads/b2g/ics_strawberry#n41 That last one rilErrnoUnrecognizedRilErrorNumber can be ignored though. > > 2- I added scPuk and scPuk2. I'm not sure if these two are needed? Unblocking and changing of PIN1/PIN2 are done via the same MMI codes (05 or 052). > > [1] > https://www.codeaurora.org/cgit/quic/qrd-android/platform/hardware/ril/tree/ > include/telephony/ril.h?h=8130_CS&id=refs/heads/ics_qrd#n41

Thanks Vicamo. I've only added the rilErrno consts and left the MMI related ones for follow up patches so we only add the consts that are actually used.

(In reply to Carol Yang [:cyang] from comment #39) > (In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, > please) from comment #32) > > Comment on attachment 764783 [details] [diff] [review] > > Gecko part - v1 > > > > Carol, as you can see I added most of the strings that you proposed with > > these exceptions: > > > > 1- rilErrnoInvalidParameter, rilErrnoRejectedByRemote and > > rilErrnoUnrecognizedRilErrorNumber as they don't seem to be part of the > > standard RIL errors [1]. > > I think the tree you are looking at is old. Please take a look at ril.h from > the ics_strawberry tree: > https://www.codeaurora.org/cgit/quic/la/platform/hardware/ril/tree/include/ > telephony/ril.h?h=refs/heads/b2g/ics_strawberry#n41 > > That last one rilErrnoUnrecognizedRilErrorNumber can be ignored though. > Thanks! > > > > 2- I added scPuk and scPuk2. > > I'm not sure if these two are needed? Unblocking and changing of PIN1/PIN2 > are done via the same MMI codes (05 or 052). According to the spec at [1], unblocking and changing PIN1/PIN2 are done via different MMI codes: 04 for changing PIN (scPin) 042 for changing PIN2 (scPin2) 05 for unblocking PIN (scPuk) 052 for unblocking PIN2 (scPuk2) [1] http://www.etsi.org/deliver/etsi_ts/122000_122099/122030/11.00.00_60/ts_122030v110000p.pdf

> According to the spec at [1], unblocking and changing PIN1/PIN2 are done via > different MMI codes: > > 04 for changing PIN (scPin) > 042 for changing PIN2 (scPin2) > 05 for unblocking PIN (scPuk) > 052 for unblocking PIN2 (scPuk2) > > [1] > http://www.etsi.org/deliver/etsi_ts/122000_122099/122030/11.00.00_60/ > ts_122030v110000p.pdf Ok sounds good!

Carol, could you share your working plan?

Hi Leo, My work is solely in the commercial RIL. Once Fernando's changes go in, then I can continue work to support localization for MMI.

http://hg.mozilla.org/projects/birch/rev/38d13271a30a (In reply to Carol Yang [:cyang] from comment #45) > Hi Leo, > > My work is solely in the commercial RIL. Once Fernando's changes go in, then > I can continue work to support localization for MMI. I am afraid that your work might still be blocked by bug 883178 (that is also blocked by bug 885701) which might take a few days more. I'll be pushing the gaia side as soon as I get an answer to https://bugzilla.mozilla.org/show_bug.cgi?id=874308#c33

Fernando, could you make the all patches including Gaia and gecko clear?

Carol, please share the qct plan. Is there a SR case related this issue?

(In reply to leo.bugzilla.gecko from comment #48) > Fernando, could you make the all patches including Gaia and gecko clear? The bugs required to get the full set of localized MMI codes are: - This one, as it introduces the required strings in Gaia side. The identifier for these strings are going to be sent by the platform. (Fixed) - Bug 883178: implements MMIResult and MMIError components required to expose a more detailed information about the request result allowing the UI to provide a more complete and localizable information. This is the key bug for all the other MMI related issues. Once this is done, the specific cases for IMEI, PIN, CF, etc. should be pretty straight forward. (Patches for m-c proposed and waiting for review, it still requires different patches for b2g18 though). - Bug 885701: implements DOMRequest.fireDetailedError to allow the platform to send an MMIError within the DOMRequest.onerror event. This one blocks 883178. (Patch for m-c proposed and waiting for review, it still requires different patch for b2g18 though) - Bug 884349: introduces the basic bits for handling the new MMIResult and MMIError objects in Gaia side, including get IMEI and USSD requests. It blocks the rest of Gaia work to handle other MMI codes like PIN handling, CF, etc. request. (Patch proposed and waiting for review). - Bug 874000: implements the Gecko and Gaia side required to expose and handle a localize result for PIN handling MMI requests. Blocked by 884349. (WIP, will have a patch soon). - Bug 879680: Same as above but for CF. (No WIP yet) - Bug 879685: Gaia bits for handling CW MMI requests. Since there is no reference RIL support for CW via MMI, this won't require a Gecko patch. (No WIP yet) - Bug 879694: Same as above but for CB. (No WIP yet)

https://hg.mozilla.org/releases/mozilla-b2g18/rev/c1a491ca5b62 Leaving status-b2g18 set to affected for the v1-train uplift.

[v1-train dea1109]

v1.1.0hd: dea1109155998e86988d806133dc8939b24a88a6

(In reply to leo.bugzilla.gecko from comment #49) > Carol, > please share the qct plan. Is there a SR case related this issue? Changes for commericial RIL will be merged as soon as all dependencies mentioned in Comment 51 are in.