- Shipped
- September 7, 2026 at 9:30 PM UTC
- Author
- Kamo
- Commit
- 1c03fa5
The lead view read "+373 606208888" back as "606208888". `formatPhoneDisplay` chose between national and international form by comparing the number's calling code against its `defaultCountry` argument — but that argument is the *parsing* hint, and the lead view rightly passes the LEAD's country so that a bare Moldovan number is read as Moldovan rather than as a fragment of an American one. A number matched against its own record's country always matches, so every non-US lead had its "+CC" stripped off. Worse, `formatNational()` on a number that is not a possible one for its country hands back the bare national digits with no grouping at all, which is how a Moldovan mobile reached the screen as an unreadable, undialable "606208888". Those are two different questions. Which country is this number from is a property of the record — a lead in Moldova, a vendor in Spain — and each caller answers it with that record's own country. Whose numbers may be shown without their code is a property of the reader, and there is one reader. HOME_PHONE_COUNTRY answers the second one now, so a US org still reads "(949) 374-7110" while Moldova, Germany, France, Spain and the UK each keep their code and get their own grouping from libphonenumber's metadata. A number too long for its country keeps its code too, rather than collapsing to a digit run that looks like a digit went missing. The contact card also re-renders its numbers when the lead's country changes, so picking the country after typing the number works as well as picking it before. The New Lead form has done that since the first report of this; this card, which is where the reporter was editing, never did.