833318 - Cost Control app renamed Usage

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Description

[marcoc]

Currently, the app is named Cost Control, but should be more correctly named Usage. This is a case of correctly meeting user expectation for what the app does.

'Cost Control' suggests the app always effects control over a user's costs. But this is not always the case, and therefore inaccurate. 
There are two main cases: 
1. If a user is in a prepaid scenario, the app only allows a user to track usage of call time and SMS messages sent. 
2. The data usage of the app view does not reference cost consumption, it only tracks usage.

* Wherever 'Cost Control' is mentioned, should be replaced by 'Usage':
- https://bug831274.bugzilla.mozilla.org/attachment.cgi?id=703829 - module
- https://bug831274.bugzilla.mozilla.org/attachment.cgi?id=703830 - alert screen

* 'Usage' should be capitalized on the Welcome Screen of cost control set-up flows as in these cases they refer to the app.

Comment 1

[Salvador de la Puente González [:salva]]

Attachment: Replacing Cost Control uses by Usage

Comment 2

[Bartosz Piec]

"Usage" is very hard to translate to other languages (in one or two short words). Can't we call this application in a more convenient way?

Comment 3

[Salvador de la Puente González [:salva]]

Lets ask Marco about it.

Comment 4

[marcoc]

'Usage' makes perfect sense in English given the above reasoning.

A translation of 'Usage' into other languages should not be done literally, it depends on:
- what fits
- what makes sense in each language to communicate the correct expectation noted in the comment
For example, movies that hope to get famous internationally don't choose their title based on its translation... you make it the best you can in each language, whether or not it's literal.

One suggestion for Spanish might be 'Consumo' - but I am not a native speaker to know if that entirely makes sense.

Comment 5

[Axel Hecht [:Pike]]

Comment on attachment 711750 [details]
Replacing Cost Control uses by Usage

The changed strings aren't localizable, it seems. We should either drop them or make them localizable.

I'd also tweak the manifest to only include localized entries. I don't see the point to have 4 entries in there that are literally the same as en-US.

Comment 6

[Salvador de la Puente González [:salva]]

(In reply to Axel Hecht [:Pike] from comment #5)
> Comment on attachment 711750 [details]
> Replacing Cost Control uses by Usage
> 
> The changed strings aren't localizable, it seems. We should either drop them
> or make them localizable.

Excuse me Alex. How could we make them localizable?

> I'd also tweak the manifest to only include localized entries. I don't see
> the point to have 4 entries in there that are literally the same as en-US.

I hoped this was localized. In the former versions they were the same as well. I don't know how to make them localizable.

Comment 7

[Axel Hecht [:Pike]]

(In reply to marcoc from comment #4)
> 'Usage' makes perfect sense in English given the above reasoning.
> 
> A translation of 'Usage' into other languages should not be done literally,
> it depends on:
> - what fits
> - what makes sense in each language to communicate the correct expectation
> noted in the comment
> For example, movies that hope to get famous internationally don't choose
> their title based on its translation... you make it the best you can in each
> language, whether or not it's literal.
> 
> One suggestion for Spanish might be 'Consumo' - but I am not a native
> speaker to know if that entirely makes sense.

We disagree here in general. We're shipping a product that doesn't matter in English, choosing feature names in a way that only works in English is counter-productive.

I don't think that this is the case here, though. I think this renaming makes sense. The ui might be challenged to accomodate for localized feature names that are longer, of course.

Comment 8

[Axel Hecht [:Pike]]

(In reply to Salvador de la Puente González [:salva] from comment #6)
> (In reply to Axel Hecht [:Pike] from comment #5)
> > Comment on attachment 711750 [details]
> > Replacing Cost Control uses by Usage
> > 
> > The changed strings aren't localizable, it seems. We should either drop them
> > or make them localizable.
> 
> Excuse me Alex. How could we make them localizable?

I would hope like with any other string, by adding data-l10n-id attributes, etc.

> > I'd also tweak the manifest to only include localized entries. I don't see
> > the point to have 4 entries in there that are literally the same as en-US.
> 
> I hoped this was localized. In the former versions they were the same as
> well. I don't know how to make them localizable.

They're localized by the build process, as long as the manifest stays in the same structure. specifically, you should be able to just remove the 'ar', 'fr', etc entries, but leave the 'en-US' one intact and in place where it currently is.

Comment 9

[Axel Hecht [:Pike]]

Comment on attachment 711750 [details]
Replacing Cost Control uses by Usage

Looks good from an l10n pov. I guess that re-using the 'usage' key is gonna be fine, though there's some risk there. As I don't really know where the title is shown, I don't know how different the visual context is compared to the <h1> where we use it right now.

Comment 10

[Salvador de la Puente González [:salva]]

I'm keeping the usage id only for titles so it's only used inside <title> and <h1> tags with a very similar meanings.

Comment 11

[Axel Hecht [:Pike]]

Vivien, I just grep'ed through our gaia sources, and I see that most html files have <title> elements, and without data-l10n-id. Can you explain why they're there, and why as non-localizable elements?

Comment 12

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Axel Hecht [:Pike] from comment #11)
> Vivien, I just grep'ed through our gaia sources, and I see that most html
> files have <title> elements, and without data-l10n-id. Can you explain why
> they're there, and why as non-localizable elements?

There is no good reason but I believe this is mostly because the title is never visible for the user.

Comment 13

[Salvador de la Puente González [:salva]]

Master: 6dc2b336b7f06308ab3bddc40e2073793393b742

Comment 14

[Salvador de la Puente González [:salva]]

Comment on attachment 711750 [details]
Replacing Cost Control uses by Usage

[Approval Request Comment]
Bug caused by (feature/regressing bug #): this one
User impact if declined: low
Testing completed: yes
Risk to taking this patch (and alternatives if risky): very low

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 711750 [details]
Replacing Cost Control uses by Usage

Looks pretty low risk and like l10n issues have been addressed, approving for v1.0.1 uplift.

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.

Comment 17

[John Ford [:jhford] CET/CEST Berlin Time]

This commit does not apply cleanly to v1-train.  If this patch depends on another bug, please comment here and I will retry when that bug is approved to land on all branches that this bug needs to land on.  If the merge conflict needs to be resolved by hand, the following commands could be a useful starting point:

cd gaia
git checkout v1-train
git cherry-pick -x -m1 6dc2b336b7f06308ab3bddc40e2073793393b742
<resolve merge conflict>

#	both modified:      apps/costcontrol/locales/costcontrol.fr.properties

Comment 18

[Salvador de la Puente González [:salva]]

I detected the merge will include partially these changes [1]. What should we do?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=829511

Comment 19

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Salvador de la Puente González [:salva] from comment #18)
> I detected the merge will include partially these changes [1]. What should
> we do?
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=829511

Per bug 829511#c38, we've already landed that bug on v1-train.  Since that's as far as this bug will get uplifted, I think we should resolve the merge conflict for this bug to get it on v1-train.

Comment 20

[Salvador de la Puente González [:salva]]

v1-train: 6916e18d1f72936e892543cf4a104a7d457f78ad

Comment 21

[John Ford [:jhford] CET/CEST Berlin Time]

I accidentally landed this on v1.0.1 (04acc5e5b14e208c09979fd2c270f82dcba0619b) then backed it out on v1.0.1 (ccb6778b635f18f42e3c510cf1a3431d3af46ce6).  My confusion was the blocking-b2g- flag overrides the status-b2g18-v1.0.1.

What should happen here?

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to John Ford [:jhford] from comment #21)
> I accidentally landed this on v1.0.1
> (04acc5e5b14e208c09979fd2c270f82dcba0619b) then backed it out on v1.0.1
> (ccb6778b635f18f42e3c510cf1a3431d3af46ce6).  My confusion was the
> blocking-b2g- flag overrides the status-b2g18-v1.0.1.
> 
> What should happen here?

Hey John - please go ahead with landing to v1.0.1 - if the bug is tracking-b2g18 and has status-b2g18-v1.0.1 marked 'affected' and not 'wontfix' then we are expecting it to land on v1.0.1 -- sorry for the confusion but we'll be burning down these bugs and most bugs from here on out will only be landing (to v1.0.1) if they are tef blockers to help reduce this confusion. (note that comment 15 also stated approval for v1.0.1 which is what I was doing to help clarify).

Comment 23

[John Ford [:jhford] CET/CEST Berlin Time]

v1.0.1: 7eced44f2658dc300a46f893c681950c3ad041ca

Comment 24

[Axel Hecht [:Pike]]

Thanks, exported to gaia-l10n/en-US, too.