* Before the PR is applied, the new tests should fail.
* After applying the PR, the new tests should pass.
* Coverage should stay at 100%.
* If you see the PR makes sense, or we discussed it and considered it should be accepted, you can add commits on top of the PR to tweak it, to add docs, tests, format, refactor, remove extra files, etc.
* Feel free to comment in the PR to ask for more information, to suggest changes, etc.

    label_strs = {label.name for label in pr.get_labels()}
    langs = []
    for label in label_strs:
        if label.startswith("lang-") and not label == lang_all_label:
            langs.append(label[5:])
    logging.info(f"PR #{pr.number} has labels: {label_strs}")
    if not langs or lang_all_label not in label_strs:
        logging.info(f"PR #{pr.number} doesn't seem to be a translation PR, skipping")
        sys.exit(0)

### Typical Pull Request Workflow -

**1. New PR**

- As a contributor, you submit a New PR on GitHub.
- We inspect every incoming PR and add certain labels to the PR such as `size:`,
  `comp:` etc.  At this stage we check if the PR is valid and meets certain
  quality requirements. For example, we check if the CLA is signed, PR has
  sufficient description, if applicable unit tests are added, if it is a

/// info | 信息

不幸的是，我不能仅仅信任那些有很多人批准的 PR。

多次发生过这样的情况：PR 有 3、5 个甚至更多的批准，可能是因为描述很吸引人，但当我检查时，它们实际上是坏的、有 bug，或者并没有解决它声称要解决的问题。😅

所以，真正重要的是你确实读过并运行过代码，并在评论里告诉我你做过这些。🤓

///

* 如果 PR 可以在某些方面简化，你可以提出建议，但没必要过分挑剔，很多东西比较主观（我也会有我自己的看法 🙈），因此尽量关注关键点更好。

### 测试 { #tests }

* 帮我检查 PR 是否包含**测试**。

* 确认在合并 PR 之前，测试**会失败**。🚨

* 然后确认合并 PR 之后，测试**能通过**。✅

        )
        pr = gh_repo.create_pull(
            title=message, body=body, base="master", head=branch_name
        )
        print(f"Created PR: {pr.number}")
    print("Finished")


if __name__ == "__main__":

/// info

很遺憾，我不能僅因為一個 PR 有好幾個核可就直接信任它。

發生過好幾次，PR 有 3、5 個甚至更多核可，可能是因為描述很吸引人，但當我實際檢查時，它其實是壞的、有 bug，或是根本沒有解決它宣稱要解決的問題。😅

所以，真的很重要的是你要實際閱讀並執行程式碼，並在留言中讓我知道你做過了。🤓

///

* 如果 PR 有機會再被簡化，你可以提出要求，但沒必要太過挑剔，很多事情是主觀的（我自己也會有主觀看法 🙈），所以最好聚焦在關鍵的事情上。

### 測試 { #tests }

* 幫我確認 PR 有**測試**。

* 檢查在 PR 之前，測試會**失敗**。🚨

* 然後檢查在 PR 之後，測試會**通過**。✅

/// info | 情報

残念ながら、承認が複数ついただけのPRを、そのまま信頼することはできません。

説明が魅力的なためか、3件、5件以上の承認がついていても、実際にPRを確認すると壊れていたり、バグがあったり、主張する問題を解決していなかったりすることが何度もありました。😅

ですので、実際にコードを読み、実行して確認し、それをコメントで知らせてもらえることが本当に重要です。🤓

///

* もしPRを簡素化できそうなら、その依頼をしても構いませんが、細かい点にこだわり過ぎる必要はありません。主観的な見方が多く（私にもあります 🙈）、基本的な点に集中できるとより良いでしょう。

### テスト { #tests }

* PRに**テスト**があるか確認を手伝ってください。

* PR前はテストが**失敗**することを確認します。🚨

Instead of adding suggestions to the translation PR, make the suggestions to the LLM prompt file for that language, in a new PR. For example, for Spanish, the LLM prompt file is at: [`docs/es/llm-prompt.md`](https://github.com/fastapi/fastapi/blob/master/docs/es/llm-prompt.md).

/// tip

    logging.info("Pushing branch")
    subprocess.run(["git", "push", "origin", branch_name], check=True)
    logging.info("Creating PR")
    pr = repo.create_pull(title=message, body=message, base="master", head=branch_name)
    logging.info(f"Created PR: {pr.number}")
    logging.info("Finished")


if __name__ == "__main__":

///

* If the PR can be simplified in a way, you can ask for that, but there's no need to be too picky, there might be a lot of subjective points of view (and I will have my own as well 🙈), so it's better if you can focus on the fundamental things.

### Tests { #tests }

* Help me check that the PR has **tests**.

* Check that the tests **fail** before the PR. 🚨