Add docs for adding a new l10n into product-details #89
Conversation
| - double-check that the PR is listing another locale in the ``public/1.0/languages.json`` file. See samples PRs like `this`_ or `this <https://github.com/mozilla-releng/product-details/pull/9>`__ from the past | ||
| - review and merge the PR, either directly into ``production`` or via ``main`` and then follow-up with a push to ``production`` | ||
| - wait for the Taskcluster CI to run successfully. Behind the scenes, the CI is cloning the repo resources and pushes them to a S3 bucket | ||
| - once the CI is green, trigger the Product-Details rebuild via Ship-it: |product-details-rebuild| |
There was a problem hiding this comment.
Note to self: I may be wrong here - pending a conclusion in the PR conversation.
| .. _Product details: https://product-details.mozilla.org/1.0/ | ||
| .. _here: https://wiki.mozilla.org/Release_Management/Product_details | ||
| .. _this: https://github.com/mozilla-releng/product-details/pull/10 | ||
| .. |product-details-rebuild| image:: /procedures/release-duty/faq/media/product-details-rebuild.png |
There was a problem hiding this comment.
Note to self: this URL will fix itself once we merge as the abspath will become valid in the main repo.
| opened against Product-details. TODO for releaseduty: | ||
|
|
||
|
|
||
| - double-check that the PR is listing another locale in the ``public/1.0/languages.json`` file. See samples PRs like `this`_ or `this <https://github.com/mozilla-releng/product-details/pull/9>`__ from the past |
There was a problem hiding this comment.
You mean another locale = a new locale?
|
|
||
|
|
||
| - double-check that the PR is listing another locale in the ``public/1.0/languages.json`` file. See samples PRs like `this`_ or `this <https://github.com/mozilla-releng/product-details/pull/9>`__ from the past | ||
| - review and merge the PR, either directly into ``production`` or via ``main`` and then follow-up with a push to ``production`` |
There was a problem hiding this comment.
The PR is always done against production, because the JSON file doesn't exist in main
There was a problem hiding this comment.
Is the main branch used for anything? Should we make production the default branch and delete the main branch?
| ship a newly-localized Firefox in a different language, RelEng gets involved. | ||
| In order for that to happen, the l10n team adds the corresponding builds as a | ||
| pre-requisite. Then, they likely ping releaseduty: PR like `this`_ or | ||
| `this <https://github.com/mozilla-releng/product-details/pull/9>`__ are |
There was a problem hiding this comment.
Based on our conversation elsewhere, and my reading of the code, I'm pretty sure that PRs against product-details are a bad idea. As far as I can tell, Ship It will rebuild product details based on the locales it finds in hg.mozilla.org (specifically, browser/locales/l10n-changesets.json).
So, a PR will work, but it will get overridden the next time we ship something, or trigger a manual rebuild of product details in Ship It.
Assuming this is all correct, this means that the correct procedure is:
- Land an hg.mozilla.org change to add the locale
- Trigger a manual rebuild of product details in Ship It
There was a problem hiding this comment.
I'm pretty sure that PRs against product-details are a bad idea
Sorry, I don't follow. product-details is the only place where the language name is defined, and that's the only change that those PRs contain (it doesn't touch the actual build information).
There was a problem hiding this comment.
It appears the PRs @MihaiTabara are pointing to change the languages.json file, which contains human-readable descriptions of the locales. It looks like the release services robot PRs don't update languages.json, nor does l10n-changesets.json contain that information. We may need both, until or unless we add the additional human-readable information into l10n-changesets.json or similar, and update the bot to also update languages.json.
@escapewindow @bhearsum Does this sound good to you? @flodolo and myself were debating earlier today whether this is the right way to go or do we need to wait another beta build to happen in order to populate the values?
Facts I understand so far, can one of you please confirm I'm correct?
firefox_primary_builds.jsonfile to populate https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly or any other downstream consumer, etc)productionis publishing the repo artifacts to the S3 bucketproduction(1) or let the https://github.com/release-services-robot force-push (2) do it.For (1) - that means that we're adjusting the files directly in this repo that we publish and that becomes the new source-of-truth
For (2) - the changes are being triggered by the rebuild function which basically meshes together the existing product-details repo, hgmo + Ship-it DB and creates a diff, if there's any change found. Note that the push happens automatically to
productionrather than via pull-requests.So to sum-up, there's two ways of updating product-details:
rebuildfunctionWho's publishing the Pulse message then?
Rebuild Product-detailsbutton in the Ship-it UI which, if I read right the JavaScript code in here hits the /product-details endpoint via javascript here which is described here as the Pulse message publisher in the API hereSo each time we push the button in the UI or a release is marked as shipped, there's a Pulse message being published.
The last dumb question that lingers in my head is: am I to assume there's a worker that monitors (basically that constantly runs this)to listen to the Pulse messaging queue in our GCP workload? Looking at the git history of this repo, I'm assuming there is, but I just want to make sure I'm not missing a piece of the puzzle.
If I'm right with above, this explains why deploying this to
productionneeds to UI-button-click, since the logic in here would return no changes, hence a no-op to publish afterwards. If so, I need to amend the docs in this PR.