Your German White Page Smells American: Why Translation Isn't Localization and What a Local Clocks in Five Seconds

Your white page isn't seen by a buyer — cloaking sends them to the money page. It's scanned by moderation: an automatic classifier before the ad runs, and a human moderator. And a human moderator with local eyes isn't "analyzing your lander." Something just snags. In Germany dates use periods, the euro goes after the number, German addresses have no state field — they never have — and 1,234.56 reads either as twelve hundred or as one point two, no way to tell. The text is German. The skeleton is American.

This isn't taste and it isn't translation quality. It's an architecture bug: geo got wired in as an interface language when it's actually a build parameter. Number format, currency position, date component order, postcode mask, what goes in the footer legal — plus a dozen more fields — are all functions of one variable. Change the country and all fifteen have to be recomputed. A translator recomputes one field out of fifteen.

A note on dates before we start, since this article is about exactly this failure: dates in the body text are written out in words so nobody has to guess. Inside code blocks, tables and the local-format examples they stay in the local format on purpose — that's the demonstration.

What follows: three layers of leakage — formats, footer legal, verifiability — plus one bogeyman that's six years out of date and one question no generator solves. The fifteen-point checklist is at the end; if you're short on time, scroll straight there.

---

Where the American skeleton comes from — and who's actually looking that closely

"The template is American" sounds like a figure of speech. It's a literal line in a config file. Unicode CLDR — the data browsers implement through Intl, that every OS and most frameworks ship — has a mechanism called defaultContent: a bare language code expands into a specific country. Same mechanism gives you pt → pt-BR and es → es-ES. So a lander for Portugal with lang="pt" quietly gets Brazilian data, and one for Mexico with lang="es" gets Spanish data: different numbers, different currency position, different clock format. No error is thrown anywhere. HTML templates, UI kits and LLM output all default to those locales. Translation changes the words; it doesn't touch the data structure.

And here's the part almost nobody clocks: the US template also arrives with NO footer legal. The United States has no federal counterpart to the Impressum — not one federal act requires a commercial site to disclose the legal entity name, registered address, registration number or tax ID; the privacy-policy obligation lives at state level only (baseline CalOPPA, in force since 1 July 2004). The missing legal footer on your "German" lander isn't your decision and it isn't an oversight. It's an American default you inherited along with the font stack.

Who even sees your white page up close? Moderation, first — an automatic classifier before the ad runs and a human moderator with local eyes; the real buyer never sees it, cloaking sends them to the money page. And the strings in your legal block can be checked against a public registry by anyone who decides to vet you. Three of them:

The suspicious visitor. Germany's Verbraucherzentrale publishes consumer guidance telling shoppers to cross-check an online store's Impressum against the Handelsregister entry — people are literally coached to do it, and a visitor who lands on your white and inspects it brings exactly that diligence.

Whoever files a DSA notice (Regulation (EU) 2022/2065, Art. 16) has to attach a "sufficiently substantiated explanation" and the exact URL — a human writes that, and under Art. 16(3) a substantiated notice creates "actual knowledge" at the hosting provider.

The network's compliance team when you apply for an offer. Being straight about this one: nobody publishes the rules, it all happens behind closed doors, and there's no number anyone can point to.

For all three, the footer legal isn't text. It's a set of strings, each of which can be checked against a public registry in seconds. Every item on the checklist at the end is something a stranger can confirm or refute without asking you a single question. What gets tested isn't tidiness. It's existence.

And it isn't only a human looking. A page whose data doesn't line up with its geo reads as a template — and "templated" is exactly the signal both automated moderation and a human moderator use to file a lander under the same family of generated pages. How that review actually works is a big separate subject (the mechanics are in a separate piece, how Facebook and Google moderation catches you in 2026), and it isn't what this article is about; one fact is enough here: a format that doesn't match the geo works against you on two levels at once. A person sees a fake. A check sees a stamp. So the fifteen fields below aren't cosmetic — the less a page looks like an en-US locale wearing a translation, the less either one has to grab onto.

---

Numbers, dates, currency: what shows in five seconds

Values per Unicode CLDR — the same data every browser formats from.

Flat, if the table doesn't render for you:

US — 1,234.56 · $ before, no space · M/d/yy (month first) · 12h AM/PM
DE — 1.234,56 · € after the number, NBSP · dd.MM.yy · 24h
PL — 1 234,56 (NBSP thousands) · zł after, NBSP · d.MM.y · 24h
NL — 1.234,56 · € before, NBSP · dd-MM-y (hyphen!) · 24h
BR — 1.234,56 · R$ before, NBSP · dd/MM/y · 24h
IN — 12,34,567.89 (3:2:2) · ₹ before, no space · dd/MM/yy · 12h AM/PM
UK — 1,234.56 · £ before, no space · dd/MM/y · 24h

The date column is each locale's own short pattern, which is why the year is two-digit in some (yy) and full in others (y) — that's how CLDR defines it, not sloppiness on anyone's part.

A slash on its own doesn't out you as American — the order does. 03/04/2026 is March 4 in the US and April 3 in the UK, Brazil and India. It's the most dangerous leak precisely because it doesn't look broken: the page isn't malfunctioning, it's just lying about the date.

The Polish thousands separator is not a period: in CLDR, pl uses a non-breaking space. This is the single most common mistake in "PL localization." On top of that, minimumGroupingDigits = 2 — a four-digit number isn't grouped at all. Before: 1 000 zł. After: 1000 zł. The second one is correct.

A non-breaking space means non-breaking. Use a regular one and, in a narrow container, 1.234,56 stays on one line while € drops to the next. That's the five-second tell: nobody fines you for it, everybody sees it.

India is the mixed case, and it's the one people break most often: the date is day-first (dd/MM) but the clock is American — CLDR timeData for IN sets preferred: 'h', i.e. 12-hour with AM/PM. Anyone who "fixes" the Indian locale by copy-pasting from the German one breaks the clock.

Language does not determine format. de-DE puts € after the number; de-AT puts it before and groups with a non-breaking space; de-CH uses a period as the decimal separator and an apostrophe for thousands: 1'234.56. One language, three incompatible formats. And an honest counter-example so this doesn't turn into cherry-picking: nl-NL and nl-BE are identical in these fields. The "country beats language" rule doesn't hold for every pair.

Two-minute test. Open the console and run your own values through it: new Intl.NumberFormat('de-DE',{style:'currency',currency:'EUR'}).format(1234.56) and new Intl.DateTimeFormat('de-DE').format(new Date()). A mismatch with what's on your page isn't a matter of opinion — it's a mismatch with the data every browser on earth runs on.

There's one practical takeaway from the whole table: a format is a setting, not copy. Where geo drives the build locale, all seven rows recompute from a single country switch — that's how we do it in white-lands.com, and how any decent i18n layer does it. Where geo is a language dropdown, those same fields get hand-patched on every lander, and they don't fall apart on the first one — they fall apart on the fifth.

---

Address and postcode: field order isn't cosmetic

A State field on a German form is the fingerprint of somebody else's address model. Per current Google Address Data Service data (which powers Chrome autofill and a lot of checkout forms), a region is required in the postal format in US, BR and IN — and absent in DE, PL, NL, UK (post town instead). Without that caveat the claim is misleading: Bundesländer, voivodeships and provinces do exist administratively — they just aren't part of the postal address. A form field and regional targeting are two different things.

A note on sourcing: the file testdata/countryinfo.txt in the google/libaddressinput repo — cited by half the i18n articles out there — is a test fixture, out of sync with the live service (it still gives the UK a county that Google removed from the format, and pre-reform Indian states). Cite the service, not the file.

The Polish postcode is not five digits in a row. Poczta Polska spells it out: "kod numeryczny pięciocyfrowy w układzie XX−XXX," and the digits should not be separated by spaces. A ^\d{5}$ validator inherited from a US template rejects every genuine Polish postcode. Before: 00950 Warszawa. After: 00-950 WARSZAWA.

The Dutch one is stricter than it looks. Google's live regex is [1-9]\d{3} ?(?:[A-RT-Z][A-Z]|S[BCE-RT-Z]): the first digit can't be 0, and the combinations SA, SD and SS are never issued. 0000 AA and 1234 SS sail through a naive check and blow up on a real form.

The British county isn't needed. Royal Mail's Programmers Guide is blunt about it: a county is not required in a correct postal address, and the Former Postal County field was removed from the raw PAF data back in December 2000. The Post Town is mandatory. The letters Q, V and X are not used in the first position, I and Z not in the second, and C, I, K, M, O, V not in the second half of the postcode.

Germany. The canonical example from UPU documentation: Erich Müller / Goethestr. 13 / 22767 HAMBURG. No DEUTSCHLAND line in domestic mail. In Deutsche Post Direkt's own ADDRESSFACTORY specification, the word "Bundesland" doesn't appear once.

Where the sources disagree, I say so — I don't pick one and pretend. The official Correios guide puts the CEP first on the last line (01311-000 São Paulo/SP), while Google's data specifies City-UF with the CEP on the line below; both forms occur in the wild. India has no single canonical order at all: the India Post template filed with the UPU gives "city / state / PIN," Google outputs the PIN on the same line as the city with the state below. For form layout, follow Google's data; for physical mail, India Post/UPU. The PIN itself is 6 digits, first digit is the postal zone 1–9, with 9 assigned to the Army Postal Service. (Introduction date and the DIGIPIN geocode rolled out in 2025 are in the sources note at the end — neither changes what you put on a form.)

Two-minute test. Run an address from your own lander through the national postal operator's address-lookup service. No such service for your geo? That's already useful to know. There is one and the address doesn't resolve? You found out before your visitor did.

---

Phone: notation and the number itself are two separate problems

Notation

First, let's kill a popular one. "Parentheses around the area code are an Americanism" is technically wrong: ITU-T E.123 §7.2 explicitly prescribes parentheses in national notation and forbids them only in international notation. In libphonenumber, the US national format is defined as ($1) $2-$3 and applies across the whole NANP zone, Canada included ((416) 555-1234) — but Brazil also wraps the DDD in parentheses via nationalPrefixFormattingRule="($FG)", giving (11) 91234-5678, and Chile gives (2) 2123 4567. Parentheses are a NANP-and-parts-of-Latin-America convention, not a mark of Americanness.

The American tell is the combination: parentheses with no leading zero + a hyphen before the last four + exactly 3-3-4. National formats in libphonenumber: DE 030 12345678, PL 12 345 67 89, NL 06 12345678, IN 098765 43210, GB 020 1234 5678 — spaces everywhere.

• Germany. DIN 5008: the area code is separated by a single space (0351 20860358), an extension is attached with a hyphen (06421 201-0), international is +49 30 3432622-113; no parentheses around the Vorwahl, no slashes, no inconsistent spacing. One correction to a date that keeps circulating on blogs: free grouping of the subscriber number has been in effect since the November 2001 edition, not 2020. That edition killed right-to-left pair grouping; DIN 5008:2020-03 changed nothing about number notation. DIN 5008 itself is a paid, advisory business-correspondence standard, not a telecom requirement.
• Netherlands. There is no regulator requirement: ACM maintains the numbering plan, not typography. Taaladvies recommends grouping in twos from right to left with a thin space, and when the count is odd, the first three as a group: 010-123 45 67. Onze Taal phrases it more loosely (twos or threes) and lists the spaces-only variant first — that version becomes a clickable tel: link on mobile.
• Poland. There is no codified rule at all: PWN's language helpline says flatly that no such rules exist in the linguistic literature, and that the area code does not need parentheses.

The number itself

A "random" number made up by hand or by a model is almost always somebody's real one. The best example runs the other way: Globo's telenovela "Sabor da Paixão" (episode of 27 January 2003) showed a genuine mobile number on screen, and a São Paulo court awarded the owner compensation of 50 minimum wages, noting specifically that the broadcaster hadn't even checked whether the number was in use (ConJur, 28 January 2008).

There is legitimate source material: numbers the regulators reserved for exactly this.

Reserves also exist in Australia (ACMA), Sweden (PTS) and France (ARCEP) — in the French decision 2018-0881 the prefixes themselves aren't published.

Bundesnetzagentur states explicitly that these numbers may be displayed, printed and spoken in media without permission; Ofcom notes that its numbers are not allocated to operators and will not be for the foreseeable future. Two corrections: Germany's fictitious mobile numbers were provided by operators, not the regulator — legally a different status. And the "British drama number 020 7123 1000" doing the rounds on aggregator sites is fabricated; Ofcom never reserved it.

555-1234 died in 2016. Per the Industry Numbering Committee decision (May 2016), approved by the FCC in September 2016, the rest of the 555 range went back into the general NANPA pool.

Where there's no reserve, there's no reserve. Any "list of fictitious Polish numbers" is made up — call one and a real person picks up. There's no pretty answer here: either a page that doesn't need a phone at all, or a real number you control.

And toll-free: 1-800 on a European lander is an instant fail. Locally: DE (0)800 + seven digits; UK, the whole 080 range; NL and BR 0800; PL 800 — though in the numbering plan itself that's classified as "usługi sieci inteligentnych," with the free-of-charge status fixed in UKE tariff rules rather than in the plan text; IN 1800, dialed directly with no trunk prefix, 8–13 digits in total (also industry practice — there's no verbatim line for it in the National Numbering Plan).

---

Footer legal: not "we have a Privacy Policy" but what actually has to be in it, country by country

Composition per primary sources. Not legal advice — the norms show what gets cross-checked.

I didn't verify the UK withdrawal period, so it isn't printed here: post-Brexit British consumer law runs separately from Directive 2011/83/EU, and you can't transplant the European 14 days onto it unchecked.

Here's the line that breaks the "one translation across all geos" idea: 14 days in the EU versus 7 in Brazil versus zero in the US. The FTC Cooling-Off Rule (16 CFR Part 429) covers only sales where the seller personally solicited the buyer away from the seller's permanent place of business, and expressly excludes transactions conducted entirely by phone or mail. And if the lander poses as a shop, a European Terms document translated word-for-word into pt-BR promises 14 days where Brazilian law gives 7 — a false promise in a document you published yourself, and a moderator or complainant spots the mismatch at once.

The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025 and covers e-commerce. The micro-enterprise exemption (fewer than 10 employees and turnover or balance sheet total not exceeding €2m) applies only to the services part. And the mismatch people get burned on: EN 301 549 is harmonized under Directive 2016/2102 on public-sector accessibility, not under the EAA — a "we comply with EN 301 549" badge proves nothing about EAA.

Two myths busted. A phone number is not mandatory in a German Impressum: CJEU judgment of 10 July 2019 in case C-649/17 — no specific means of contact is prescribed. And the "two-click rule" isn't a norm at all, it's a permissive BGH precedent of 20 July 2006 (I ZR 228/03).

Ten-second stale-template test. Search the footer legal for "§ 5 TMG." Found it? The block was copied from a source older than May 2024, because that law no longer exists (DDG, BGBl. 2024 I Nr. 149 of 13 May 2024; the substance of the norm was carried over). While you're there, check that the penalty isn't attributed to "§ 11 Abs. 3 DDG" — no such provision exists; the correct pairing is § 33 Abs. 2 Nr. 1 + § 33 Abs. 6 Nr. 3 DDG. The punchline: the fake citation spreads mostly through vendor Impressum generators. British equivalent: a citation to The Companies (Trading Disclosures) Regulations 2008 — repealed and replaced by SI 2015/17 on 31 January 2015.

What it looks like once it's assembled

Germany, § 5 DDG
[Firma] GmbH
[street and house number]
[PLZ] [Stadt]
Tel.: 040 66969 042
E-Mail + second contact channel
Vertreten durch: [Geschäftsführer]
Registergericht: AG [...], HRB [...]
USt-IdNr.: only if assigned
Withdrawal: 14 days
Price: 1.234,56 €
Date: 20.07.2026

Brazil, Decreto 7.962/2013
[Razão social] Ltda.
CNPJ: [14 characters, verifiable]
[Rua], [number] — [Bairro]
[CEP] [Cidade]/[UF]
Tel.: (11) [...]
E-mail: [...]
Withdrawal: 7 days
Price: R$ 1.234,56
Date: 20/07/2026

The address is deliberately left empty, like the rest of the company data: dropping someone else's or a non-existent one in there is exactly the § 269 StGB problem I cover in the next section. The phone in the German block comes from the Bundesnetzagentur reserve.

Compare the two blocks once more: neither derives from the other. A German Impressum is not a translated About us, and a Brazilian footer is not an Impressum with the registration number swapped out. The set of legal pages is bound to the country as tightly as the number format is, which is why in white-lands.com it's assembled alongside the other geo fields rather than translated separately. By hand it's perfectly doable too — just keep the table above open, because what people miss is rarely a whole page. It's one line inside one.

---

Verifiability: a company detail isn't text, it's a pointer into a public database

What gets tested is existence, not tidiness.

Three corrections to things the industry repeats unchecked.

"A Handelsregister extract costs €4.50" — obsolete since 1 August 2022. DiRUG abolished the fee. Free public verification of German company data has existed for roughly four years, which means the habit of "nobody's going to dig into Germany anyway" is older than the ability to dig.

"Check the VAT number in VIES and you'll see the company name" — untrue for Germany. Direct query: DE811569869 → isValid: true, but name: "---" and address: "---". Same for Spain; France, Italy, Poland and the Netherlands return everything. The conclusion for the main geo: VIES confirms that a number exists, not that it belongs to the company in your Impressum. The person checking has to go to the Handelsregister — and does.

"VIES said invalid, so the outfit is fake" — also untrue. The European Commission lists three causes: the number doesn't exist; the number isn't activated for intra-EU transactions; the registration isn't complete. The response doesn't distinguish between them. Germany is a separate case on top of that: the domestic Steuernummer isn't a VAT number at all and is never checkable in VIES — intra-EU requires a USt-IdNr from the BZSt.

A checksum catches a typo, not a forgery. The Polish NIP's last digit is a check digit (modulo 11); the algorithm is open and implemented in every validation library. I couldn't find a Ministry of Finance instrument that specifies those exact weights — it's practice reproduced identically by all implementations, and it checks out empirically against real NIPs pulled from the state KRS registry. Ten random digits pass in only ~9% of cases. But 1111111111, 0000000000 and 9876543210 pass the algorithm perfectly, and not one of them is in the registry. The Brazilian CNPJ works the same way: the check digits confirm the absence of a typo; only Cartão CNPJ confirms the company exists. (For the record: from 31 July 2026 the CNPJ becomes alphanumeric — 14 positions are retained, letters may appear in the first 12, the check digits stay numeric, existing numbers don't change, and the letters encode no state.)

Which gives the rule for this section — and it has to be phrased precisely. The temptation is to say "invented data is worse than missing data." The courts say otherwise. OLG Frankfurt a.M. (judgment of 14 March 2017, case 6 U 44/16) held placeholders like Registergericht: Amtsgericht 000, Registernummer: HR 0000, DE 00000000 to be unfair competition: the reader can't tell whether registration is absent, the data is being concealed, or it's temporarily unavailable. And in the same breath: "Falsche Angaben sind ebenso unlauter wie fehlende Angaben" — false information is unfair to the same degree as missing information. Meanwhile, per OLG Hamm (2 April 2009, 4 U 213/08), omitting a mandatory detail is itself an infringement. Working rule: if a requirement doesn't apply to you, omit the field — don't fill it with zeros. And only omit what genuinely doesn't apply.

Then there's the red zone. The asymmetry is brutal: an empty legal footer in Germany is a dormant administrative matter; someone else's legal footer is a criminal offense in both jurisdictions. In Germany that's § 269 StGB (Fälschung beweiserheblicher Daten, up to 5 years), with § 263 added when a consumer is defrauded. The phenomenon even has a name — Impressumsdiebstahl — it's a signature marker of a fake shop, it's actively hunted, and the company whose details you lifted becomes a claimant against you. In Brazil, using someone else's CNPJ is Art. 299 CP (falsidade ideológica) coupled with Art. 171. One caveat, or I'm overstating this: I couldn't find published convictions specifically for "someone else's company data in a website legal footer" in either Germany or Brazil — the classification comes from commentary on the offense and from fake-shop write-ups, not from a concrete case. So it's not a guaranteed outcome — it's the statute you get charged under if someone pushes it. And a registry cross-check is exactly what fails to catch this, which Verbraucherzentrale itself says openly. The list: invented registration numbers, someone else's registered address, someone else's VAT, a front company, zero-filled placeholders.

---

What doesn't actually happen: the Abmahnung bogeyman is six years out of date

Short version, if German litigation isn't your hobby: competitor Abmahnungen over an Impressum died on 2 December 2020. § 13 Abs. 4 Nr. 1 UWG — a competitor cannot claim reimbursement of Abmahnung costs for breaches of information duties in electronic commerce. The only documented regulator fine specifically for an Impressum is €1,050 (Medienanstalt Hamburg/Schleswig-Holstein against the YouTuber ApoRed, 14 December 2017) — 2% of the €50,000 ceiling in § 33 DDG, and only after ignored written warnings. And the share of German sellers getting an Abmahnung at all halved in 2025. The person who actually checks you is a suspicious visitor or a complainant, not a lawyer.

The detail, for anyone who wants it:

• The 2020 law kicked three legs out from under competitor-filed Abmahnungen at once. § 13 Abs. 4 Nr. 1 has no employee-count threshold at all (the <250 threshold sits in Nr. 2 and covers GDPR only; the <100 threshold sits in § 13a Abs. 2 and covers contractual penalties only — all three get confused constantly). § 13a Abs. 2 — on a first Abmahnung you can't extract a Vertragsstrafe either, if the infringer has fewer than 100 employees. § 14 Abs. 2 killed forum shopping: the sender can't file in whichever court he likes any more. On top of that, § 13 Abs. 2 Nr. 5 obliges the sender to state in the letter itself that it isn't entitled to claim costs, and § 13 Abs. 5 gives the recipient a counterclaim. The BGH confirmed the mechanics in its judgment of 10 April 2025 (I ZR 80/24). A telling sign: IDO-Verband, the biggest mass sender of Abmahnungen in German e-commerce, never made it onto the register of qualified associations — OVG NRW refused definitively on 6 May 2026 (4 A 3451/25).
• The opposite extreme is wrong too. Only cost reimbursement was abolished, and only for competitors (§ 8 Abs. 3 Nr. 1). Associations, consumer organizations and chambers (Nr. 2–4) keep the right. Wettbewerbszentrale for 2024: around 3,100 cases, 1,362 formal objections, around 200 court proceedings; 54% were misleading practices, lack of transparency and breaches of information duties lumped into a single block — there's no separate "Impressum" line in the public summary.
• On frequency, the trend has reversed. The Händlerbund Abmahnstudie 2025 (survey of 164 sellers, July 2025) showed the share receiving an Abmahnung rising from 12% (2023) to 18% (2024). But the Jahresstudie 2026 (335 sellers, February–March 2026) shows that in 2025 only 9% received one — half as many, on twice the sample. Printing a "risk is rising" narrative today is misleading. Same caveat on all of these: survey self-reporting, and no separate "Impressum" line in any of the studies. The much-quoted €9,500 and €12,500 fines from Landesmedienanstalten were Werbekennzeichnung cases, not Impressum. To be straight about the limits: no Landesmedienanstalt publishes Impressum fine statistics, so "regulators are actively fining" can't be asserted in either direction.

Where the rule does have teeth: Brazil. In 2013, during the first enforcement wave under decree 7.962/2013, Procon-DF inspected 73 online stores and fined 49 — including for the absence of a contact address, the entity's CNPJ, or the responsible individual's CPF on the site (sanction under Art. 57 CDC). Same limit here as with Germany: I couldn't find comparable recent raids with figures, so "Brazil fines regularly over legal footers" has nothing to stand on — there's one documented enforcement wave and a rule that's still on the books.

One thing I'll say out loud: if you operate outside the EU and outside Brazil, the legal part of this article touches you less. Formats, address, phone and payment icons touch everyone.

---

Payment icons and tone of voice

Payment icons — only if the lander poses as a shop. An info or service archetype has none in the footer at all. The Visa / Mastercard / Amex / PayPal set in the footer is the same American default, just in pictures, and it travels not by automation but by template inertia — and a moderator checks it against a real local store's site. In Shopify the icon set isn't fixed: the theme (Dawn, for instance) renders them dynamically from shop.enabled_payment_types — from the providers the merchant actually has connected, factoring in the buyer's region and currency. A US store on Shopify Payments typically gets Visa, Mastercard, American Express and Discover plus Shop Pay, with PayPal appearing only if separately connected. A hardcoded list like visa, master, american_express, paypal isn't a platform default — it's the manual footer-section edit the guides walk you through. WooCommerce ships no badges at all: on classic checkout you add them with a plugin, on block checkout (the default for new stores since 8.3) with editor blocks.

Before the numbers, one thing about where they come from: no central bank anywhere publishes a "payment method share of e-commerce" table. Central banks count all retail payments, not the online channel. Which means any figure of the "Pix = 44% of Brazilian e-commerce" variety originates from a vendor that also sells those methods. Second trap: share by transaction count and share by value are radically different numbers.

• Germany. Bundesbank, "Zahlungsverhalten in Deutschland 2025," online by number of payments: internet payment services 50%, direct debit and credit transfer (Lastschrift/Überweisung) 30%, credit card 15%, debit card 4%. Within internet services, PayPal is ≈86%. EHI's "Online-Payment 2026," using a different method, gives the same ordering by revenue: PayPal 28.7%, purchase on invoice 26.1%, direct debit (Lastschrift) 14.4%, cards 13.7%. Cards are the fourth-biggest payment method in German e-commerce, not the first. And it isn't that Germans don't have cards: 98% hold a debit card, 50% a credit card.
• Poland. BLIK for 2025: 2.9 billion transactions, almost half of them online, average online basket 156 zł. The regulator doesn't publish BLIK's share of Polish e-commerce — only the vague line "most frequently chosen payment method." Any specific percentage is vendor-sourced.
• Netherlands. Betaalvereniging Nederland: iDEAL covers roughly three quarters of the online payments market in e-commerce (1.47 billion transactions in 2024), and it's the only method with reliable data. And the icon is changing right now: from 2026, "iDEAL | Wero" co-branding (to be completed by 31 March 2026), merchant migration from 1 October 2026, iDEAL available until 31 December 2027.
• Brazil. BCB, "Estatísticas de Pagamentos de Varejo" (release of 7 April 2026): in H2 2025 Pix was 54.7% of all retail transactions by count but 28.6% by value (TED at 34.7%); average ticket R$456.

And about the figure you've seen in fifty vendor blogs: "local payment methods lift conversion by 20–40%" has no primary source. It circulates as "research shows," with no research named.

Tone of voice. A translation can be grammatically perfect and still sound like nobody local: US marketing phrases translated word-for-word, imperatives where the language won't take them, casual du/tu where a real business would use Sie/vous. Dialect is a build parameter too: in CLDR, pt-PT and es-MX exist as standalone locales precisely because pt-BR and es-ES are the defaultContent. The differences are fixed in data: seg./ter./qua. (BR) versus segunda/terça/quarta (PT), AM/PM versus a.m./p.m., the orthographic pairs facto/fato and receção/recepção locked in by the dual-spelling mechanism of the 1990 Agreement; and in vocabulary — ônibus/autocarro, trem/comboio, parada/paragem. And es-ES versus es-MX are inverted on three basic signals at once: numbers, currency position and clock format.

Two-minute tone test with no native speaker: open the site of a real local business in the same category in the same geo and compare its tone and form of address with your copy. Not another lander — an actual business.

---

Decide what the page claims to be

Everything above is about how the page looks. What's left is the part you can neither render nor translate.

How deep the footer legal has to go is a function of what you've claimed to be. Three levels:

1. Informational or comparison resource. Minimum company data, minimum promises, nothing is sold. Important for DE: even minimal commercial activity moves a site into the "geschäftsmäßig" category and triggers § 5 Abs. 1 DDG regardless of revenue — the official Leitfaden from the media regulator LFK (2024 edition) names "Bannerwerbung oder Affiliate Links" as its very first example. And § 18 Abs. 1 MStV requires a name and address from all telemedia whatsoever, except purely personal and family ones.
2. Service or consultancy. Contact details and a form, but no sale and no payment.
3. Shop with payment. Full legal set, registration number, return terms with the correct period for the country, shipping.

The deeper the level, the more verifiable assertions you're obliged to put on the table. Which raises the awkward question people usually route around: what do you put in an Impressum if there's no legal entity? There's one honest answer: a full German shop without a legal entity doesn't get built — § 5 DDG demands exactly the fields a stranger checks for free in seconds. The correct move is to drop a level — informational instead of a shop — not to invent company data. A more specific answer would be instructions for forgery, and I'm not giving those.

---

Local audit checklist: 15 points

1. Decimal separator and thousands separator match CLDR for the geo (in PL, thousands are a non-breaking space, not a period).
2. Four-digit numbers in PL aren't grouped (1000, not 1 000).
3. Currency symbol on the correct side, separated by a non-breaking space where required.
4. Date component order isn't American; separator is correct (NL — hyphen).
5. Clock format per territory: India is 12-hour alongside a day-first date.
6. Postcode mask validated by the local rule, not by ^\d{5}$ (PL — XX-XXX, NL — 1234 AB with exclusions, UK — six patterns).
7. Postcode position relative to the city is correct; street–number order matches the country.
8. A "State" field exists only where the region is part of the postal address (BR, IN, US), and is removed in DE, PL, NL, UK.
9. Phone written in national notation, not in NANP 3-3-4 form.
10. Number taken from the official fictitious reserve where one exists; where there isn't one (PL, NL, IN, probably BR) — the number isn't made up at random.
11. Toll-free is local (0800, 1800, 080), not 1-800.
12. Footer legal assembled per country: DE — under § 5 DDG (not "§ 5 TMG"), PL — KRS and NIP, UK — registered number and office, BR — CNPJ/CPF and physical address in a prominent place.
13. No references to repealed norms (SI 2008/495) or to non-existent ones (§ 11 Abs. 3 DDG).
14. If the lander is a shop, the cooling-off / return period matches the jurisdiction: 14 days in the EU, 7 in Brazil, no federal right in the US.
15. Every line of the company data cross-checked against the public registry by you — before somebody else checks it; an inapplicable field omitted, not zero-filled. If the lander is a shop, payment icons reflect the geo's habits (for NL, the iDEAL → Wero transition), tone checked against a real local business's site.

What a machine does. Anything that's just data staying consistent with itself and with one country: address, postcode, phone, currency, number and date format, the set of legal pages, and for a shop the icon set. That's fifteen dependent fields off one parameter: forget one and you leave an American thousands separator in a German lander, and the copy won't tell you. It always breaks at volume — not because the buyer doesn't know about dd.MM.yyyy, but because on the fifth lander of the day he isn't thinking about it. And it doesn't necessarily take a lander generator to solve: the same job is done by a locale config in the template, an i18n library, or a geo-parameter table the page is assembled from.

What stays with you: deciding what the page claims to be, supplying real company data, getting tone right. That isn't a gap in the tooling — it's a different class of problem. You can render anything that's described by data; you can only produce what you actually have.

Which gives you the question worth putting to any lander generator: is geo a build parameter in it, or just an "interface language" field? Testable in a minute — generate the same page for DE and for BR and see whether the thousands separator, currency symbol position, postcode format, presence of a "State" field and the set of legal pages actually diverged.

We ran this checklist against our own — white-lands.com. What's bound to the country there rather than to the language is the set of fields that causes most of the failures: the number format — thousands and decimal separator, the grouping itself (how digits clump), currency-symbol position and spacing — the symbol and its ISO code, date format, dialling code, city with a real postcode, the local name of the company register, and the composition of the legal pages, so an Impressum appears where it's mandatory and doesn't where it isn't. The same amount across geos: 1.290 € for DE, $1,290 for US, 1 290 € for FR, R$ 1.290 for BR. And on larger amounts the grouping itself recomputes: for IN it's ₹12,34,567 in the Indian 3:2:2 system, not 1,234,567 — symbol, separator, grouping and position all move, not just the language of the label.

Honestly, that list is shaped the way it is for a reason. When we ran our own generator through the checklist in this article, two things turned up. The thousands separator was tied to the language, not the country — the exact mistake the section above is about: de-DE and de-CH would have diverged. And the Indian 3:2:2 grouping wasn't done at all — it emitted 1,234,567 instead of 12,34,567. We found both on our own output and fixed them: the separator moved onto the country, the Indian grouping added. So the advice isn't abstract: judge any tool by its output, not its description, ours included. Running this checklist against your own generator almost always turns something up; if it turned up nothing, the odds are you diffed a page against its documentation instead of against another page.

Past that point the line falls in the same place for everybody. The machine handles data consistency: the fifteen fields that break on the fifth lander of the day. The decision about what the page pretends to be, and whose obligations you're prepared to produce on demand, stays human. That's where landers actually fail — not for lack of a way to build them, but because they claimed a business that doesn't exist.

---

Bottom line

A geo white page is assembled, not translated. Three layers of leakage — and one thing none of them substitutes for.

The first layer is formats. They leak out of en-US silently, show in five seconds, and get fixed by a locale at build time, not by hand in the HTML.

The second is the footer legal. Not "we have a Privacy Policy" but specific contents per country — different registries, company details and formats; and if the lander poses as a shop, a return period on top: 14 days in the EU versus 7 in Brazil versus zero in the US.

The third and most important is verifiability. The Handelsregister has been free since 2022, VIES answers without a key, CNPJ and NIP have check digits, Companies House searches without registration. A detail that doesn't reconcile with the registry is unfair to exactly the same degree as a missing one, and someone else's genuine detail moves the question from administrative to criminal — under offenses that exist in both jurisdictions, even though there are no published convictions specifically over legal footers.

And the one looking at all this isn't a regulator. The classic German Impressum Abmahnung has been bled dry since December 2020, the only documented fine is €1,050, and the share of sellers receiving a complaint halved in 2025. The ones looking are the three from the start of this article — the suspicious visitor, the DSA complainant, the network's compliance team — and none of them find opening a registry too much trouble, because it opens for free.

There's exactly one decision between "sloppy" and "criminal": pick what the page claims to be so you can actually back it, instead of typing zeros into a field that doesn't apply to you.

---

Further reading. If you want the base layer, not just the geo one: what a white page is and where it sits in the funnel covers the basics · how FB and Google moderation catches you in 2026 is the moderation deep-dive · the white-page archetype per vertical, gambling as the example picks up where this article's "choose an archetype" ends.

---

Educational post, not legal advice. Norms, formats and registries are as recorded in primary sources; the subject is how locally accurate a page is and what a stranger can verify about it. I'm not covering how to manufacture company data you don't have — that's § 269 StGB, and the verifiability section explains why. Where I couldn't verify something I left it out or said so. Sources on request.

Sources note, edge cases that don't change what you do: the Indian PIN was introduced 15.08.1972 (date per the government publication "India 1974"; no separate confirmation on the India Post site), and since May 2025 India Post has additionally rolled out DIGIPIN — a 10-character geocode covering roughly 4×4 m, which supplements the PIN rather than replacing it. The NIP checksum was verified empirically against 254 real NIPs pulled from KRS: 254 out of 254 passed. Portuguese lexical pairs per the Ciberdúvidas da Língua Portuguesa consultation; Priberam flags paragem as [Portugal] and gives the Brazilian parada, ponto.