[ty] Consistent use of American english (in rules) (#19488)

## Summary

Just noticed this as a minor inconsistency in our rules, and had Claude
do a few more automated replacements.
This commit is contained in:
David Peter 2025-07-22 16:10:38 +02:00 committed by GitHub
parent da8aa6a631
commit 64e5780037
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
11 changed files with 36 additions and 36 deletions

View file

@ -13,7 +13,7 @@ declare_lint! {
/// Checks for f-strings in type annotation positions.
///
/// ## Why is this bad?
/// Static analysis tools like ty can't analyse type annotations that use f-string notation.
/// Static analysis tools like ty can't analyze type annotations that use f-string notation.
///
/// ## Examples
/// ```python
@ -38,7 +38,7 @@ declare_lint! {
/// Checks for byte-strings in type annotation positions.
///
/// ## Why is this bad?
/// Static analysis tools like ty can't analyse type annotations that use byte-string notation.
/// Static analysis tools like ty can't analyze type annotations that use byte-string notation.
///
/// ## Examples
/// ```python
@ -63,7 +63,7 @@ declare_lint! {
/// Checks for raw-strings in type annotation positions.
///
/// ## Why is this bad?
/// Static analysis tools like ty can't analyse type annotations that use raw-string notation.
/// Static analysis tools like ty can't analyze type annotations that use raw-string notation.
///
/// ## Examples
/// ```python
@ -88,7 +88,7 @@ declare_lint! {
/// Checks for implicit concatenated strings in type annotation positions.
///
/// ## Why is this bad?
/// Static analysis tools like ty can't analyse type annotations that use implicit concatenated strings.
/// Static analysis tools like ty can't analyze type annotations that use implicit concatenated strings.
///
/// ## Examples
/// ```python