import type { HowGroups } from '../components/verifier/types';

export type Lang = 'en' | 'de';
export const langs: Lang[] = ['en', 'de'];
export const defaultLang: Lang = 'en';

export function langFromUrl(url: URL): Lang {
  const [, first] = url.pathname.split('/');
  return first === 'de' ? 'de' : 'en';
}

/** Prefix a site-relative path for a language. `path` starts with "/". */
export function localePath(lang: Lang, path: string): string {
  if (lang === 'en') return path === '' ? '/' : path;
  return path === '/' ? '/de' : `/de${path}`;
}

/** The same page in the other language. */
export function switchLang(url: URL, to: Lang): string {
  const clean = url.pathname.replace(/^\/de(?=\/|$)/, '') || '/';
  return localePath(to, clean) + url.hash;
}

export function formatDate(date: Date, lang: Lang): string {
  return new Intl.DateTimeFormat(lang === 'de' ? 'de-DE' : 'en-GB', {
    day: 'numeric', month: 'long', year: 'numeric',
  }).format(date);
}

const en = {
  meta: {
    siteName: 'CipherCell',
    home: { title: 'CipherCell. Security engineering for software.', description: 'CipherCell is a security engineering company in Passau. Threat analysis, security engineering, verification and monitoring for the software behind private 5G, critical network infrastructure and cloud-native systems.' },
    team: { title: 'Team', description: 'The security researchers, engineers and architects behind CipherCell.' },
    verifier: { title: 'CipherVerifier', description: 'CipherVerifier is a self-hosted verification pipeline for software: seventeen static analysers and two SBOM generators, one vocabulary, a two-stage review of every finding, and a ranked list an engineer can act on.' },
    insights: { title: 'Insights', description: 'Notes on software security in private 5G, critical networks and the systems that run them.' },
    imprint: { title: 'Legal notice', description: 'Legal notice for the CipherCell website.' },
    privacy: { title: 'Privacy', description: 'Privacy policy for the CipherCell website.' },
  },
  nav: {
    skip: 'Skip to content',
    capabilities: 'Capabilities',
    product: 'Product',
    sectors: 'Sectors',
    insights: 'Insights',
    team: 'Team',
    contact: 'Contact',
    menu: 'Menu',
    close: 'Close',
    homeLabel: 'CipherCell, home',
  },
  hero: {
    lines: ['Security for the software', 'everything else runs on.'],
  },
  manifesto: {
    lines: ['Security is built in,', 'not bolted on.'],
    p1: 'Infrastructure is software now. Private 5G networks, industrial control systems and cloud platforms are assembled from the code and components of many vendors. Every interface between them is an attack surface, and off-the-shelf tools were not built for that.',
    p2: 'CipherCell is a security engineering company for software. We model real adversaries, build zero trust into the architecture rather than around it, and prove that the code holds. From the first threat model to the running system.',
    cta: 'About CipherCell',
  },
  method: {
    lines: ['Four stages.', 'One method.'],
    body: 'Threat analysis, engineering, verification and monitoring, applied to your software as one continuous method rather than four separate projects. It runs alongside your development, modular and integrable.',
    imageAlt: 'A security engineer seen through glass, the reflections of monitoring screens layered across her face.',
    cta: 'Explore CipherVerifier',
    diagramTitle: 'The CipherCell method',
    diagramDesc: 'A closed loop of four stages: threat analysis, engineering, verification and monitoring. Each stage carries its own instruments: threat model, attack paths and CI/CD integration; zero trust, key management and secure APIs; independent review, hardening and testing; intrusion detection, security logging and resilience checks. Monitoring feeds back into threat analysis.',
    stages: [
      { title: 'Threat analysis', items: ['Threat model', 'Attack paths', 'CI/CD integration'] },
      { title: 'Engineering', items: ['Zero trust', 'Key management', 'Secure APIs'] },
      { title: 'Verification', items: ['Independent review', 'Hardening', 'Testing'] },
      { title: 'Monitoring', items: ['Intrusion detection', 'Security logging', 'Resilience checks'] },
    ],
  },
  stages: {
    eyebrow: 'What we do.',
    items: [
      { title: 'Threat analysis', body: 'Automated, empirical analysis of real attack paths through your software. It runs inside your CI/CD pipeline and delivers continuous assurance.' },
      { title: 'Engineering', body: 'Zero-trust enforcement, key management and secure API design as modular, composable components for your codebase and deployments.' },
      { title: 'Verification', body: 'Independent review of code and security measures, hardening checklists and application-level testing across all components.' },
      { title: 'Monitoring', body: 'Intrusion detection and security logging built into the software, from the first deployment through ongoing resilience verification.' },
    ],
  },
  sectors: {
    title: 'Who we work with',
    items: [
      { title: 'Private 5G and campus networks', body: 'Software-defined networks with open interfaces and a multi-vendor supply chain. Our origin, and still the hardest case.', imageAlt: 'A private 5G antenna and radio cabinet on the parapet of a factory roof, cranes in the distance.' },
      { title: 'Critical network infrastructure', body: 'Control and network software where a breach stops production, damages equipment or endangers people.', imageAlt: 'An electrical substation seen straight from above: transformers, switchgear and a service road.' },
      { title: 'Cloud-native systems', body: 'Containers, service meshes and CI/CD pipelines that carry infrastructure workloads. Security that runs as code, alongside yours.', imageAlt: 'A cold aisle between server racks in a data centre, a technician far in the distance.' },
    ],
  },
  proof: {
    title: 'Where we come from.',
    items: [
      { name: 'University of Passau', body: 'Our method grew out of academic security research. The university remains our research partner.' },
      { name: 'xG-ALOE alliance and xG-Incubator', body: 'Partners in the alliance for open enterprise networks, from lab to deployment.' },
      { name: 'Federal Ministry of Research, Technology and Space', body: 'Our work is publicly funded.' },
    ],
  },
  quote: {
    eyebrow: 'From the essay',
    text: 'Standard-compliant is not the same as secure.',
    name: 'Dr. Felix Klement',
    role: 'Founder and CEO',
    link: 'Read the essay',
    portraitAlt: 'Portrait of Dr. Felix Klement, founder and CEO of CipherCell.',
  },
  insights: {
    title: 'Insights',
    all: 'All insights',
    intro: 'Notes on software security in private 5G, critical networks and the systems that run them.',
    readingTime: (min: number) => `${min} min read`,
    event: { category: 'Event', when: 'September 2026', text: 'Meet us at the xG‑ALOE Plugfest 2026.', link: 'Event details', href: 'https://xg-aloe.de/xg-aloe-plugfest-2026/' },
    back: 'All insights',
    by: 'By',
    inEnglish: 'This essay is available in English.',
  },
  contact: {
    title: 'Talk to us.',
    body: 'Complex software, a tight compliance deadline, or a problem no one has solved yet. We respond within 24 hours.',
    address: ['Innstr. 43', '94032 Passau, Germany'],
    phone: '+49 (0)851 / 509-3218',
    phoneHref: 'tel:+498515093218',
    email: 'office@ciphercell.de',
    form: {
      firstName: 'First name',
      lastName: 'Last name',
      email: 'Email',
      message: 'Message',
      required: 'Required.',
      honeypot: 'Leave this field empty',
      submit: 'Send message',
    },
  },
  footer: {
    mission: 'Security engineering for software where failure has consequences.',
    company: 'Company',
    capabilities: 'Capabilities',
    contact: 'Contact',
    legal: 'Legal',
    language: 'Language',
    imprint: 'Legal notice',
    privacy: 'Privacy',
    github: 'GitHub',
    email: 'Email',
    fundingAlt: 'With funding from the Federal Ministry of Research, Technology and Space.',
    copyright: (year: number) => `© ${year} CipherCell`,
    en: 'English',
    de: 'Deutsch',
  },
  verifier: {
    eyebrow: 'Product',
    title: ['CipherVerifier.', 'Every finding, verified.'],
    cta: 'Talk to us',
    burstDesc: 'Seventeen thin lines converge on one point and leave it as a single line.',
    intro: {
      lines: ['Seventeen scanners.', 'One list.'],
      p1: 'CipherVerifier is a self-hosted pipeline. It takes a repository, runs seventeen static analysers and two bill-of-materials generators over it, and merges everything they report into one vocabulary.',
      p2: 'Then it does what scanners cannot. It reads each finding in its context, decides whether it is real, and ranks what remains by security impact. The result is a list an engineer can work through, not a pile of alerts.',
    },
    imageAlt: 'A software engineer at a desk in the evening, source code reflected in the dark window beside the monitors.',
    how: {
      title: 'How CipherVerifier works.',
      groups: [
        {
          title: 'One run, five stages.',
          body: 'A scan starts from a commit, a branch or an uploaded archive. Bill-of-materials generation and dependency analysis run in one lane, static analysis, classification and ranking in the other. Each stage is its own tool with its own status, and each can be switched off per repository.',
          desc: 'A repository forks into two lanes. The upper lane runs SBOM generation and then Dependency-Track analysis. The lower lane runs SAST scanning, then Polygraph classification, then Prism ranking. Both lanes join in the report.',
          labels: { repo: 'Repository', sbom: ['SBOM', 'generation'], sbomSub: 'Syft and cdxgen', dt: ['Dependency-Track', 'analysis'], dtSub: 'Vulnerability report', sast: ['SAST', 'scanning'], sastSub: 'Seventeen analysers', poly: ['Polygraph', 'classification'], polySub: 'Two-stage verdict', prism: ['Prism', 'ranking'], prismSub: 'By security impact', report: 'Report' },
        },
        {
          title: 'Seventeen analysers, one vocabulary.',
          body: 'Rayfusion detects the languages in the tree and runs the analysers that apply, each in its own container, in parallel. A security profile narrows every tool to rules that describe a weakness rather than a style. SarifCombiner then merges the reports: one CWE vocabulary of 970 entries, overlapping findings for the same weakness merged into one, and rules without a CWE resolved once and remembered.',
          desc: 'Seventeen analysers converge on one report. From there three steps follow: one CWE vocabulary, one finding per weakness, and unmapped rules resolved.',
          tools: ['Bandit', 'Checkov', 'Cppcheck', 'Fallow', 'Fallow Security', 'Gitleaks', 'Gosec', 'Hadolint', 'KubeLinter', 'mypy', 'Pylint', 'Roslyn Analyzers', 'Safety', 'Semgrep', 'Staticcheck', 'Trivy', 'Vulture'],
          labels: { one: 'One report', oneSub: 'SARIF, validated', cwe: ['One CWE', 'vocabulary'], cweSub: '970 entries', merge: ['One finding', 'per weakness'], mergeSub: 'Overlaps merged', resolve: ['Unmapped rules', 'resolved'], resolveSub: 'Once, then cached' },
        },
        {
          title: 'Two stages of judgement.',
          body: 'Polygraph reads every finding with its code, its provenance and the file around it, and returns a verdict with a certainty and a priority. A finding it is unsure about, or a false-positive call it is not certain of, goes to a second agent that can read the repository itself, within a fixed budget of requests and tokens. Every verdict carries its reasoning. A cached verdict is reused only when the code it was based on is unchanged.',
          desc: 'A finding is assembled with its context: provenance, code snippet, file header and an optional dataflow trace. A static verdict agent returns a first verdict. Certain verdicts go straight to the result. Uncertain verdicts, and false-positive verdicts below high certainty, are escalated to an escalation agent that reads files, lists directories and searches the tree within a bounded budget. The result is true positive, false positive or uncertain, with certainty, priority and reasoning.',
          labels: { finding: 'Finding', context: 'Context', ctx: ['Provenance', 'Code snippet', 'File header', 'Dataflow trace, optional'], stage1: ['Static verdict', 'Agent'], stage2: ['Escalation', 'Agent'], tools: ['Reads files', 'Lists directories', 'Searches the tree', 'Bounded budget'], verdict: 'Verdict', outcomes: ['True positive', 'False positive', 'Uncertain'], carries: 'Certainty, priority, reasoning', certain: 'Certain', unsure: 'Uncertain, or an unsure false positive' },
        },
        {
          title: 'The dependency side.',
          body: 'Two generators, Syft and cdxgen, each produce a bill of materials. Spectograph merges them by package URL into one CycloneDX document that is more complete than either. Deptrace hands it to Dependency-Track, a hosted instance or a container started for the scan, and brings back the vulnerability report per component.',
          desc: 'Syft and cdxgen each produce an SBOM. They merge into one CycloneDX document deduplicated by package URL, which goes to Dependency-Track, hosted or ephemeral, and comes back as a vulnerability report per component that joins the scan report.',
          labels: { syft: 'Syft', cdxgen: 'cdxgen', sbom: 'One SBOM', sbomSub: ['CycloneDX 1.6', 'Merged by package URL'], dt: 'Dependency-Track', dtSub: ['Hosted instance', 'or ephemeral container'], vdr: ['Vulnerability', 'report'], vdrSub: 'Per component, with severity', report: 'Report' },
        },
        {
          title: 'Built to be operated.',
          body: 'Repositories come in from GitHub, GitLab and Gitea, as an uploaded archive, or from your CI over a webhook with a token. Settings cascade from global to project to repository, so one default serves many teams and a single repository can still differ. Scans queue, run in parallel and report each stage live. What comes out is kept: the combined report, the vulnerability report, a PDF, and every artefact in your own storage.',
          desc: 'Sources on the left, GitHub, GitLab, Gitea, archive upload and CI webhook, feed CipherVerifier in the centre. Outputs on the right: live pipeline, combined report, vulnerability report, PDF report and artefacts in your storage. Below, settings cascade from global to project to repository.',
          labels: { hub: 'CipherVerifier', sources: ['GitHub App', 'GitLab', 'Gitea', 'Archive upload', 'CI webhook'], outputs: ['Live pipeline', 'Combined report', 'Vulnerability report', 'PDF report', 'Artefacts in your storage'], scopes: ['Global', 'Project', 'Repository'], scopesTitle: 'Settings cascade' },
        },
      ] as HowGroups,
    },
    cards: [
      { title: 'Fix these first.', body: 'Prism ranks the verified findings by security impact and puts the ranked list at the top of the scan page. Findings classified as false positives can be left out entirely.' },
      { title: 'Runs where your code is.', body: 'One installer sets up the server, the database, the object store and the scanner images. The language model and the Dependency-Track instance are endpoints you choose.' },
      { title: 'Every verdict carries its reasoning.', body: 'Each classified finding gets a line in the audit log with its verdict, its certainty and the reasoning behind it. Each stage records when it started and how it ended. The PDF report and the artefacts stay for as long as the scan exists.' },
    ],
    facts: {
      title: 'In numbers.',
      items: [
        { value: '17', label: 'Static analysers, each in its own container.' },
        { value: '14', label: 'Programming languages, plus Docker, Kubernetes, Helm, Terraform and CloudFormation.' },
        { value: '2', label: 'Bill-of-materials generators, merged into one document.' },
        { value: '970', label: 'CWE entries in one vocabulary.' },
        { value: '5', label: 'Pipeline stages, each switchable per repository.' },
      ],
    },
    outro: {
      title: 'Talk to us about your repositories.',
      body: 'Bring a repository you know well, and we will show you what CipherVerifier makes of it: what it finds, what it rules out, and why.',
      cta: 'Talk to us',
    },
  },
  team: {
    title: ['Researchers,', 'engineers,', 'architects.'],
    intro: 'The people who go deep on the problems that matter, from network, software to hardware and cloud-native systems. If it\'s a genuinely hard problem, we\'re in our element.',
    photoAlt: 'The CipherCell team on a staircase in the offices in Passau.',
    roles: {
      ceo: 'Founder and CEO',
      cto: 'Founder and CTO',
      engineer: 'Software engineer',
      bizdev: 'Business development',
      studentF: 'Working student, development',
      studentM: 'Working student, development',
    },
    research: {
      title: ['Published', 'research.'],
      intro: 'Papers by our team on Open RAN, cloud-native infrastructure and hardware security. The method we sell grew out of this work.',
      sortLabel: 'Sort',
      sort: { cites: 'Most cited', newest: 'Newest', oldest: 'Oldest' },
      filterLabel: 'Category',
      all: 'All',
      showAll: (n: number) => `Show all ${n} papers`,
      showFewer: 'Show fewer',
      count: (shown: number, total: number) => `Showing ${shown} of ${total} papers`,
      categories: {
        'Open RAN & 6G': 'Open RAN & 6G',
        'Hardware security': 'Hardware security',
        'Automotive & mobility': 'Automotive & mobility',
        'IoT security & privacy': 'IoT security & privacy',
        'Wireless security': 'Wireless security',
        'Cryptography': 'Cryptography',
        'AI agents': 'AI agents',
      } as Record<string, string>,
    },
  },
  notFound: {
    title: 'Page not found',
    body: 'The address you followed leads nowhere. The pages that exist are listed in the footer.',
    link: 'Go to the start page',
  },
  legal: {
    imprintEyebrow: 'Information pursuant to § 5 TMG',
    responsible: 'Responsible',
    mailing: 'Mailing address',
    contact: 'Contact',
    asOf: 'As of 14 June 2025',
  },
};

const de: typeof en = {
  meta: {
    siteName: 'CipherCell',
    home: { title: 'CipherCell. Security Engineering für Software.', description: 'CipherCell ist ein Security-Engineering-Unternehmen in Passau. Bedrohungsanalyse, Security Engineering, Verifikation und Monitoring für die Software hinter privaten 5G-Netzen, kritischer Netzinfrastruktur und Cloud-nativen Systemen.' },
    team: { title: 'Team', description: 'Die Sicherheitsforschenden, Ingenieurinnen und Architekten hinter CipherCell.' },
    verifier: { title: 'CipherVerifier', description: 'CipherVerifier ist eine selbst gehostete Verifikations-Pipeline für Software: siebzehn statische Analysewerkzeuge und zwei SBOM-Generatoren, ein Vokabular, ein zweistufiges Urteil zu jedem Fund und eine Rangliste, die ein Engineer abarbeiten kann.' },
    insights: { title: 'Einblicke', description: 'Notizen zur Softwaresicherheit in privaten 5G-Netzen, kritischen Netzen und den Systemen, die sie betreiben.' },
    imprint: { title: 'Impressum', description: 'Impressum der CipherCell-Website.' },
    privacy: { title: 'Datenschutz', description: 'Datenschutzerklärung der CipherCell-Website.' },
  },
  nav: {
    skip: 'Zum Inhalt springen',
    capabilities: 'Leistungen',
    product: 'Produkt',
    sectors: 'Einsatzfelder',
    insights: 'Einblicke',
    team: 'Team',
    contact: 'Kontakt',
    menu: 'Menü',
    close: 'Schließen',
    homeLabel: 'CipherCell, Startseite',
  },
  hero: {
    lines: ['Sicherheit für die Software,', 'auf der alles andere läuft.'],
  },
  manifesto: {
    lines: ['Sicherheit wird eingebaut,', 'nicht angeschraubt.'],
    p1: 'Infrastruktur ist heute Software. Private 5G-Netze, industrielle Steuerungssysteme und Cloud-Plattformen werden aus Code und Komponenten vieler Hersteller zusammengesetzt. Jede Schnittstelle dazwischen ist eine Angriffsfläche, und Standardwerkzeuge sind dafür nicht gebaut.',
    p2: 'CipherCell ist ein Security-Engineering-Unternehmen für Software. Wir modellieren reale Angreifer, verankern Zero Trust in der Architektur statt daneben und weisen nach, dass der Code standhält. Vom ersten Bedrohungsmodell bis zum laufenden System.',
    cta: 'Über CipherCell',
  },
  method: {
    lines: ['Vier Stufen.', 'Eine Methode.'],
    body: 'Bedrohungsanalyse, Engineering, Verifikation und Monitoring, auf Ihre Software angewandt als eine durchgehende Methode statt vier getrennter Projekte. Sie läuft neben Ihrer Entwicklung, modular und integrierbar.',
    imageAlt: 'Eine Sicherheitsingenieurin hinter Glas, die Spiegelungen von Monitoring-Bildschirmen liegen über ihrem Gesicht.',
    cta: 'CipherVerifier ansehen',
    diagramTitle: 'Die CipherCell-Methode',
    diagramDesc: 'Ein geschlossener Kreislauf aus vier Stufen: Bedrohungsanalyse, Engineering, Verifikation und Monitoring. Jede Stufe hat ihre Instrumente: Bedrohungsmodell, Angriffspfade und CI/CD-Integration; Zero Trust, Schlüsselmanagement und sichere APIs; unabhängige Prüfung, Härtung und Tests; Angriffserkennung, Security-Logging und Resilienzprüfung. Das Monitoring fließt zurück in die Bedrohungsanalyse.',
    stages: [
      { title: 'Bedrohungsanalyse', items: ['Bedrohungsmodell', 'Angriffspfade', 'CI/CD-Integration'] },
      { title: 'Engineering', items: ['Zero Trust', 'Schlüsselmanagement', 'Sichere APIs'] },
      { title: 'Verifikation', items: ['Unabhängige Prüfung', 'Härtung', 'Tests'] },
      { title: 'Monitoring', items: ['Angriffserkennung', 'Security-Logging', 'Resilienzprüfung'] },
    ],
  },
  stages: {
    eyebrow: 'Was wir tun.',
    items: [
      { title: 'Bedrohungs\u00ADanalyse', body: 'Automatisierte, empirische Analyse realer Angriffspfade durch Ihre Software. Sie läuft in Ihrer CI/CD-Pipeline und liefert kontinuierliche Absicherung.' },
      { title: 'Engineering', body: 'Zero-Trust-Durchsetzung, Schlüsselmanagement und sicheres API-Design als modulare, kombinierbare Komponenten für Ihre Codebasis und Deployments.' },
      { title: 'Verifikation', body: 'Unabhängige Prüfung von Code und Sicherheitsmaßnahmen, Härtungs-Checklisten und anwendungsnahe Tests über alle Komponenten.' },
      { title: 'Monitoring', body: 'Angriffserkennung und Security-Logging, in die Software eingebaut, vom ersten Deployment bis zur laufenden Resilienzprüfung.' },
    ],
  },
  sectors: {
    title: 'Für wen wir arbeiten',
    items: [
      { title: 'Private 5G- und Campusnetze', body: 'Softwaredefinierte Netze mit offenen Schnittstellen und einer Lieferkette aus vielen Herstellern. Unser Ursprung, und noch immer der schwerste Fall.', imageAlt: 'Eine private 5G-Antenne mit Funkschrank auf der Attika eines Fabrikdachs, Kräne im Hintergrund.' },
      { title: 'Kritische Netzinfrastruktur', body: 'Steuerungs- und Netzsoftware, bei der ein Einbruch die Produktion stoppt, Anlagen beschädigt oder Menschen gefährdet.', imageAlt: 'Ein Umspannwerk senkrecht von oben: Transformatoren, Schaltanlagen und eine Zufahrt.' },
      { title: 'Cloud-native Systeme', body: 'Container, Service Meshes und CI/CD-Pipelines, die Infrastruktur tragen. Sicherheit als Code, neben Ihrem.', imageAlt: 'Ein Kaltgang zwischen Serverschränken in einem Rechenzentrum, ein Techniker weit hinten.' },
    ],
  },
  proof: {
    title: 'Woher wir kommen.',
    items: [
      { name: 'Universität Passau', body: 'Unsere Methode ist aus akademischer Sicherheitsforschung entstanden. Die Universität bleibt unser Forschungspartner.' },
      { name: 'xG-ALOE-Allianz und xG-Incubator', body: 'Partner in der Allianz für offene Unternehmensnetze, vom Labor bis zum Betrieb.' },
      { name: 'Bundesministerium für Forschung, Technologie und Raumfahrt', body: 'Unsere Arbeit wird öffentlich gefördert.' },
    ],
  },
  quote: {
    eyebrow: 'Aus dem Essay',
    text: 'Standardkonform ist nicht dasselbe wie sicher.',
    name: 'Dr. Felix Klement',
    role: 'Gründer und CEO',
    link: 'Essay lesen',
    portraitAlt: 'Porträt von Dr. Felix Klement, Gründer und CEO von CipherCell.',
  },
  insights: {
    title: 'Einblicke',
    all: 'Alle Einblicke',
    intro: 'Notizen zur Softwaresicherheit in privaten 5G-Netzen, kritischen Netzen und den Systemen, die sie betreiben.',
    readingTime: (min: number) => `${min} Min. Lesezeit`,
    event: { category: 'Veranstaltung', when: 'September 2026', text: 'Treffen Sie uns beim xG‑ALOE Plugfest 2026.', link: 'Zur Veranstaltung', href: 'https://xg-aloe.de/xg-aloe-plugfest-2026/' },
    back: 'Alle Einblicke',
    by: 'Von',
    inEnglish: 'Dieser Essay liegt auf Englisch vor.',
  },
  contact: {
    title: 'Sprechen Sie mit uns.',
    body: 'Komplexe Software, eine knappe Compliance-Frist oder ein Problem, das noch niemand gelöst hat. Wir antworten innerhalb von 24 Stunden.',
    address: ['Innstr. 43', '94032 Passau, Deutschland'],
    phone: '+49 (0)851 / 509-3218',
    phoneHref: 'tel:+498515093218',
    email: 'office@ciphercell.de',
    form: {
      firstName: 'Vorname',
      lastName: 'Nachname',
      email: 'E-Mail',
      message: 'Nachricht',
      required: 'Pflichtfeld.',
      honeypot: 'Dieses Feld bitte leer lassen',
      submit: 'Nachricht senden',
    },
  },
  footer: {
    mission: 'Security Engineering für Software, bei der Ausfälle Folgen haben.',
    company: 'Unternehmen',
    capabilities: 'Leistungen',
    contact: 'Kontakt',
    legal: 'Rechtliches',
    language: 'Sprache',
    imprint: 'Impressum',
    privacy: 'Datenschutz',
    github: 'GitHub',
    email: 'E-Mail',
    fundingAlt: 'Gefördert vom Bundesministerium für Forschung, Technologie und Raumfahrt.',
    copyright: (year: number) => `© ${year} CipherCell`,
    en: 'English',
    de: 'Deutsch',
  },
  verifier: {
    eyebrow: 'Produkt',
    title: ['CipherVerifier.', 'Jeder Fund, verifiziert.'],
    cta: 'Sprechen Sie mit uns',
    burstDesc: 'Siebzehn dünne Linien laufen in einem Punkt zusammen und verlassen ihn als eine Linie.',
    intro: {
      lines: ['Siebzehn Scanner.', 'Eine Liste.'],
      p1: 'CipherVerifier ist eine selbst gehostete Pipeline. Sie nimmt ein Repository, lässt siebzehn statische Analysewerkzeuge und zwei Stücklisten-Generatoren darüber laufen und führt alles, was sie melden, in einem Vokabular zusammen.',
      p2: 'Dann tut sie, was Scanner nicht können. Sie liest jeden Fund in seinem Kontext, entscheidet, ob er echt ist, und ordnet den Rest nach Sicherheitsrelevanz. Das Ergebnis ist eine Liste, die ein Engineer abarbeiten kann, kein Stapel Meldungen.',
    },
    imageAlt: 'Ein Software-Engineer am Schreibtisch am Abend, der Quellcode spiegelt sich im dunklen Fenster neben den Monitoren.',
    how: {
      title: 'So arbeitet CipherVerifier.',
      groups: [
        {
          title: 'Ein Lauf, fünf Stufen.',
          body: 'Ein Scan beginnt bei einem Commit, einem Branch oder einem hochgeladenen Archiv. Stücklisten-Erzeugung und Abhängigkeitsanalyse laufen in der einen Bahn, statische Analyse, Klassifikation und Rangfolge in der anderen. Jede Stufe ist ein eigenes Werkzeug mit eigenem Status und lässt sich pro Repository abschalten.',
          desc: 'Ein Repository teilt sich in zwei Bahnen. Die obere Bahn erzeugt die SBOM und lässt sie von Dependency-Track analysieren. Die untere Bahn führt SAST-Scans aus, dann die Polygraph-Klassifikation, dann die Prism-Rangfolge. Beide Bahnen münden im Bericht.',
          labels: { repo: 'Repository', sbom: ['SBOM-', 'Erzeugung'], sbomSub: 'Syft und cdxgen', dt: ['Dependency-Track-', 'Analyse'], dtSub: 'Schwachstellenbericht', sast: ['SAST-', 'Scan'], sastSub: 'Siebzehn Analysewerkzeuge', poly: ['Polygraph-', 'Klassifikation'], polySub: 'Urteil in zwei Stufen', prism: ['Prism-', 'Rangfolge'], prismSub: 'Nach Sicherheitsrelevanz', report: 'Bericht' },
        },
        {
          title: 'Siebzehn Werkzeuge, ein Vokabular.',
          body: 'Rayfusion erkennt die Sprachen im Baum und startet die passenden Analysewerkzeuge, jedes in einem eigenen Container, parallel. Ein Sicherheitsprofil beschränkt jedes Werkzeug auf Regeln, die eine Schwachstelle beschreiben, nicht einen Stil. SarifCombiner führt die Berichte dann zusammen: ein CWE-Vokabular mit 970 Einträgen, überlappende Funde derselben Schwachstelle zu einem verschmolzen, Regeln ohne CWE einmal aufgelöst und gemerkt.',
          desc: 'Siebzehn Analysewerkzeuge laufen in einem Bericht zusammen. Darauf folgen drei Schritte: ein CWE-Vokabular, ein Fund pro Schwachstelle und aufgelöste Regeln ohne Zuordnung.',
          tools: ['Bandit', 'Checkov', 'Cppcheck', 'Fallow', 'Fallow Security', 'Gitleaks', 'Gosec', 'Hadolint', 'KubeLinter', 'mypy', 'Pylint', 'Roslyn Analyzers', 'Safety', 'Semgrep', 'Staticcheck', 'Trivy', 'Vulture'],
          labels: { one: 'Ein Bericht', oneSub: 'SARIF, validiert', cwe: ['Ein CWE-', 'Vokabular'], cweSub: '970 Einträge', merge: ['Ein Fund pro', 'Schwachstelle'], mergeSub: 'Überlappungen verschmolzen', resolve: ['Regeln ohne CWE', 'aufgelöst'], resolveSub: 'Einmal, dann gemerkt' },
        },
        {
          title: 'Urteil in zwei Stufen.',
          body: 'Polygraph liest jeden Fund mit seinem Code, seiner Herkunft und der Datei darum herum und gibt ein Urteil mit Sicherheit und Priorität zurück. Ein Fund, bei dem es unsicher ist, oder ein Fehlalarm-Urteil, dessen es sich nicht sicher ist, geht an einen zweiten Agenten, der das Repository selbst lesen kann, innerhalb eines festen Budgets an Anfragen und Tokens. Jedes Urteil trägt seine Begründung. Ein gemerktes Urteil wird nur wiederverwendet, wenn der Code, auf dem es beruht, unverändert ist.',
          desc: 'Ein Fund wird mit seinem Kontext zusammengestellt: Herkunft, Code-Ausschnitt, Dateikopf und optional eine Datenfluss-Spur. Ein Agent für statische Urteile liefert ein erstes Urteil. Sichere Urteile gehen direkt ins Ergebnis. Unsichere Urteile und Fehlalarm-Urteile unterhalb hoher Sicherheit werden an einen Eskalations-Agenten weitergegeben, der Dateien liest, Verzeichnisse auflistet und den Baum durchsucht, innerhalb eines begrenzten Budgets. Das Ergebnis ist echt, Fehlalarm oder unsicher, mit Sicherheit, Priorität und Begründung.',
          labels: { finding: 'Fund', context: 'Kontext', ctx: ['Herkunft', 'Code-Ausschnitt', 'Dateikopf', 'Datenfluss-Spur, optional'], stage1: ['Agent für', 'statische Urteile'], stage2: ['Eskalations-', 'Agent'], tools: ['Liest Dateien', 'Listet Verzeichnisse', 'Durchsucht den Baum', 'Begrenztes Budget'], verdict: 'Urteil', outcomes: ['Echt', 'Fehlalarm', 'Unsicher'], carries: 'Sicherheit, Priorität, Begründung', certain: 'Sicher', unsure: 'Unsicher oder unsicherer Fehlalarm' },
        },
        {
          title: 'Die Seite der Abhängigkeiten.',
          body: 'Zwei Generatoren, Syft und cdxgen, erzeugen je eine Stückliste. Spectograph führt sie anhand der Package-URL zu einem CycloneDX-Dokument zusammen, das vollständiger ist als jedes einzelne. Deptrace übergibt es an Dependency-Track, eine gehostete Instanz oder einen für den Scan gestarteten Container, und holt den Schwachstellenbericht je Komponente zurück.',
          desc: 'Syft und cdxgen erzeugen je eine SBOM. Sie verschmelzen zu einem CycloneDX-Dokument, dedupliziert nach Package-URL, das an Dependency-Track geht, gehostet oder kurzlebig, und als Schwachstellenbericht je Komponente in den Scan-Bericht zurückkehrt.',
          labels: { syft: 'Syft', cdxgen: 'cdxgen', sbom: 'Eine SBOM', sbomSub: ['CycloneDX 1.6', 'Zusammengeführt nach Package-URL'], dt: 'Dependency-Track', dtSub: ['Gehostete Instanz', 'oder kurzlebiger Container'], vdr: ['Schwachstellen-', 'bericht'], vdrSub: 'Je Komponente, mit Schweregrad', report: 'Bericht' },
        },
        {
          title: 'Gebaut, um betrieben zu werden.',
          body: 'Repositories kommen von GitHub, GitLab und Gitea, als hochgeladenes Archiv oder aus Ihrer CI über einen Webhook mit Token. Einstellungen vererben sich von global über Projekt zu Repository, sodass ein Standard vielen Teams dient und ein einzelnes Repository trotzdem abweichen kann. Scans warten in der Reihe, laufen parallel und melden jede Stufe live. Was herauskommt, bleibt: der zusammengeführte Bericht, der Schwachstellenbericht, ein PDF und jedes Artefakt in Ihrem eigenen Speicher.',
          desc: 'Quellen links, GitHub, GitLab, Gitea, Archiv-Upload und CI-Webhook, speisen CipherVerifier in der Mitte. Ausgaben rechts: Live-Pipeline, zusammengeführter Bericht, Schwachstellenbericht, PDF-Bericht und Artefakte in Ihrem Speicher. Darunter vererben sich Einstellungen von global über Projekt zu Repository.',
          labels: { hub: 'CipherVerifier', sources: ['GitHub App', 'GitLab', 'Gitea', 'Archiv-Upload', 'CI-Webhook'], outputs: ['Live-Pipeline', 'Zusammengeführter Bericht', 'Schwachstellenbericht', 'PDF-Bericht', 'Artefakte in Ihrem Speicher'], scopes: ['Global', 'Projekt', 'Repository'], scopesTitle: 'Einstellungen vererben sich' },
        },
      ] as HowGroups,
    },
    cards: [
      { title: 'Das zuerst beheben.', body: 'Prism ordnet die verifizierten Funde nach Sicherheitsrelevanz und stellt die Rangliste an den Anfang der Scan-Seite. Als Fehlalarm eingestufte Funde können ganz entfallen.' },
      { title: 'Läuft dort, wo Ihr Code ist.', body: 'Ein Installer richtet Server, Datenbank, Objektspeicher und die Scanner-Images ein. Sprachmodell und Dependency-Track-Instanz sind Endpunkte, die Sie wählen.' },
      { title: 'Jedes Urteil trägt seine Begründung.', body: 'Jeder klassifizierte Fund bekommt eine Zeile im Audit-Log mit Urteil, Sicherheit und Begründung. Jede Stufe hält fest, wann sie begann und wie sie endete. PDF-Bericht und Artefakte bleiben, solange der Scan existiert.' },
    ],
    facts: {
      title: 'In Zahlen.',
      items: [
        { value: '17', label: 'Statische Analysewerkzeuge, jedes im eigenen Container.' },
        { value: '14', label: 'Programmiersprachen, dazu Docker, Kubernetes, Helm, Terraform und CloudFormation.' },
        { value: '2', label: 'Stücklisten-Generatoren, zu einem Dokument zusammengeführt.' },
        { value: '970', label: 'CWE-Einträge in einem Vokabular.' },
        { value: '5', label: 'Pipeline-Stufen, jede pro Repository abschaltbar.' },
      ],
    },
    outro: {
      title: 'Sprechen Sie mit uns über Ihre Repositories.',
      body: 'Bringen Sie ein Repository mit, das Sie gut kennen, und wir zeigen Ihnen, was CipherVerifier daraus macht: was es findet, was es ausschließt, und warum.',
      cta: 'Sprechen Sie mit uns',
    },
  },
  team: {
    title: ['Forschende,', 'Ingenieure,', 'Architekten.'],
    intro: 'Die Menschen, die sich in die Probleme vertiefen, auf die es ankommt: von Netzwerken über Software bis hin zu Hardware und Cloud-nativen Systemen. Wenn es sich um ein wirklich schwieriges Problem handelt, sind wir in unserem Element.',
    photoAlt: 'Das CipherCell-Team auf einer Treppe in den Büros in Passau.',
    roles: {
      ceo: 'Gründer und CEO',
      cto: 'Gründer und CTO',
      engineer: 'Software Engineer',
      bizdev: 'Business Development',
      studentF: 'Werkstudentin, Entwicklung',
      studentM: 'Werkstudent, Entwicklung',
    },
    research: {
      title: ['Veröffentlichte', 'Forschung.'],
      intro: 'Arbeiten unseres Teams zu Open RAN, cloud-nativer Infrastruktur und Hardware-Sicherheit. Die Methode, die wir anbieten, ist aus dieser Arbeit entstanden.',
      sortLabel: 'Sortieren',
      sort: { cites: 'Meistzitiert', newest: 'Neueste', oldest: 'Älteste' },
      filterLabel: 'Kategorie',
      all: 'Alle',
      showAll: (n: number) => `Alle ${n} Arbeiten zeigen`,
      showFewer: 'Weniger zeigen',
      count: (shown: number, total: number) => `${shown} von ${total} Arbeiten`,
      categories: {
        'Open RAN & 6G': 'Open RAN & 6G',
        'Hardware security': 'Hardware-Sicherheit',
        'Automotive & mobility': 'Automotive & Mobilität',
        'IoT security & privacy': 'IoT-Sicherheit & Datenschutz',
        'Wireless security': 'Funksicherheit',
        'Cryptography': 'Kryptografie',
        'AI agents': 'KI-Agenten',
      } as Record<string, string>,
    },
  },
  notFound: {
    title: 'Seite nicht gefunden',
    body: 'Die Adresse, der Sie gefolgt sind, führt ins Leere. Die vorhandenen Seiten stehen in der Fußzeile.',
    link: 'Zur Startseite',
  },
  legal: {
    imprintEyebrow: 'Angaben gemäß § 5 TMG',
    responsible: 'Verantwortlich',
    mailing: 'Postanschrift',
    contact: 'Kontakt',
    asOf: 'Stand: 14. Juni 2025',
  },
};

export const ui: Record<Lang, typeof en> = { en, de };
export function t(lang: Lang) { return ui[lang]; }