Closed Bug 1393147 Opened 2 years ago Closed 2 years ago

Update the new langpack-webext manifest scheme

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox57 verified)

VERIFIED FIXED
mozilla57
Tracking Status
firefox57 --- verified

People

(Reporter: zbraniecki, Assigned: zbraniecki)

References

Details

Attachments

(1 file)

Per bug 1365709 comment 33, we want to change a few bits in the manifest.json scheme for webextension langpacks.
Assignee: nobody → gandalf
Blocks: 1365709
Status: NEW → ASSIGNED
The result manifest looks like this:

```
{
  "languages": {
    "pl": {
      "chrome_resources": [
        "locale branding pl browser/chrome/pl/locale/branding/", 
        "locale browser pl browser/chrome/pl/locale/browser/", 
        "locale browser-region pl browser/chrome/pl/locale/browser-region/", 
        "locale devtools pl browser/chrome/pl/locale/pl/devtools/client/", 
        "locale devtools-shared pl browser/chrome/pl/locale/pl/devtools/shared/", 
        "locale formautofill pl browser/chrome/pl/locale/pl/", 
        "locale pdf.js pl browser/chrome/pl/locale/pdfviewer/", 
        "override chrome://global/locale/appstrings.properties chrome://browser/locale/appstrings.properties", 
        "override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd", 
        "override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd", 
        "resource search-plugins chrome://browser/locale/searchplugins/", 
        "locale pocket pl browser/features/firefox@getpocket.com/pl/locale/pl/", 
        "locale onboarding pl browser/features/onboarding@mozilla.org/pl/locale/pl/", 
        "locale presentation pl browser/features/presentation@mozilla.org/pl/locale/pl/", 
        "locale webcompat-reporter pl browser/features/webcompat-reporter@mozilla.org/pl/locale/pl/", 
        "locale alerts pl chrome/pl/locale/pl/alerts/", 
        "locale autoconfig pl chrome/pl/locale/pl/autoconfig/", 
        "locale global pl chrome/pl/locale/pl/global/", 
        "locale global-platform pl chrome/pl/locale/pl/global-platform/mac/", 
        "locale global-platform pl chrome/pl/locale/pl/global-platform/unix/", 
        "locale global-platform pl chrome/pl/locale/pl/global-platform/win/", 
        "locale mozapps pl chrome/pl/locale/pl/mozapps/", 
        "locale necko pl chrome/pl/locale/pl/necko/", 
        "locale passwordmgr pl chrome/pl/locale/pl/passwordmgr/", 
        "locale pipnss pl chrome/pl/locale/pl/pipnss/", 
        "locale pippki pl chrome/pl/locale/pl/pippki/", 
        "locale places pl chrome/pl/locale/pl/places/", 
        "locale pluginproblem pl chrome/pl/locale/pl/pluginproblem/", 
        "locale weave pl chrome/pl/locale/pl/services/"
      ], 
      "version": "57.0a1", 
      "resources": null
    }
  }, 
  "applications": {
    "gecko": {
      "strict_min_version": "57.0a1", 
      "id": "langpack-pl@mozilla.org"
    }
  }, 
  "version": "57.0a1", 
  "langpack-id": "pl", 
  "name": "Polski Language Pack", 
  "manifest_version": 2, 
  "author": "Aviary.pl (contributors: Aviary.pl, Zbigniew Braniecki, Marek Stępień, Piotr Komoda, Marek Wawoczny, Piotr Bartecki, Kornel Misiejuk, Wadim Dziedzic, Stefan Plewako)", 
  "description": "Language pack for Firefox for pl"
}
```

I keep the `resources` to null for now, but we may want to experiment with indexing them and using `IndexedFileSource` for L10nRegistry later.

The version per language is not important for WebExt code, but may help us later in L10nRegistry when deciding which version of `es-MX` should we use.

One thing about versions - ideally, we'd like to version language packs (and languages) after a timestamp of the revision from the VCS repo of the locale we're pulling from.
So, instead of version "57.0a1" we'd like to end up with "201708231454" and then if there'll be a newer commit to "pl" repo it would get updated to "201708241923". Is that something that would work or do we have to somehow version our langpacks artificially "57.0a1-1", "57.0a1-2" etc?
Kris, in bug 1365709 comment 37, you wrote:

> Is there a particular reason you want to do that?
>
> I'm pretty strongly opposed to it. Chrome resources registered by language
> packs need to be validated. We need to make sure they're only registering
> locale resources, and that the locale resources they're registering are only
> for the locales they claim to provide.
>
> Aside from making that easier to verify, the format I suggested is also
> considerably more compact.

If I understand correctly the choice is between:

1) chrome entries stored in manifest.json as a list of tokens:
```
{
  "chrome_resources": [
    ["locale", "global", "pl", "chrome/pl/locale/pl/global/"]
  ]
}
```

2) chrome entries stored in manifest.json as a string:

```
{
  "chrome_resources": [
    "locale global pl chrome/pl/locale/pl/global/"
  ]
}
```

In both cases I'm taking them from parsing the chrome manifest in the build system, and then either we split by space at build time, or at runtime.

I don't see a major difference between those two approaches and quite frankly, chose the latter because it made the .json file slightly smaller :)
If you prefer the (1), I'm happy to switch to it, but first would like to confirm that those are the two choices on the table and you do prefer (1).
Flags: needinfo?(kmaglione+bmo)
No, what I suggested was:

  "languages": {
    "pl": {
      "chrome_resources": {
        "branding": "browser/chrome/pl/locale/branding/",
        "browser": "browser/chrome/pl/locale/browser/",
        "browser-region": "browser/chrome/pl/locale/browser-region/",
        "devtools": "browser/chrome/pl/locale/pl/devtools/client/",
        "devtools-shared": "browser/chrome/pl/locale/pl/devtools/shared/",
        "formautofill": "browser/chrome/pl/locale/pl/",
        "pdf.js": "browser/chrome/pl/locale/pdfviewer/",
        "pocket": "browser/features/firefox@getpocket.com/pl/locale/pl/",
        "onboarding": "browser/features/onboarding@mozilla.org/pl/locale/pl/",
        "presentation": "browser/features/presentation@mozilla.org/pl/locale/pl/",
        "webcompat-reporter": "browser/features/webcompat-reporter@mozilla.org/pl/locale/pl/",
        "alerts": "chrome/pl/locale/pl/alerts/",
        "autoconfig": "chrome/pl/locale/pl/autoconfig/",
        "global": "chrome/pl/locale/pl/global/",

	// These ones are tricky... need to think of a solution for
	// platform-specific entries...
        "global-platform": "chrome/pl/locale/pl/global-platform/mac/",
        "global-platform": "chrome/pl/locale/pl/global-platform/unix/",
        "global-platform": "chrome/pl/locale/pl/global-platform/win/",

        "mozapps": "chrome/pl/locale/pl/mozapps/",
        "necko": "chrome/pl/locale/pl/necko/",
        "passwordmgr": "chrome/pl/locale/pl/passwordmgr/",
        "pipnss": "chrome/pl/locale/pl/pipnss/",
        "pippki": "chrome/pl/locale/pl/pippki/",
        "places": "chrome/pl/locale/pl/places/",
        "pluginproblem": "chrome/pl/locale/pl/pluginproblem/",
        "weave": "chrome/pl/locale/pl/services/"
      },
      ...
    },
    ...
  }
Flags: needinfo?(kmaglione+bmo)
So, that would be awesome but there are two issues not handled by such data model:

1) the "global-platform"

As you pointed out yourself, we need to be able to handle that. I could try to do 

```
  "languages": {
    "pl": {
      "chrome_resources": {
        "global-platform": {
          "mac": "chrome/pl/locale/pl/global-platform/mac/",
          "unix": "chrome/pl/locale/pl/global-platform/unix/",
          "win": "chrome/pl/locale/pl/global-platform/win/",
        },
        ...
      },
      ...
    },
    ...
  }
```

lmk if you like it.

2) the override and resource entries:

We have now three override and one resource entry:
```
        "override chrome://global/locale/appstrings.properties chrome://browser/locale/appstrings.properties", 
        "override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd", 
        "override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd", 
        "resource search-plugins chrome://browser/locale/searchplugins/", 
```

I tried to remove the overrides in bug 1377911, but that regressed something and the build people didn't have time to look at why.
Do you want me to block this bug on that being solved?

And what to do with the search-plugins?
Flags: needinfo?(kmaglione+bmo)
Oh, and it seems that so far I've been cutting out part of the chrome entry for the global-platform. The original entry is:

```
locale global-platform pl pl/locale/pl/global-platform/mac/ os=Darwin
locale global-platform pl pl/locale/pl/global-platform/unix/ os=LikeUnix os=Android
locale global-platform pl pl/locale/pl/global-platform/win/ os=WINNT
```

So yeah, we need to figure out how to include it in the manifest.json.

Does your registerChromeEntry API support os= flags?
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #5)
> So, that would be awesome but there are two issues not handled by such data
> model:
> 
> 1) the "global-platform"
> 
> As you pointed out yourself, we need to be able to handle that.

This is a problem with your previous proposal too :) The last entry would have
just clobbered the ones before it.

> I could try to do 
> 
> ```
>   "languages": {
>     "pl": {
>       "chrome_resources": {
>         "global-platform": {
>           "mac": "chrome/pl/locale/pl/global-platform/mac/",
>           "unix": "chrome/pl/locale/pl/global-platform/unix/",
>           "win": "chrome/pl/locale/pl/global-platform/win/",
>         },
>         ...
>       },
>       ...
>     },
>     ...
>   }
> ```
> 
> lmk if you like it.

I think I can live with that, yeah.

> 2) the override and resource entries:
> 
> We have now three override and one resource entry:
> ```
>         "override chrome://global/locale/appstrings.properties chrome://browser/locale/appstrings.properties",
>         "override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd",
>         "override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd",
>         "resource search-plugins chrome://browser/locale/searchplugins/",
> ```
> 
> I tried to remove the overrides in bug 1377911, but that regressed something
> and the build people didn't have time to look at why.
> Do you want me to block this bug on that being solved?

The override entries can't be specified in the langpack manifest, for obvious
security reasons. My original plan for them was to just register a static list
of them from the AOM side.

> And what to do with the search-plugins?

For the resource entries, my suggestion was something like:

[16:52:19] <John-Galt> gandalf: So, going with your example: "languages": {"pl": {"resources": ["/localization/pl/browser/aboutDialog.ftl"], "chrome_resources": {"alerts": "pl/locale/pl/alerts/", ...}}}

Though if we need to specify specific resource packages, that's trickier...
How do we decide when they get registered?

I guess we should have a static list of resource packages a langpack is
allowed to register (which would probably consist of just "search-plugins" for
now), and register them only when that locale is active?
Flags: needinfo?(kmaglione+bmo)
> This is a problem with your previous proposal too :) The last entry would have
just clobbered the ones before it.

Well, I could have just fix it to include the `os=X` part in the string :)

> I think I can live with that, yeah.

Is it also ok that the manifest entry has things like os=Darwin and os=Android and we switch it to "mac" and "win"?
And it seems that registerChrome doesn't support the os flags, so we need to add that, am I correct?

> The override entries can't be specified in the langpack manifest, for obvious
security reasons. My original plan for them was to just register a static list
of them from the AOM side.

I'm afraid that that wouldn't work between products since each has different override list (Firefox, Fennec, Tb etc.).
If we cannot register overrides per-locale, that would mean that we are blocked by 1377911.


> I guess we should have a static list of resource packages a langpack is
allowed to register (which would probably consist of just "search-plugins" for
now), and register them only when that locale is active?

That sounds good to me.
Flags: needinfo?(kmaglione+bmo)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #8)
> > This is a problem with your previous proposal too :) The last entry would
> > have just clobbered the ones before it.
> 
> Well, I could have just fix it to include the `os=X` part in the string :)

You couldn't, because the dynamic chrome registration API doesn't use the
manifest parser, and that's what handles the attribute filtering :)

> > I think I can live with that, yeah.
> 
> Is it also ok that the manifest entry has things like os=Darwin and
> os=Android and we switch it to "mac" and "win"?
> And it seems that registerChrome doesn't support the os flags, so we need to
> add that, am I correct?

We need to do the filtering before constructing the object we pass to
registerChrome. Let's just use an object with keys corresponding to the value
in AppConstants.platform

> > The override entries can't be specified in the langpack manifest, for
> > obvious security reasons. My original plan for them was to just register a
> > static list of them from the AOM side.
> 
> I'm afraid that that wouldn't work between products since each has different
> override list (Firefox, Fennec, Tb etc.). If we cannot register overrides
> per-locale, that would mean that we are blocked by 1377911.

We can have a separate list per-product.

Thunderbird isn't my concern, but we should be able to fix this for Firefox
and Fennec, and they should be able to handle their side.
Flags: needinfo?(kmaglione+bmo)
> We need to do the filtering before constructing the object we pass to
registerChrome. Let's just use an object with keys corresponding to the value
in AppConstants.platform

I tried to apply this concept to my patch and unfortunately, it's not as easy.

Basically, there may be many different flags and it would be very hard to handle all of them.
From what I've seen in all products, we can limit it to 'os', but it still is a list, and it may have equal and not-equal signs.

So, there are entries like "os=Unix os=Android" which mean that the entry should be enabled on either. There may be "os!=Mac" or "os!=Mac os=Windows".

I tried to capture those operators and the fact that it's a list, and ended up with:

```
  "languages": {
    "pl": {
      "chrome_resources": {
        "necko": "chrome/pl/locale/pl/necko/", 
        "pdf.js": "browser/chrome/pl/locale/pdfviewer/", 
        "global": "chrome/pl/locale/pl/global/", 
        "onboarding": "browser/features/onboarding@mozilla.org/pl/locale/pl/", 
        "devtools": "browser/chrome/pl/locale/pl/devtools/client/", 
        "pipnss": "chrome/pl/locale/pl/pipnss/", 
        "devtools-shim": "browser/chrome/pl/locale/pl/devtools/shim/", 
        "alerts": "chrome/pl/locale/pl/alerts/", 
        "branding": "browser/chrome/pl/locale/branding/", 
        "presentation": "browser/features/presentation@mozilla.org/pl/locale/pl/", 
        "autoconfig": "chrome/pl/locale/pl/autoconfig/", 
        "devtools-shared": "browser/chrome/pl/locale/pl/devtools/shared/", 
        "global-platform": [
          {
            "platforms": [[true, "Darwin"]], 
            "path": "chrome/pl/locale/pl/global-platform/mac/"
          }, 
          {
            "platforms": [[true, "LikeUnix"], [true, "Android"]], 
            "path": "chrome/pl/locale/pl/global-platform/unix/"
          }, 
          {
            "platforms": [[true, "WINNT"]], 
            "path": "chrome/pl/locale/pl/global-platform/win/"
          }
        ], 
        "browser-region": "browser/chrome/pl/locale/browser-region/", 
        "mozapps": "chrome/pl/locale/pl/mozapps/", 
        "pluginproblem": "chrome/pl/locale/pl/pluginproblem/", 
        "pocket": "browser/features/firefox@getpocket.com/pl/locale/pl/", 
        "weave": "chrome/pl/locale/pl/services/", 
        "formautofill": "browser/chrome/pl/locale/pl/", 
        "places": "chrome/pl/locale/pl/places/", 
        "passwordmgr": "chrome/pl/locale/pl/passwordmgr/", 
        "pippki": "chrome/pl/locale/pl/pippki/", 
        "webcompat-reporter": "browser/features/webcompat-reporter@mozilla.org/pl/locale/pl/", 
        "browser": "browser/chrome/pl/locale/browser/"
      }, 
      "version": "57.0a1", 
      "resources": null
    }
  }, 
```

I don't think is very graceful, but contains the right information.
Wdyt?
Flags: needinfo?(kmaglione+bmo)
I'd rather we go with something simpler, like we talked about before:

        "global-platform": {
          "macosx": "chrome/pl/locale/pl/global-platform/mac/",
          "linux": "chrome/pl/locale/pl/global-platform/unix/",
          "win": "chrome/pl/locale/pl/global-platform/win/"
        },

There's no point in using an array, since only one will ever be
active at a time.
Flags: needinfo?(kmaglione+bmo)
(In reply to Kris Maglione [:kmag] from comment #12)
> I'd rather we go with something simpler, like we talked about before:
> 
>         "global-platform": {
>           "macosx": "chrome/pl/locale/pl/global-platform/mac/",
>           "linux": "chrome/pl/locale/pl/global-platform/unix/",
>           "win": "chrome/pl/locale/pl/global-platform/win/"
>         },
> 
> There's no point in using an array, since only one will ever be
> active at a time.

But that would mean that there's no way to set a global-platform override that works for, say, only android. Or android and windows, or not android and not windows etc.

The full "os!=Linux os==Windows" data model contains more than just a selection of one out of several options.

Do you believe we should impose a limitation like that?
Flags: needinfo?(kmaglione+bmo)
I'm not really concerned about it. We have a finite list of supported platforms. It shouldn't be that much of a burden to list all of them in cases where they diverge.

And I'd be surprised if we ever wind up in a situation where we use the same langpacks on desktop and android.
Flags: needinfo?(kmaglione+bmo)
Ok, sounds reasonable. Will work on the patch.

Also, Ni on Pike to confirm that he's ok with us going this route as well.
Flags: needinfo?(l10n)
Updated the patch. I'm also moving other entry types away from langpacks, so placing this on a dependency list. I like that we'll only handle locale entries here tbh.
Depends on: 1377911, 1393848
I recall conflicted conversations about the platform piece in the chrome registry. Not sure who were the stakeholders in that conversation, though. There was something about "general case first, and then platform dependent overwrites", which would call for a list. I'd look at glandium for the conversation, but really just because that starts with a 'g'.

Happy to do a f? on an actual patch here.
Flags: needinfo?(l10n)
> There was something about "general case first, and then platform dependent overwrites", which would call for a list.

We don't have "general case" here. We only have per-platform dependencies. I guess my question is if in the context of locale related chrome manifests do we have a case where we use different flags or different quantifier than "=="?
I checked android, and it doesn't have any.

Jorg: do you know if any locale related chrome entry uses chrome manifest flags other than "os="?

I don't have a build env for Thunderbird, but you should be able to look at tb's equivalent of:
 - obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/en-US.manifest
 - obj-x86_64-pc-linux-gnu/dist/bin/chrome/en-US.manifest 

in the build directory. With patches in bug 1377911 and bug 1393848 I only now see "locale" entries and only "global-platform" have any flags, and all those flags are "os=" which we're going to handle here.

Could you check for me the en-US.manifest's for Tb?
Flags: needinfo?(jorgk)
Comment on attachment 8900391 [details]
Bug 1393147 - Update the new langpack-webext manifest scheme.

Thanks for the offer Pike, The patch is ready for your feedback!
Attachment #8900391 - Flags: feedback?(l10n)
Comment on attachment 8900391 [details]
Bug 1393147 - Update the new langpack-webext manifest scheme.

https://reviewboard.mozilla.org/r/171744/#review178280

::: python/mozbuild/mozbuild/action/langpack_manifest.py:252
(Diff revision 5)
>                  'id': "langpack-" + main_locale + "@mozilla.org",
>                  'strict_min_version': appver
>              }
>          },
>          'name': defines['MOZ_LANG_TITLE'] + ' Language Pack',
>          'description': 'Language pack for Firefox for ' + main_locale,

Nit: Can you please use template strings rather than concatenation for these?

::: python/mozbuild/mozbuild/action/langpack_manifest.py:253
(Diff revision 5)
> -        'langpack-id': main_locale,
> +        'langpack_id': main_locale,
>          'manifest_version': 2,
>          'applications': {
>              'gecko': {
>                  'id': "langpack-" + main_locale + "@mozilla.org",
>                  'strict_min_version': appver

We probably also want `'strict_max_version': '%s.*' % appver` here, or the langpack will still be marked compatible after an app update, and things may blow up if strings are missing.

::: python/mozbuild/mozbuild/action/langpack_manifest.py:260
(Diff revision 5)
>          },
>          'name': defines['MOZ_LANG_TITLE'] + ' Language Pack',
>          'description': 'Language pack for Firefox for ' + main_locale,
>          'version': appver,
> -        'languages': locales,
> +        'languages': {},
>          'author': '%s (contributors: %s)' % (defines['MOZ_LANGPACK_CREATOR'], contributors),

Will `contributors` ever be empty?

::: python/mozbuild/mozbuild/action/langpack_manifest.py:273
(Diff revision 5)
> -                entry['alias'],
> -                entry['locale'],
> -                entry['path']
> -            )
> -        elif entry['type'] == 'override':
> -            line = '%s %s %s' % (
> +                if entry['alias'] not in cr:
> +                    cr[entry['alias']] = {}
> +                for platform in platforms:
> +                    cr[entry['alias']][platform] = entry['path']
> +            else:
> +                cr[entry['alias']] = entry['path']

Maybe `assert entry['alias'] not in cr` here?

::: python/mozbuild/mozbuild/action/langpack_manifest.py:279
(Diff revision 5)
>          else:
>              raise Exception('Unknown type %s' % entry['type'])
> -        manifest['chrome_entries'].append(line)
> +
> +    for loc in locales:
> +        manifest['languages'][loc] = {
> +            'version': appver,

Do we really need a separate version for each language?
Attachment #8900391 - Flags: review?(kmaglione+bmo) → review+
> Do we really need a separate version for each language?

I think so.

The way it works in L10nRegistry is that you register each langpack as a FileSource for a give number of locales.

Now, let's imagine the following scenario (from the future, we don't build multi-lingual langpacks yet):

User installs two langpacks, langpack-es@mozilla.org and langpack-es-MX@mozilla.org. The former has just one language, "es", but the latter provides a partial translation of "es-MX" and a fallback locale of "es".

This fallback locale allows "es-MX" to only carry strings that are specific to MX, and fallback on "es" for all others.

Now, in the UI that means that we'll show the user that he has language resources for Firefox in "es" and "es-MX", and if he selects "es", L10nRegistry needs to know if it should look for the resources in "es" from langpack-es@mozilla.org or langpack-es-MX@mozilla.org.

Here comes language version. It allows us to say - the langpack-es-MX@mozilla.org has newer version of "es", so let's use this one.

I'd like those versions to start coming in form of "YYYYMMDDHHMMSS" timestamps based on the push datetime in the locale repo.

Pike - does it make sense?
Flags: needinfo?(l10n)
OK, sounds reasonable to me, as long as we're assuming that langpacks won't always ship the same version of every language, or the latest version of every language prior to a given top-level version.

We can probably guarantee that for langpacks we build, but for user-generated langpacks, I guess it may be better to be safe and specify the version for each.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #21)
> Could you check for me the en-US.manifest's for Tb?
Please excuse the late reply. I only have:
C:\mozilla-source\comm-central\obj-x86_64-pc-mingw32\dist\bin\chrome\en-US.manifest
and the only entries with "flags" (xx=...) are:
locale global-platform en-US en-US/locale/en-US/global-platform/mac/ os=Darwin
locale global-platform en-US en-US/locale/en-US/global-platform/unix/ os=LikeUnix os=Android
locale global-platform en-US en-US/locale/en-US/global-platform/win/ os=WINNT
I hope that answers the question.
Flags: needinfo?(jorgk)
yeah, thank you! Seems like Firefox, Tb and Fennec are all covered. I will assume that Sm is as well, but I don't have a way to check that.
If we're wrong, we may have to extend the features when we'll be moving Sm to the new langpacks.
Comment on attachment 8900391 [details]
Bug 1393147 - Update the new langpack-webext manifest scheme.

https://reviewboard.mozilla.org/r/171744/#review178314

::: python/mozbuild/mozbuild/action/langpack_manifest.py:216
(Diff revision 5)
>  #    manifest == {
> -#        'languages': ['pl'],
> +#        'languages': {
> +#            'pl': {
> +#                'version': '201709121481',
> +#                'resources': None,
> +#                'chrome_resourcs': {

typo, 'e' missing in resources
Comment on attachment 8900391 [details]
Bug 1393147 - Update the new langpack-webext manifest scheme.

Didn't spot anything but a typo, and +1 to the things kmag found.
Attachment #8900391 - Flags: feedback?(l10n) → feedback+
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #24)
> I'd like those versions to start coming in form of "YYYYMMDDHHMMSS"
> timestamps based on the push datetime in the locale repo.
> 
> Pike - does it make sense?

push datetime stamp would be the safest and most portable. Not exactly sure how to reliably get it in developer builds and automation, though.

As for version per locale, I think that makes sense. We could just always update the version, aka, use a buildid. But that might add noise in the ecosystem down the road that we'd prefer to not have. Noise in the sense that it'd signal "there's a new localization to update to" while there's not.
Flags: needinfo?(l10n)
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fc4d31fca3f1
Update the new langpack-webext manifest scheme. r=kmag
I landed the patch as it gets the schema in line with our work on consuming the langpacks, but there are still a couple open questions that I'll address in follow up patches:

1) The strict_max_version seems to product "57.0a1.*' now, which I'm not sure if it's a correct token
2) The "Firefox" name is hardcoded - we should have the langpack name per-product (not sure how to get it tho!)
3) The language versions are now just a copy of appver, they should be taken from the push datetime stamp from the language repo, or langpack build timestamp as a fallback.
https://hg.mozilla.org/mozilla-central/rev/fc4d31fca3f1
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
This feature is verified as fixed on Firefox 57.0 (20171112125346), Firefox 58.0b3 (20171113130450) and 59.0a1 (20171113220112) under Wind 10 64-bit and Mac OS X 10.13.
Status: RESOLVED → VERIFIED
Depends on: 1425689
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.