if label.name == "lang-all":
                is_lang = True
                break
        for review in pr.reviews.nodes:
            if review.author:
                authors[review.author.login] = review.author
                if is_lang:
                    translation_reviewers[review.author.login] += 1
        if pr.state == "MERGED" and pr.author:
            if is_lang:

* **Easier onboarding**: New contributors have clear guidance on which spelling to use
* **Better searchability**: Finding code and documentation becomes more predictable
* **Reduced review friction**: Less time spent on spelling corrections during PR reviews
* **Professional appearance**: Consistent APIs and documentation appear more polished
* **Clearer contribution guidelines**: [CONTRIBUTING.md](../../CONTRIBUTING.md) now includes this requirement

        )

        if pr.state == "open" and awaiting_label in label_strs:
            logging.info(
                f"This PR seems to be a language translation and awaiting reviews: #{pr.number}"
            )
            if already_notified_comment:
                logging.info(
                    f"This PR #{pr.number} was already notified in comment: {already_notified_comment.url}"

* Add the specific language label.
* Add the label `awaiting-review`.

The label `awaiting-review` is special, only used for translations. A GitHub Action will detect it, then it will read the language label, and it will update the GitHub Discussions managing the translations for that language to notify people that there's a new translation to review.

* Review those pull requests, requesting changes or approving them. For the languages I don't speak, I'll wait for several others to review the translation before merging.

/// tip

# This is needed for all Clang17 builds but must not be present in GCC builds.
common:rbe_linux_cpu --copt=-Wno-error=unused-command-line-argument
# This was added in clang-16 by https://reviews.llvm.org/D133574.
# Can be removed once upb is updated, since a type definition is used within
# offset of in the current version of ubp.

* They are rarely updated after creation and initial review, and then become hard to follow, especially after important decisions are made
* They are not synced with the code to reflect the eventual solution that is committed
* Google Docs is not a "code-oriented" tool, like Markdown can be
* Review in Google Docs is not as simple as a PR code review in GitHub

## Decision

* Suggest a new **feature**.

**Note**: if you do it, then I'm going to ask you to also help others. 😉

## Review Pull Requests { #review-pull-requests }

You can help me review pull requests from others.

Again, please try your best to be kind. 🤗

---

Here's what to keep in mind and how to review a pull request:

### Understand the problem { #understand-the-problem }

      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
        CONFIG: >
          {
            "approved-1":
              {
                "number": 1,
                "await_label": "awaiting-review"
              }

   * the first are ignored.
   */
  public static <E> ImmutableSet<E> of(E e1, E e2) {
    return new RegularSetBuilderImpl<E>(2).add(e1).add(e2).review().build();
  }

  /**
   * Returns an immutable set containing the given elements, minus duplicates, in the order each was