The advice arrived in the language she was trying to read her way out of

Reported as "the Portuguese option isn't translating the advice in
English — it's just reprinting Portuguese." Nothing was wrong with
targetFor. It was reading a direction the account could not leave.

learnerPairs held only zh, so SetPair refused learning_pair for pt-PT
and every Portuguese account was learning_en by force. targetFor then
did exactly what it says: explanations follow the half of the pair she
is not learning, which for a forced learning_en account is Portuguese.
A Portuguese document, corrected in Portuguese, explained in
Portuguese, with no way to ask for English — correct behaviour derived
from a fact about the roster that was no longer true.

The note in learnerPairs was written one phase too early to see it. It
said turning a pair around needs a word list and a dictionary reading
into English, and that fr, es and pt-PT had neither. Portuguese has
both. Word boundaries are spaces — the megabyte jieba needs is a
property of a writing system that doesn't use them, not a debt every
pair owes. And the dictionary arrived with dict.db, which reads pt→en
as readily as en→pt; dreamProvider.reverse has been answering that
question since the pair shipped. What was actually blocking the pair a
native English speaker learning Portuguese needs was this list.

So pt-PT joins it, and the pt-PT pack gets the learner copy the control
renders from — each label in the language of whoever would pick it,
since someone on the wrong side of that switch cannot read the side
they are reaching for. fr and es clear the same two bars through the
same dict.db and stay out: their packs carry no learner block yet,
which is a translation question rather than a data one, and the server
should keep saying no until one is written.

Two things that assumed learning_pair meant Chinese, now that it
doesn't. The segmenter gate reads the pair as well as the direction, or
a Portuguese learner would load a megabyte of Chinese word list and
hover Portuguese words at /api/hanzi. And that endpoint's own comment
justified skipping providerFor with a guarantee it no longer has; the
real guarantee was always the caller's — it is only ever asked about
tokens the Chinese segmenter found — and a stray lookup was already
safe, answering a miss with an empty 200.

Tests in both packages. The auth test that pinned pt-PT's refusal now
pins its acceptance, with fr and es still refused; the suggestions test
pins the consequence where it actually lands, which is the language she
reads her advice in.

Claude-Session: https://claude.ai/code/session_01GJHNvirh7Hzhc9RL3HAvz7

web/src/i18n/packs/pt-PT.ts

@@ -42,6 +42,25 @@ export const ptPT: Pack = {
   nativeName: 'Português',
   locale: 'pt-PT',
 
+  // pt-PT is the second pair Petal can be *learned* toward: spaces do the
+  // segmenting a Latin script needs, and dict.db already reads Portuguese into
+  // English (see auth.learnerPairs for both halves of that argument).
+  //
+  // Each label is written for whoever would pick it, which is why they are not
+  // in the same language as each other. A native Portuguese speaker practising
+  // English reads the first; an English speaker learning Portuguese reads the
+  // second, and would not be helped by being told "Português" in Portuguese.
+  //
+  // This is also the switch that decides which language Petal *explains* in, so
+  // it is the difference between a Portuguese document annotated in Portuguese
+  // and the same document annotated in English.
+  learner: {
+    label: 'Estou a aprender · I am learning',
+    toEn: 'inglês',
+    toPair: 'Portuguese',
+    failed: 'Não foi possível mudar · Couldn’t switch — nothing changed',
+  },
+
   app: {
     duplicateTitle: (title) => `${title} (cópia)`,
     garden: 'Jardim de palavras',