In bug 1013837 we have a case where app name need to be updated by the MOZILLA_OFFICIAL switch. Yuren need to figure out how this work in Gaia build script and localization etc then we could find people doing these work, preferably not Yuren.

for this bug we need to add a l10n variable to manifest like: > ... > "locales": { > "en-US": { > "name": "{{browserBrandShortName}} Built-in Keyboard" > } > } Pike, do we have the capability to handle template like this for l10n?

I don't know of a reason against it, I'd prefer to have this fly by stas, too, though.

App names are not currently run through the mozL10n's logic. Instead, the localized names are taken from manifest.properties files found in l10n repos and inserted into the manifest directly: https://github.com/mozilla-b2g/gaia/blob/b3324d031fe91b864090461ffcacc6ca605a2903/build/multilocale.js#L323-L363 I'd be happy to change this behavior, also to fix bug 1012702. However, I'm not sure where would the values of {{variables}} come from. In cases when we want to display the app name in the marketplace or on the homescreen there is no guarantee that any of the references variables will be defined. Is there something I'm missing about what this bug is about?

Stas, discussed with Tim and Rudy, we may scan all l10n properties files in app itself directory (e.g. apps/keyboard) and shared directory, than we can use l10n string in manifest. for marketplace issue which you mentioned on comment 3, it's not a problem since we won't put gaia core apps on marketplace. but it looks a huge work for this proposal, do you have any better idea?

We are talking about localizing manifests here, Marketplace and Home screen always sees the localized manifest.

(In reply to Yuren [:yurenju] from comment #4) > Stas, > > discussed with Tim and Rudy, we may scan all l10n properties files in app > itself directory (e.g. apps/keyboard) and shared directory, than we can use > l10n string in manifest. > > for marketplace issue which you mentioned on comment 3, it's not a problem > since we won't put gaia core apps on marketplace. We absolutely want to move some gaia apps to the marketplace as privileged apps to be able to provide more frequent updates. It would be good to keep that in mind.

I read through bug 1013837 and from what I understood the idea to use {{brandName}} in the names of the keyboard apps came from Omega (bug 1013837 comment 2 and bug 1013837 comment 5). AFAICT, the need to have "Mozilla" or "Firefox OS" in the app name was dictated by the fact that only the name used to be displayed in the selection dialog. In bug 1013837 comment 7, however, Omega attached a UX proposal (attachment 8431426 [details]) in which each keyboard layout has an additional label, thus differentiating between built-in and other keyboards. Proposal 2 from his attachment was eventually implemented and bug 1013837 was resolved fixed, which I think means that we can safely wontfix this bug. We don't need to interpolate official branding in app names any more. (I still think that wouldn't be a good idea.)

(In reply to Fabrice Desré [:fabrice] from comment #6) > We absolutely want to move some gaia apps to the marketplace as privileged > apps to be able to provide more frequent updates. It would be good to keep > that in mind. That's still unrelated to this bug -- Marketplace will receive a built package regardless of the build process. This bug is about amendment to Gaia build script so it could pick up "{{brandShortName}} Keyboard" and translate it to "Firefox OS Keyboard". (In reply to Staś Małolepszy :stas from comment #7) > I read through bug 1013837 and from what I understood the idea to use > {{brandName}} in the names of the keyboard apps came from Omega (bug 1013837 > comment 2 and bug 1013837 comment 5). AFAICT, the need to have "Mozilla" or > "Firefox OS" in the app name was dictated by the fact that only the name > used to be displayed in the selection dialog. > > In bug 1013837 comment 7, however, Omega attached a UX proposal (attachment > 8431426 [details]) in which each keyboard layout has an additional label, > thus differentiating between built-in and other keyboards. Proposal 2 from > his attachment was eventually implemented and bug 1013837 was resolved > fixed, which I think means that we can safely wontfix this bug. We don't > need to interpolate official branding in app names any more. > > (I still think that wouldn't be a good idea.) Yes, the UI has been changed in these bug. Whatever the change, noted that "Built-in keyboard" is always visible regardless. Let's ask :omega on whether or not UX still want to put brand name on the name of the keyboard app. I agree it's it actually easier to wontfix this bug.

With the current UI design, there is no need of the brand name for keyboard app.

Woot! Yuren, please reopen if we have another use case in the future.