fix(connect): locale-agnostic connection detection (fixes German / supersedes #319)

[Dominien]

Summary

`connect_with_person` currently returns `connect_unavailable` on every profile for users whose LinkedIn UI is not in English. On my German account every invite fails with `LinkedIn did not expose a usable Connect action for this profile.` even though the profile clearly renders a `Vernetzen` button.

Root cause

`core/browser.py` launches Playwright with `locale="en-US"`. That option only drives `navigator.language` + the `Accept-Language` header — LinkedIn ignores both for logged-in users and serves the UI in the language chosen under Settings → Account preferences → Display language on the account itself. So a US-locale browser can still render:

Account language	Connect	Follow	Pending	More
English (en)	Connect	Follow	Pending	More
German (de)	Vernetzen	Folgen	Ausstehend	Mehr
French (fr)	Se connecter	Suivre	En attente	Plus

`scraping/connection.py` only matched the English strings, so every non-English profile fell through to `unavailable`.

Changes

Kept `locale="en-US"` as a best-effort hint and added small per-locale tables in `scraping/connection.py` so detection works regardless of what LinkedIn actually renders:

• `STATE_BUTTON_MAP_BY_LOCALE` — click labels keyed by locale + state. Ships `en`, `de`, `fr`. New locales = one line.
• `_DETECTION_LABELS_BY_LOCALE` — labels used while parsing the action area.
• `_SECTION_HEADINGS_BY_LOCALE` — per-locale section headings that end the action area (`About` / `Info` / `Infos` / …).
• `_FIRST_DEGREE_MARKERS` — `· 1st` / `· 1.` / `· 1er`.
• `_MORE_ARIA_LABELS` — `More` / `Mehr` / `Plus`.
• `all_button_texts(state)` helper so locale-agnostic call sites (like the More menu) can build their locator text lists.

`detect_connection_state` now returns `tuple[ConnectionState, str]` where the second element is the detected locale, so the caller picks the right button without needing its own language guess. `connect_with_person` looks up `STATE_BUTTON_MAP_BY_LOCALE[locale][state]`; `_open_more_menu` builds its aria-label selector and menu-item regex dynamically from the locale table.

Why one PR for EN + DE + FR

#319 already proposed French support using an `is_french: bool` flag. That pattern doesn't generalize — adding German would require an `is_german: bool`, then Italian, Spanish, Dutch, etc. This PR introduces a single locale-keyed table so every new language is a one-line change in one file, and covers French as well to avoid leaving two overlapping PRs open. Credit to @vrpctaywal for pinning down the French case and the `_contains` helper shape.

Tests

• Updated the 9 existing `TestDetectConnectionState` cases for the new tuple return value.
• Added 6 German cases (connectable, follow_only, pending, incoming_request, already_connected, action-area cut-at-`Info`).
• Added 5 French cases (parity with feat: add French locale support for connection state detection #319).
• All 383 tests pass (`uv run pytest`).
• `uv run ruff check`, `uv run ruff format --check`, `uv run pre-commit run` — all clean.

Test plan

• `TestDetectConnectionState` — 20 unit tests cover EN + DE + FR
• Full test suite — 383 passed
• Manual: `connect_with_person` on a German profile with a `Vernetzen` button (verified locally — previously returned `connect_unavailable`, now sends the invite)
• Manual: `connect_with_person` on a French profile with `Se connecter`
• Manual: `connect_with_person` on a profile with only `Folgen` → goes through More menu

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

Replaces the hard-coded English-only button strings in connection.py with locale-keyed tables (EN/DE/FR), changes detect_connection_state to return (state, locale), and threads that locale through connect_with_person so the right on-screen label is clicked regardless of the account's display language. The design is clean, well-tested, and easy to extend for additional locales.

Confidence Score: 5/5

Safe to merge — all findings are P2 suggestions; the core locale-detection and button-click logic is correct.

All three inline comments are P2 (style/theoretical edge cases). The detection loop, locale-keyed button map, and extractor integration are logically sound. Test coverage is comprehensive across EN/DE/FR with only one missing French edge-case test. No P0/P1 issues found.

No files require special attention; the two minor concerns in connection.py (· 1. marker anchoring and "Plus" aria-label breadth) are low-risk in practice.

Important Files Changed

Filename	Overview
linkedin_mcp_server/scraping/connection.py	Core locale-detection logic: well-structured locale tables, correct detection loop order; minor concerns around the unpinned · 1. German marker and the broad "Plus" aria-label fragment.
linkedin_mcp_server/scraping/extractor.py	Correctly unpacks the new (state, locale) tuple and uses STATE_BUTTON_MAP_BY_LOCALE[locale][state] for button clicks; _open_more_menu builds a multi-locale selector but the "Plus" substring could match unintended French buttons.
tests/test_scraping.py	Good coverage of EN/DE/FR states; only gap is a missing test_incoming_request_fr case to match German parity.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[profile_text] --> B{· 1st / · 1. / · 1er\nin first 300 chars?}
    B -- yes --> C[return already_connected, en]
    B -- no --> D[_extract_action_area\ncut at section heading]
    D --> E{Try EN labels}
    E -- Pending found --> F[return pending, en]
    E -- Accept+Ignore found --> G[return incoming_request, en]
    E -- Connect found --> H[return connectable, en]
    E -- Follow found --> I[return follow_only, en]
    E -- no match --> J{Try DE labels}
    J -- Ausstehend found --> K[return pending, de]
    J -- Annehmen+Ignorieren --> L[return incoming_request, de]
    J -- Vernetzen found --> M[return connectable, de]
    J -- Folgen found --> N[return follow_only, de]
    J -- no match --> O{Try FR labels}
    O -- En attente found --> P[return pending, fr]
    O -- Accepter+Ignorer --> Q[return incoming_request, fr]
    O -- Se connecter found --> R[return connectable, fr]
    O -- Suivre found --> S[return follow_only, fr]
    O -- no match --> T[return unavailable, en]
    H & M & R --> U[connect_with_person\nSTATE_BUTTON_MAP_BY_LOCALE\nlookup locale+state]
    G & L & Q --> U
    I & N & S --> V{_open_more_menu\nfinds Connect variant?}
    V -- yes --> U
    V -- no --> W[return follow_only result]
    U --> X[click_button_by_text\nbutton_text, scope]

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: tests/test_scraping.py
Line: 843-868

Comment:
**Missing `incoming_request` test for French locale**

The French test block covers `already_connected`, `connectable`, `follow_only`, `pending`, and the heading-cut case — but `incoming_request` is absent. German has `test_incoming_request_de` and English has `test_incoming_request`. Adding a French case would verify that `Accepter` + `Ignorer` together trigger `("incoming_request", "fr")`, the same parity the PR explicitly aims for with #319.

```python
def test_incoming_request_fr(self):
    text = "Jane Doe\n\n--\n\nParis\n\nAccepter\nIgnorer\nPlus"
    assert detect_connection_state(text) == ("incoming_request", "fr")
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/connection.py
Line: 79-83

Comment:
**German degree marker `· 1.` is an unpinned substring**

`· 1.` (4 characters) would match any string containing that sequence in the first 300 chars — including `· 1.5K followers` or `· 1.000 Kontakte` if LinkedIn ever renders follower/connection counts with the `·` (U+00B7) separator near the top of the extracted text. The English marker `· 1st` and French `· 1er` are terminated by a letter that prevents this drift. Adding a trailing space or newline anchor reduces the risk:

```python
_FIRST_DEGREE_MARKERS: tuple[str, ...] = (
    "\u00b7 1st",   # en
    "\u00b7 1. ",   # de – "· 1. Grades"; trailing space guards against "· 1.5K"
    "\u00b7 1er",   # fr
)
```

(The trailing space works because the degree badge text is always followed by a space before "Grades" / "Kontakt".)

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/connection.py
Line: 85-88

Comment:
**`"Plus"` in `_MORE_ARIA_LABELS` could match non-More buttons in French**

Playwright's `aria-label*='Plus'` is a case-sensitive *substring* match. On a French profile LinkedIn renders several buttons whose accessible name contains "plus": "Afficher plus" (show-more toggles), "Ajouter une section" expand controls, etc. If any of those appear in `main` before the three-dot menu button, `more_btn.first.click()` fires on the wrong element. The English `"More"` and German `"Mehr"` are less ambiguous, but "Plus" is common enough in French UI strings to cause spurious clicks.

One mitigation is to also require `aria-label` to *end with* the label (e.g. `aria-label$='Plus'`), which is how LinkedIn normally labels the three-dot menu ("Plus d'options" or just "Plus"):

```python
more_selector = ", ".join(
    f"main button[aria-label$='{label}']" for label in _MORE_ARIA_LABELS
)
```

Alternatively, keep substring matching but place the French entry last so a false positive only fires if neither the English nor German More button was found first.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(connect): locale-agnostic detection ..." | Re-trigger Greptile}

[greptile-apps]

Missing incoming_request test for French locale

The French test block covers already_connected, connectable, follow_only, pending, and the heading-cut case — but incoming_request is absent. German has test_incoming_request_de and English has test_incoming_request. Adding a French case would verify that Accepter + Ignorer together trigger ("incoming_request", "fr"), the same parity the PR explicitly aims for with #319.

def test_incoming_request_fr(self):
    text = "Jane Doe\n\n--\n\nParis\n\nAccepter\nIgnorer\nPlus"
    assert detect_connection_state(text) == ("incoming_request", "fr")

Prompt To Fix With AI

This is a comment left during a code review.
Path: tests/test_scraping.py
Line: 843-868

Comment:
**Missing `incoming_request` test for French locale**

The French test block covers `already_connected`, `connectable`, `follow_only`, `pending`, and the heading-cut case — but `incoming_request` is absent. German has `test_incoming_request_de` and English has `test_incoming_request`. Adding a French case would verify that `Accepter` + `Ignorer` together trigger `("incoming_request", "fr")`, the same parity the PR explicitly aims for with #319.

```python
def test_incoming_request_fr(self):
    text = "Jane Doe\n\n--\n\nParis\n\nAccepter\nIgnorer\nPlus"
    assert detect_connection_state(text) == ("incoming_request", "fr")
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

German degree marker · 1. is an unpinned substring

· 1. (4 characters) would match any string containing that sequence in the first 300 chars — including · 1.5K followers or · 1.000 Kontakte if LinkedIn ever renders follower/connection counts with the · (U+00B7) separator near the top of the extracted text. The English marker · 1st and French · 1er are terminated by a letter that prevents this drift. Adding a trailing space or newline anchor reduces the risk:

_FIRST_DEGREE_MARKERS: tuple[str, ...] = (
    "\u00b7 1st",   # en
    "\u00b7 1. ",   # de – "· 1. Grades"; trailing space guards against "· 1.5K"
    "\u00b7 1er",   # fr
)

(The trailing space works because the degree badge text is always followed by a space before "Grades" / "Kontakt".)

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/connection.py
Line: 79-83

Comment:
**German degree marker `· 1.` is an unpinned substring**

`· 1.` (4 characters) would match any string containing that sequence in the first 300 chars — including `· 1.5K followers` or `· 1.000 Kontakte` if LinkedIn ever renders follower/connection counts with the `·` (U+00B7) separator near the top of the extracted text. The English marker `· 1st` and French `· 1er` are terminated by a letter that prevents this drift. Adding a trailing space or newline anchor reduces the risk:

```python
_FIRST_DEGREE_MARKERS: tuple[str, ...] = (
    "\u00b7 1st",   # en
    "\u00b7 1. ",   # de – "· 1. Grades"; trailing space guards against "· 1.5K"
    "\u00b7 1er",   # fr
)
```

(The trailing space works because the degree badge text is always followed by a space before "Grades" / "Kontakt".)

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

"Plus" in _MORE_ARIA_LABELS could match non-More buttons in French

Playwright's aria-label*='Plus' is a case-sensitive substring match. On a French profile LinkedIn renders several buttons whose accessible name contains "plus": "Afficher plus" (show-more toggles), "Ajouter une section" expand controls, etc. If any of those appear in main before the three-dot menu button, more_btn.first.click() fires on the wrong element. The English "More" and German "Mehr" are less ambiguous, but "Plus" is common enough in French UI strings to cause spurious clicks.

One mitigation is to also require aria-label to end with the label (e.g. aria-label$='Plus'), which is how LinkedIn normally labels the three-dot menu ("Plus d'options" or just "Plus"):

more_selector = ", ".join(
    f"main button[aria-label$='{label}']" for label in _MORE_ARIA_LABELS
)

Alternatively, keep substring matching but place the French entry last so a false positive only fires if neither the English nor German More button was found first.

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/connection.py
Line: 85-88

Comment:
**`"Plus"` in `_MORE_ARIA_LABELS` could match non-More buttons in French**

Playwright's `aria-label*='Plus'` is a case-sensitive *substring* match. On a French profile LinkedIn renders several buttons whose accessible name contains "plus": "Afficher plus" (show-more toggles), "Ajouter une section" expand controls, etc. If any of those appear in `main` before the three-dot menu button, `more_btn.first.click()` fires on the wrong element. The English `"More"` and German `"Mehr"` are less ambiguous, but "Plus" is common enough in French UI strings to cause spurious clicks.

One mitigation is to also require `aria-label` to *end with* the label (e.g. `aria-label$='Plus'`), which is how LinkedIn normally labels the three-dot menu ("Plus d'options" or just "Plus"):

```python
more_selector = ", ".join(
    f"main button[aria-label$='{label}']" for label in _MORE_ARIA_LABELS
)
```

Alternatively, keep substring matching but place the French entry last so a false positive only fires if neither the English nor German More button was found first.

How can I resolve this? If you propose a fix, please make it concise.