Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add docs for adding a new l10n into product-details #89

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions procedures/release-duty/faq/faq.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
FAQ
===

This piece of docs tracks frequently-asked-questions during our releaseduty cycles.

Adding a new locale into Product-Details
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

`Product details`_ is a public JSON API which contains release
information for Mozilla products. More information on this can be found
in `here`_.

Each time a new locale is being added so that we’re able to
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Land an hg.mozilla.org change to add the locale
  2. Trigger a manual rebuild of product details in Ship It

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I stand corrected!

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean another locale = a new locale?

- review and merge the PR, either directly into ``production`` or via ``main`` and then follow-up with a push to ``production``
Copy link

@flodolo flodolo May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR is always done against production, because the JSON file doesn't exist in main

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the main branch used for anything? Should we make production the default branch and delete the main branch?

- 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|
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: this URL will fix itself once we merge as the abspath will become valid in the main repo.

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
3 changes: 2 additions & 1 deletion procedures/release-duty/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ Contents:
:glob:

desktop/*
faq/*
mobile/*
merge-duty/*

Expand Down Expand Up @@ -213,7 +214,7 @@ taskgroup in the inspector.
After ReleaseDuty
-----------------

After your tour of releaseduty, In the past it was customary to fix any documentation
After your tour of releaseduty, In the past it was customary to fix any documentation
or automation issues discovered. Now make sure you file any bugs so issues can be included
in a future sprint or work cycle.

Expand Down