A filtered-out directory card stayed visible. The card is targeted by an
id-based ready-state selector (`.js #directory[data-dir-state="ready"]
#dirGrid > .dev-card`, two ids), which outranked the old per-element patch
`.dev-card[hidden] { display:none }` — so `card.hidden = true` set the
attribute and every card stayed on screen while the count line correctly
read "Showing 1 of 4".
Fix: one rule, `[hidden] { display:none !important }`, early in /style.css.
A class- or id-based `display` can no longer beat the attribute, so this
cannot recur with the next class that sets `display`. The per-element
`[hidden]` patches are removed so a single mechanism governs:
- odoo-community-developers: cards + filter row + pager + modal
(load-bearing — each sets `display`); focus-sliders/noscript (redundant)
- index/de/es `.hero-notice[hidden]`, odoo-black-friday `.ads-consent[hidden]`
(redundant — those elements set no `display`)
Re-fingerprint local assets (style.css changed): /style.css?v 3332fbba93 ->
061517baef across 51 pages.
Measured in a real browser (local harness, stubbed webhook; no record created,
no probe write) — computed display + geometry, never the `hidden` property:
- filtered to one card: the other three report display:none and height 0;
the visible set (1) equals the count line ("Showing 1 of 4") — 1 == 1
- HEAD (pre-fix) reproduces the defect: 3 cards hidden=true yet display:flex,
height 599.38 each; 4 visible vs the count's 1
- pager: display:none height 0 with one page; display:flex height 66.83 with
12 cards (Page 1 of 2); page 2 hides page-1 cards (display:none)
- modals closed: display:none height 0; load state: cards 0, pager/empty
display:none, filter row visibility:hidden by design
- 375 px: same result, no horizontal overflow; avatar ask-row top identical
across a row (2053.97 / links 2086.91)
Part 1 — asset versioning: every local <script src> and <link rel=stylesheet> on the
tracked pages now carries ?v=<sha256-of-the-file> (10 hex), computed at BUILD time from
the file's bytes by work/build-asset-versions.py — never hand-typed, and idempotent
(re-running with no file change rewrites nothing). This is what makes an edited
focus-rule.js / photo-upload.js a new URL instead of a stale cache hit.
Part 2 — language facet: a language now counts for the Language filter only when its
0-5 self-assessment is >= LANG_FACET_MIN (3 = 'works in it'). The constant sits beside
the 15-point rule in the page script and its mirror in build-directory.py. Nothing
stored changes; the card's languages chart still prints every language above 0, the
search box is unchanged, and the facet stays an exact membership test against the
card's value. A '1' language no longer offers the person under that language.
Two user decisions (2026-11-03). The page is live.
1. The anonymous-contact modal is removed in full, not just its gate: its markup and
comment, the .contact-modal and .dev-anon-btn CSS, the JS (modalEls, openContactModal,
closeContactModal, initContactModal, enhanceContact), the two init-time calls and the
per-card render call. ODOO_EXPERTS_QUOTE_WEBHOOK is deleted — the only readers were the
two gates (initContactModal, enhanceContact) and the postTo inside the modal's own
submit handler; nothing else read it. The modal's lede ("We pass your request on ...")
goes with it, so no relay copy survives. Kept on purpose: the invite relay form and
ODOO_EXPERTS_INVITE_WEBHOOK, the OCA filter + badge, ODOO_EXPERTS_WEBHOOK, and the
card's direct "Email this freelancer" chip.
2. hello@odoo4projects.com is retired site-wide: 24 occurrences (mailto + visible text)
become support@odoo4projects.com, and the 12 support@ODOO4projects.com case variants
are normalised to lower case. oliver@odoo4projects.com is a freelancer's own published
contact address on their card and is left untouched.
Tests run: verify-html.py PROBLEMS 0; check-inline-js.py OK; competitor QC exit 3 with 74
pre-existing hits and 0 added; impeccable detect 1 -> 1 (identical, 0 new).
Same defect the bootcamp carried (2aa9b19), fixed site-wide in one mechanical pass.
P0 (17 pages): /style.css was deferred via media="print" onload=... -> unstyled
first paint -> a BODY layout shift. Now a normal render-blocking
<link rel="stylesheet">; the now-redundant no-JS <noscript> for style.css is
dropped. Web fonts + Font Awesome keep their legitimate deferral.
Pages: index.html, odoo-black-friday/, odoo-hosting-offers/, de/index.html,
es/index.html, odoo-hosting-2027.html (+de/+es), odoo-community-upgrade.html
(+de/+es), odoo-staging-environment/, odoo-community-ai/,
odoo-n8n-masterclass/, australia.html, workshops/, what-can-i-use-odoo-for/.
P1 (1 page): /odoo-black-friday/ footer form action mailto: -> CRM webhook
(Lighthouse is-on-https). Changed only because the page already loads a handler
for #footerContactForm (static/black-friday.js). The other 13 mailto-form pages
load no handler and are left alone on purpose (no drive-by handler copy-in).
Added the no-JS <noscript> fallback so a JS-off visitor keeps a path.
P2 (35 pages): add a single <main> landmark wrapping the primary content; top
bar and footer stay outside. Additive only, no redesign.
Guards held: bootcamp EN/DE/ES and every JS/static file untouched; Buy forms
product_id 4/17 intact; one [data-bc-seats]; ads-consent gate intact.
verify-html.py PROBLEMS 0; competitor QC 74 pre-existing, 0 added.
PageSpeed pass on /odoo-erp-automation-bootcamp/ (EN + DE + ES):
- CLS: /style.css was deferred via media="print" onload=... → unstyled first paint
shifted BODY 0.31 (live CLS 0.326). Now a normal <link rel="stylesheet">; the two
hero webp files are preloaded (fetchpriority=high) by viewport.
- a11y: footer <h4> → <h3> (heading-order), a lighter brass + underline for links
inside on-dark notes (color-contrast, link-in-text-block), .fcopy 3.2:1 → 5.17:1.
- best-practices: the footer contact forms and the waiting-list form now post to the
CRM webhook instead of action="mailto:", which Lighthouse flags as an insecure
request (is-on-https 0 → 1). No Google Ads tag on these pages (no consent gate).
- regression fix: these pages do NOT load /script.js, so after the action change the
footer form had no JS handler and a submit navigated the visitor to the webhook's raw
JSON reply. static/bootcamp-waitlist.js now carries a footer-form handler mirroring
/script.js one-for-one (same webhook, payload { email, requirements, area:'message' }
in UTM.inject, success/failure behaviour); its two strings are read from the form's
own data-ok / data-err attributes so each language keeps its own text. ENDPOINT
hoisted to module scope so both handlers share it.
- no-JS path: a <noscript> footer line with support@ODOO4projects.com as a plain
mailto link. Verified it does not re-trigger is-on-https (unlike a mailto FORM action).
Guards held: Buy forms still post product_id 17; exactly one [data-bc-seats];
waitlist still posts area:'message'; plausible snippet present; competitor QC exit 0.
The [data-bc-seats] line lived in the Price-and-booking section; the user wants it
just under the hero. Moved (not copied) on EN/DE/ES — one element per page, the same
/static/bootcamp-availability.js, every string unchanged ("x of 6 seats available" /
"x von 6 Plätzen frei" / "x de 6 plazas disponibles").
Also adds a page-scoped :disabled style for the Buy buttons so a sold-out cohort's
disabled buttons actually read as disabled (rule: zero is honest — the buy must not
look open). Buy forms untouched: still post product_id 17.
Three bootcamp pages (EN/DE/ES) get a small waiting-list block below the Buy
button, in the Price and booking section next to the live seat count.
- two required fields: email + comment; framed as "another timezone or
language?" and worded around the January cohort's own schedule
- posts to the same n8n CRM webhook as the site's other forms, with the
footer-message payload shape copied exactly: area:'message',
requirements carries the comment, no name field, wrapped in UTM.inject()
- success hides the form and shows a confirmation; a failure restores the
button and shows a retryable error (never stuck on "sending")
- Plausible event 'Bootcamp Waitlist' on success only (cookieless); no
Google Ads tag and no conversion, as on the rest of these pages
- new page-local /static/bootcamp-waitlist.js carries the verbatim UTM
helpers from script.js (this page does not load script.js)
- buying is untouched: no markup change to the three product-17 forms
Verified: exact posted body per language captured on the wire, success and
error states in a real browser, 375 px no overflow, verify-html 0, JS syntax
0, competitor QC 0 new, impeccable detect byte-identical (zero new findings).
Show the honest remaining seats for product 17 (Bootcamp Q1-2027) on all
three bootcamp pages, in the page's own language, from the availability
webhook. Progressive enhancement (static/bootcamp-availability.js): empty
and hidden by default, filled on a successful fetch; on qty 0 the cohort is
reported full, the next cohort is pointed at, and the Buy buttons are
disabled; on any timeout/error/unexpected payload the page is left exactly
as-is and the Buy buttons stay enabled. The count is never written into the
HTML as a fixed string.
All nine Buy forms on the bootcamp pages (EN/DE/ES, three each) posted
product_id 12, which the shop resolves to 'Bootcamp - Q1-2026-eng'. The
advertised cohort is Q1 2027 (starts Thu 21 Jan 2027), so a customer
buying the 2027 bootcamp received the 2026 cohort. Both are 595.00 and
neither cart was empty, so it went unnoticed; the form's info field reads
'Q1 2027, English' while the product was 2026.
product_id 12 -> 17 in every bootcamp Buy form, all three languages.
The info field is kept (it renders as the cart line description via
sale.order.line.name, so it is read downstream); it is truthful.
static/buy.js doc comment updated to match. Nothing else changed:
plausible-event-name=Buy class, target=_blank form post, prices and
layout untouched.
The DE/ES hero-sub read '... Zertifikat und Upgrades.' / '... el certificado y
las actualizaciones.' — the last unqualified upgrade instances, mirroring the EN
hero fix (8fc6478). Both pages already qualify the distinction in the body and
the comparison table; the hero now matches, naming the in-version scope with the
pages' own phrase (DE 'die Updates innerhalb Ihrer Odoo-Version' / ES 'las
actualizaciones dentro de su versión de Odoo').
In-version updates/upgrades stay included; a major-version migration (19 -> 20)
remains a separate quote. Copy-only: tag/attr/JSON-LD structure proven identical.
Qualify the version-upgrade claim in the three spots the EN page (46b943b) already
qualifies, in the DE and ES twins at exactly the same three places:
- JSON-LD Product.description
- "Why we exist" body paragraph
- comparison-table row (Version upgrades / Versions-Upgrades / Actualizaciones de versión)
In-version / server-side updates and upgrades are included; a major-version
migration (Odoo 19 -> 20) is a separate service and is quoted separately
(user rule 2026-11-02, wiki concepts/odo4-commercial-promises). Copy-only: no
price, plan, structure, tag, attribute, class or link changed.
- de|es/index.html: order widget #orderPlanTax '+ MwSt.'/'+ impuestos'
-> 'inkl. MwSt.'/'impuestos incluidos' (static span, no JS writes it)
- de|es/support.html: add the AI-agent urgent + 24h email support sentence
- de|es/odoo-erp-automation-bootcamp/index.html: add the seat terms
(transferable any time, cancellable up to two weeks before 21 Jan 2027)
- terms.html has no DE/ES page (legal pages held back) -> nothing to mirror
Mirror of 9715a3b into the two translated bootcamp pages. Each page's three
surfaces now read 595.00: the three buy buttons, the JSON-LD Offer `price`
field, and the `.bc-price` sentence. Matches the shop product, so the DE/ES
page can no longer lose the sale at the cart.
Price-only: the term (Q1 2027), the dates, the six-seat cap and the "one year
of hosted Odoo Community Edition" wording are untouched. Currency stays USD,
numeral format unchanged per page.
Verified (see translator/work/verify-price-change.py):
- HEAD vs worktree per page identical on tag sequence, attribute list,
<style> bytes, non-JSON-LD <script> bytes and JSON-LD shape -> text-only.
- 595.00 x5, 465.00 x0, no stray `465` token on either page.
- the three buy forms label-normalised byte-identical to EN.
No DE/ES workshops, black-friday or what-can-i-use-odoo-for translations
exist; llms.txt already carries 595.00.
All three bootcamp pages (EN/DE/ES), every buy form: the basket line now
carries info="Q1 2027, English" alongside product_id 12 and qty 1, the
same field shape australia.html uses for location. Value verbatim on all
three pages (the programme is delivered in English in every language).
clear=1 / action / method / target / button labels unchanged.
Verified end to end against the live shop: POST /shop/post_basket returns
303 -> /shop/checkout and /shop/cart shows product 12 at qty 1 with the
info text rendered on the order line.
Mirror the EN cap from 2940d33 in native register, cap only — the Black
Friday call-out (window, second hosted year, BF2026) is not added; it was
dropped from EN in fd3f1dc and stays out of every language.
- de|es/odoo-erp-automation-bootcamp/index.html: Class-size fact row
(Begrenzt auf 6 Teilnehmer / Limitado a 6 participantes), the .bc-price
cap line, and JSON-LD CourseInstance maximumAttendeeCapacity: 6.
- No workshops DE/ES copies exist, so no card / comparison row applies.
- why-odoo4projects.html left untracked.
Mirror the EN term change (01c5dd3) into the published German and Spanish
bootcamp pages: hero kicker, hero first-session stat, the four schedule
facts, the DST note and both JSON-LD dates. Text/date splice only — the
verifier reports the tag sequence, attribute list, <style>/<script> bytes
and JSON-LD shape identical before and after, english_leftovers: none.
Plausible's click handler walks up from the clicked element and bails out the
moment it meets a <form>, so a plausible-event-name=Buy class on a
<button type="submit"> inside a plain form never fires Buy — the tracker sends
its automatic "Form: Submission" event instead and the goal records nothing.
Measured live on /odoo-erp-automation-bootcamp/ before this change:
{"n":"Form: Submission"}.
- odoo-erp-automation-bootcamp/index.html (3 CTAs): class moved from the
<button type="submit"> to the enclosing <form>.
- australia.html (2 CTAs): same move.
- de|es/odoo-erp-automation-bootcamp/index.html (3 forms each): the buy forms
carried no Buy marking at all, so the DE and ES bootcamp sales were invisible
to the goal. Class added to the <form>.
- odoo/upsell.html: the three .plan-btn buttons drive the same JS buy path and
were unmarked. A class on a plain <button> (not a form submit) does fire, so
it was added there and browser-verified. The disabled Trial button is left
unmarked.
Class attribute only: every button label, every form action and every basket
payload is byte-identical. No CSS or JS rule references the class.
Verified in a real browser (fetch shimmed, tracker's localhost/automation gates
bypassed): EN bootcamp 3/3, australia 2/2, DE 3/3, ES 3/3, upsell 1/1 clicks
each send exactly one {"n":"Buy"} to /api/event and never "Form: Submission".
The snippet was on 10 of 40 pages, so the Trial / FAQ / Buy / Custom Quote /
search posts / Project Plan goals were inert everywhere else. It now sits
verbatim, in the same <head> position as index.html, on all 39 visitor-facing
pages. email/trial-confirmation.html is deliberately left out (email template).
FAQ: the five <details class="bc-faq"> <summary> elements on the bootcamp page
and its DE/ES twins now carry plausible-event-name=FAQ, and the 15
.faq-question buttons on de/es/support.html get the marking they were believed
to already have. No goal renamed: one FAQ goal across all languages.
No markup, copy or behaviour change, and no third-party request beyond the
snippet itself. verify-html.py PROBLEMS 0; check-links.py OK; event checker
59 PASS / 0 FAIL; impeccable detector +0/-0 findings on the changed files.
Mark the six conversion goals on the self-hosted Plausible instance so the
events match the goals to be registered in Plausible. Event names verbatim:
Trial, FAQ, Buy, Custom Quote, search posts, Project Plan.
CSS-class markings (work without JS logic, on the clickable element):
- FAQ -> index/de/es index .faq-card; odoo-hosting-2027 + odoo-community-upgrade
(de/es twins) and australia <summary>; support.html .faq-question
- Buy -> index/de/es index .btn-buy anchors; australia + bootcamp native
post_basket submit buttons (forms stay native POST)
JS call markings in script.js (loaded by index, de/index, es/index):
- Trial on the successful trial-form POST (.then branch)
- Custom Quote on the successful custom-quote POST (.then branch)
- Project Plan on the successful business-wizard submit
- search posts on the FIRST input of #blogSearch only (guard flag, one per
pageview, not on every keystroke, not on #ocaSearch)
Nothing fires on page load; the 'Start the free trial' anchors that only
scroll to #trialCard are deliberately not tagged. One goal per topic across
all languages, no language suffix. No visual, behavioural or request change.
build-i18n.py's rebase_paths() only re-pointed a root-absolute page link when it
contained ".html", so extensionless directory links stayed on the EN route even
when the language had its own copy (`/odoo-erp-automation-bootcamp/` on all four
DE and ES pages, and `/` on the DE/ES bootcamp pages). Same guard as the .html
branch: localise only when <lang>/<path>/index.html exists.
Re-applied the rebasing to the 8 already-built DE/ES pages (work/i18n/
relocalise-links.py) - a full re-transform is not safe for them because the
switcher-slot/hero rework means repo pages are not raw transform output. 18 refs
in 8 files. The DE/ES homepages were the stale case: their body links were built
before support.html/odoo-hosting-2027.html existed in that language and were
never revisited.
check-links.py now flags an EN-route page link whose language has its own copy:
0 such links on all 10 DE/ES pages after the rebuild. test-build.py 107 passed;
verify-html.py 0 problems.
Copy-only mirrors of odoo-community-upgrade.html built by translator against the
post-R1-R5 English (EN af27098a, commit 2fe0c31), rendered through work/i18n/build-i18n.py:
<html lang>, canonical, 4-way hreflang cluster (en-US/de/es/x-default), og:url,
/static/lang.js and 15 rebased refs. No EN page change.
- sitemap.xml: 33 -> 35 <loc>, both new pages at priority 0.9
- llms.txt ## Languages: DE + ES lists now name /<lang>/odoo-community-upgrade.html
- checks: check-links.py 0 broken, verify-html.py 0 problems (tag balance, JSON-LD,
sitemap XML), JSON-LD FAQPage answers verbatim in the visible FAQ 8/8 per page
Four follow-up defects found beyond the 2026-10-27 SEO audit (no copy changes):
1. legal.html canonical was https://ODOO4projects.com/legal — uppercase host AND a
path that 404s. Now https://odoo4projects.com/legal.html. The file's og:url keeps
its path /legal but its host is lowercased (path fix awaiting a decision).
2. The no-"4" domain typo in reader-visible <pre><code> body text of
blog/posts/{guide-migrate-enterprise,speed-run-deploy,my-first-post}.html:
odooprojects.com -> odoo4projects.com. Domain string only, no other wording.
3. Lowercase host in every machine-read value: the robots.txt Sitemap line, the
homepage + de/ + es/ Organization JSON-LD url / contactPoint.url / offers[].url,
legal.html og:url, and the four absolute self-URL hrefs in blog posts,
odoo/support.html and email/trial-confirmation.html. Display text untouched
(support@ODOO4projects.com stays as written).
4. One BlogPosting per blog post (15), every value taken from the page itself:
headline = its <h1>, datePublished = its visible post-meta date, url = its own
canonical, author/publisher = the Organization the site already publishes,
image = its og:image where one exists (omitted on the 10 posts that have none).
Empire ">950.00", FAQPage on support.html, the blog-chrome change and the bootcamp
date conflict are untouched — decisions pending with the user.
The translated pages now carry the same four footer items as the three English pages:
ODOO Bootcamp -> /odoo-erp-automation-bootcamp/, ODOO Hosting in 2027 (DE) / ODOO Hosting en
2027 (ES), Support/Soporte, Rechtliches/Aviso legal. Deleted: Startseite/Inicio,
Datenschutz/Privacidad, AGB/Terminos, Kontakt/Contactenos.
Rebuilt with work/i18n/build-i18n.py from the translator's six files (work/i18n/I18N-BUILD-PLAN.md
section 5), then: place-hero-slot.py for de|es/index.html, place-slot.py for the two 2027 pages,
insert-hero-i18n.py for the two bootcamp pages (the hero CSS is language-neutral chrome held
outside the translated source). Nothing else changed: git diff 31c02b1 over these six files is
the footer list and nothing else - bootcamp hero, three buy forms (product_id 12), 465.00,
selector and hreflang clusters untouched.
Checked: verify-html.py PROBLEMS: 0; node --check static/lang.js OK; verify-footer-useful-links-de-es.py
PROBLEMS: 0; test-build.py 88/88; test-lang.js 31/31; check-links.py BROKEN/MISPLACED: 0;
impeccable detector identical finding set on all six pages (0 changed lines).
The uniform .72 -> .55 scrim composited the whole hero band to luma ~37 and the
right zone to ~35, against a flat midnight of 25.4: a dark photo made darker.
The scrim is now two zones on the same photo:
.78 0%-88% (copy zone: kicker, H1, value line, the four facts, the CTA)
ramp 88%-94%
.25 94%-100% (the lit skyline, no copy over it)
.78 is the smallest flat alpha that holds every text block over its floor
(body 4.5:1, large 3.0:1) at 1920/1440/1024/390 in EN, DE and ES - measured on
the rendered page, not modelled. 88% is where the ramp has to start: the longest
translated fact line (DE, 1024px) reaches 89.3% of the hero.
Measured before -> after (full-range mean luma of the rendered band):
whole band 37.3 / 36.8 / 37.6 / 37.3 -> 33.8 / 33.6 / 34.1 / 34.0
right 88-100% 34.8 / 35.9 / 35.5 / 38.4 -> 38.7 / 40.2 / 39.4 / 43.4
plateau 94-100% -> 41.4 / 44.2 / 42.7 / 46.9
(= 1.63x-1.91x the flat-midnight 25.4, was 1.37x-1.51x)
Worst text block: 4.87:1 (was 3.13:1). No copy, buy form, JSON-LD, selector,
hreflang or price touched: de/ and es/ differ ONLY by this inserted hero block.
Rebuilt de|es/odoo-erp-automation-bootcamp/index.html from the translator's
updated files with work/i18n/build-i18n.py (same recipe as 89bb7b7: lang,
canonical, the four hreflang links, og:url, the top-bar selector kept as-is).
- 2 occurrences per file: the facts-list <dd> and the "Your instructor"
<strong> now read "Oliver - The OC Guy - Arnold, Technical Lead bei/de
ODOO4projects" (the user's alter ego, typed hyphen form).
- Both JSON-LD instructor Person nodes gain alternateName "The OC Guy"
(the translator mirrored the EN page e5e4f5b; name stays Oliver Arnold).
- Buy forms untouched: three POST forms, product_id 12, clear=1, price 465.00
in five places per page.
- git diff --stat e5e4f5b = these two files only (+10/-6).
- add de|es/odoo-erp-automation-bootcamp/index.html (build-i18n.py from the
translator's files; canonical + hreflang cluster + top-bar selector)
- EN bootcamp page gains the four hreflang alternates (was asymmetric)
- price 790 -> 465.00 across all three pages (JSON-LD offers.price, the three
buy-button labels, the bc-price sentence); the three buy forms stay
byte-identical apart from the label language
- sitemap.xml: +/de/ and /es/odoo-erp-automation-bootcamp/; llms.txt: Languages
section names the new pages
Rebuild the two German phase-2 pages from translator/out/de/ with the standard
build recipe (lang, canonical, four hreflang links, top-bar language selector):
em-dashes cut in the German copy (odoo-hosting-2027 30 -> 5 body em-dashes,
support 8 -> 6 body) so the DE pages no longer exceed the EN source. Punctuation
only, no re-translation. ES and EN pages unchanged.
impeccable detect: finding profile unchanged except the [em-dash-overuse]
advisory on de/odoo-hosting-2027.html, which is resolved.
Four new pages, built from the verified translator output with work/i18n/build-i18n.py,
plus the same hreflang cluster and top-bar language selector on the two English pages.
Same recipe as the homepage pilot (main 937dbd4 / 06beab4); nothing else touched.
- de|es/odoo-hosting-2027.html, de|es/support.html: per-language canonical, the full
hreflang cluster (en-US, de, es, x-default -> EN), /static/lang.js, and the switcher
slot placed in the page's own top bar (.cmp-topbar on the 2027 page, .blog-header on
support.html) with the per-shape CSS hook from I18N-BUILD-PLAN.md §3.
- odoo-hosting-2027.html, support.html: same cluster, same selector, so the cluster is
symmetric (asymmetric hreflang is discarded by Google). support.html's canonical and
og:url were still on the capitalised ODOO4projects.com host; the build normalises them
to the lowercase form the rest of the site and sitemap.xml use.
- Internal links: the build's rebase step now also localises a root-absolute page link
(/support.html#contact in the translator's 2027 pages) once that page exists in the
language. /de/support.html, /de/odoo-hosting-2027.html, /de/, /de/#pricing and
/de/#trialCard are local; /legal.html stays on the EN route because the legal pages
are not translated (lawyer review pending).
- sitemap.xml: +4 URLs, lastmod 2026-10-24, priority reused from the EN entry (2027 -> 0.9,
support.html -> 0.6 fallback, it has no EN entry). 17 -> 21 <loc>, no duplicates.
- llms.txt: the ## Languages section now names the mirrored pages.
Checks: verify-html.py PROBLEMS: 0; node --check static/lang.js OK; test-lang.js 31/31;
test-build.py 64/64 (was 43; +21 for the four built pages and the root-absolute rule);
check-links.py on the four new pages BROKEN/MISPLACED: 0.
The EN | DE | ES switcher existed but rendered into the footer slot, so a
visitor had to scroll to the bottom of the page to find it (measured live:
y=5582 on /, y=5498 on /odoo-erp-automation-bootcamp/). The user asked for a
selector a visitor can actually see.
- index.html, de/index.html, es/index.html: the slot is now the first child of
.hero .container, right-aligned in flow above the kicker. In flow, not a
fixed pill, so it cannot collide with the absolute .hero-notice.
- odoo-erp-automation-bootcamp/index.html: the slot is now the last child of
.bc-topbar .container, right of the nav links, behind a hairline brass
divider; .bc-topbar-links gets margin-left:auto so the brand stays left.
- One [data-lang-switcher] per page; the footer slot is removed everywhere.
- Styling follows the CI: Inter 12px / .06em / uppercase codes (the existing
.lang-switch rules), active language in --brass on these midnight surfaces,
the other two in the surrounding text colour. CSS-only, in each page's
inline <style>; lang.js is untouched, so its redirect behaviour is unchanged.
- The rules are recorded in work/i18n/I18N-BUILD-PLAN.md §3 for the phase-2
pages (de|es/odoo-hosting-2027.html, de|es/support.html).
Homepage pilot of the website i18n project. Adds the translated homepage for DE and
ES, the shared selector at /static/lang.js, and the hreflang cluster on all three
language versions (EN included, or the cluster is asymmetric and ignored).
- de/index.html, es/index.html: translator output plus the i18n build (html lang,
self-referencing canonical, hreflang cluster, lang.js tag, switcher slot in the footer).
- index.html: same cluster + lang.js tag + switcher slot; canonical and og:url
normalised to the lowercase host.
- static/lang.js: the tested selector (client-side language choice, auto-detect on the
EN homepage only, once per session; a stored choice or ?lang= always wins).
- sitemap.xml: /de/ and /es/ (priority 1.0, lastmod 2026-10-24).
- llms.txt: new '## Languages' section.
Two gaps in the build recipe were closed while building: a mirrored page cannot use
root-relative source paths (style.css, images/* would resolve to /de/style.css -> 404),
so the build now re-points assets at the site root and keeps page links on the EN route
until the language page exists; and og:url is now this page's own URL instead of the
EN one inherited from the source. Not built yet: support.html, odoo-hosting-2027.html,
the blog, the bootcamp page, the legal pages.
webmaster
translator
webmaster