Closed Bug 1395457 Opened 2 years ago Closed 2 years ago

De-hardcode product name when producing webext-langpack


(Core :: Internationalization, enhancement, P3)




Tracking Status
firefox57 --- fixed


(Reporter: zbraniecki, Assigned: zbraniecki)




(1 file)

The python code used to generate webextension langpacks' manifest.json has the name `Firefox` hardcoded in it:

We should de-hardcode it, but I'm not sure where can we take the brandName from.
Blocks: 1395363
Priority: -- → P3
We currently have one place where we use the name "Firefox" to build the description of the language pack "Language pack for Firefox for ab-CD"[0]

I'd like to de-hardcode the name, so that we can create a language pack for Firefox or for Fennec or for Thunderbird, Seamonkey etc.

The challenge here is that I don't know where to take the product name from in mozbuild/action.

I could maybe use .properties parser and look for Or try to vendor fluent python parser and add brand.ftl already.

Alternatively, I can remove the product specifier and keep it as "Language pack for ab-CD".

Pike, what do you think?


p.s. additionally, if I had the product name, I could increase the specificity of the langpack addon ID, by replacing "" with "" and "" or sth like that.
Flags: needinfo?(l10n)
MOZ_APP_DISPLAYNAME or MOZ_APP_NAME ? Try with devedition branding, those are the trickiest.

Probably not a good idea to use those for the langpack ID, though.
Flags: needinfo?(l10n)
Assignee: nobody → gandalf

I'm not going to touch the langpack ID for now.
Comment on attachment 8903337 [details]
Bug 1395457 - De-hardcode product name when producing webext-langpack.

I think you'll need a different reviewer to guide you to the right thing here.

MOZ_APP_DISPLAYNAME doesn't work out of the box. Thunderbird uses Daily, for example, and I'm not convinced that our langpack titles should differ for Developer Edition, or Nightly for that matter?

Maybe there's nothing good yet, and we need to explicitly create something for our use-case.
Attachment #8903337 - Flags: review?(l10n) → review-
Kris, Dave, any thoughts on this?

I'm trying to pick a good description for the new langpacks. Using MOZ_APP_DISPLAYNAME gives me: "Language pack for Firefox for pl" but as Pike pointed out also "Language pack for Nightly for pl" and "Language pack for Daily for pl".

I'd be happy to not differentiate between channels, but MOZ_APP_NAME is all lower-case, so not that good for "Language pack for firefox for pl".

Any idea what should I do, and if Axel is correct that we need to generate a new one, where should I take it from?
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(dtownsend)
MOZ_APP_DISPLAYNAME (or the equivalent brandShortName from a string bundle) is probably the best we're going to do. We generally try to consistently use the appropriate codename for unbranded/unofficial/nightly builds, so there aren't any easy ways to access the branded app name in those. And we probably want to stick to the code name in the langpack name for consistency in those builds, anyway.
Flags: needinfo?(kmaglione+bmo)
I don't think I have anything else to add here.
Flags: needinfo?(dtownsend)
Comment on attachment 8903337 [details]
Bug 1395457 - De-hardcode product name when producing webext-langpack.

Ok, Pike is ok with Kris' approach. Setting r?kmag
Attachment #8903337 - Flags: review- → review?(kmaglione+bmo)
Comment on attachment 8903337 [details]
Bug 1395457 - De-hardcode product name when producing webext-langpack.
Attachment #8903337 - Flags: review?(kmaglione+bmo) → review+
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg rebase -s 57d24857e849 -d 95543c372e9f: rebasing 418651:57d24857e849 "Bug 1395457 - De-hardcode product name when producing webext-langpack. r=kmag" (tip)
merging python/mozbuild/mozbuild/action/
merging toolkit/locales/
warning: conflicts while merging python/mozbuild/mozbuild/action/! (edit, then use 'hg resolve --mark')
warning: conflicts while merging toolkit/locales/! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
Pushed by
De-hardcode product name when producing webext-langpack. r=kmag
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.