From ef808b3d40929ddebc69a86d75b693f4bb200ec9 Mon Sep 17 00:00:00 2001 From: ludekjanda <55971668+ludekjanda@users.noreply.github.com> Date: Sun, 19 Nov 2023 18:35:00 +0100 Subject: [PATCH] Add DA translations (#1599) The latest Danish translation Co-authored-by: Ludek Janda --- content/da/certificates.md | 2 +- content/da/contact.md | 8 +- content/da/docs/account-id.md | 4 +- content/da/docs/caa.md | 79 ++++++++++++++++--- content/da/docs/cert-compat.md | 18 ++++- content/da/docs/ct-logs.html | 12 +-- ...st-root-ca-x3-expiration-september-2021.md | 3 +- content/da/stats-dashboard.html | 2 +- content/da/thankyou.html | 21 +++++ i18n/da.toml | 16 ++-- 10 files changed, 129 insertions(+), 36 deletions(-) create mode 100644 content/da/thankyou.html diff --git a/content/da/certificates.md b/content/da/certificates.md index cb1f432963..207c834bda 100644 --- a/content/da/certificates.md +++ b/content/da/certificates.md @@ -94,7 +94,7 @@ Dette certifikat bruges til at signere OCSP-svar for Let's Encrypt sinatur inter Vores nyere intermedia certifikater har ikke OCSP-URL'er (deres tilbagekaldelsesoplysninger er anvendes i stedet via CRL), så vi har ikke udstedt et OCSP-signeringscertifikat fra ISRG Root X2. -# Certificate Transparency +# Certifikatets Gennemsigtighed Vi er dedikeret til gennemsigtighed i vores driftsanliggender og i de certifikater, vi udsteder. Vi sender alle certifikater til [Certifikat Gennemsigtighed Logen](https://www.certificate-transparency.org/) når vi udsteder dem. Du kan se alle udstedte Let's Encrypt certifikater via disse links: diff --git a/content/da/contact.md b/content/da/contact.md index 2db46daec0..3e6be4d4a6 100644 --- a/content/da/contact.md +++ b/content/da/contact.md @@ -1,9 +1,9 @@ --- title: Kontakt slug: contact -description: How to contact us +description: Sådan kontakter du os top_graphic: 1 -lastmod: 2023-08-23 +lastmod: 2023-09-26 menu: main: weight: 90 @@ -20,7 +20,9 @@ E-mail: [press@letsencrypt.org](mailto:press@letsencrypt.org) E-mail: [press@letsencrypt.org](mailto:sponsor@letsencrypt.org) -## Abonner på vores nyhedsbrev +## Abonner på vores nyhedsbrev + + ## Privatlivspolitik diff --git a/content/da/docs/account-id.md b/content/da/docs/account-id.md index 6327ea665a..3644c0b319 100644 --- a/content/da/docs/account-id.md +++ b/content/da/docs/account-id.md @@ -3,7 +3,7 @@ title: Find Konto IDer slug: account-id top_graphic: 1 date: 2016-08-10 -lastmod: 2019-07-30 +lastmod: 2021-12-27 show_lastmod: 1 --- @@ -12,6 +12,6 @@ Når du rapporterer problemer kan det være nyttigt at angive dit Let's Encrypt Dit konto-id er en URL på formularen `https://acme-v02.api.letsencrypt.org/acme/acct/12345678`. -Hvis du bruger Certbot, kan du finde dit konto-id ved at se på feltet "uri" i `/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json`. +Hvis du bruger [Certbot](https://certbot.eff.org/), og du kører version 1.23.0 eller nyere kan du finde dit konto-id ved at køre underkommandoen `-certbot show_account`. Hvis din Certbot er ældre end 1.23.0, så kan du finde konto ID ved at se på "uri" feltet i `/etc/letsencrypt/accounts/acme-v02. pi.letsencrypt.org/directory/*/regr.json`. Hvis du bruger en anden ACME-klient, vil vejledningen være klientafhængig. Tjek dine logs for webadresser på formularen beskrevet ovenfor. Hvis din ACME-klient ikke registrerer konto-ID, du kan hente det ved at indsende en ny registrering anmodning med samme nøgle. Se [ACME-spec for flere detaljer](https://tools.ietf.org/html/rfc8555#section-7.3). Du kan også finde den numeriske form for dit ID i Boulder-Requester-header i svaret på hver POST din ACME-klient laver. diff --git a/content/da/docs/caa.md b/content/da/docs/caa.md index b69e4f4b05..05730d20db 100644 --- a/content/da/docs/caa.md +++ b/content/da/docs/caa.md @@ -3,26 +3,85 @@ title: Certifikat Autoritetsgodkendelse (CAA) slug: caa top_graphic: 1 date: 2017-07-27 -lastmod: 2017-07-27 +lastmod: 2023-08-16 show_lastmod: 1 --- -CAA er en type DNS-post, der giver ejere af webstedet mulighed for at angive, hvilket certifikat myndigheder (CAs) har lov til at udstede certifikater, der indeholder deres domænenavne. Det blev standardiseret i 2013 af [RFC 6844](https://tools.ietf.org/html/rfc6844) for at tillade en CA at "reducere risikoen for utilsigtet certifikat udstedelses-problem". Som standard er alle offentlige CA tilladt at udstede certifikater for ethvert domænenavn i den offentlige DNS forudsat at de validerer kontrollen med dette domænenavn. Det betyder, at, hvis der er en fejl i en af de mange offentlige CA'ers valideringsprocesser, er hvert domænenavn potentielt påvirket. CAA giver mulighed for, at indehavere af domæner kan reducere denne risiko. +CAA er en type DNS-post, der giver ejere af webstedet mulighed for at angive, hvilket certifikat myndigheder (CAs) har lov til at udstede certifikater, der indeholder deres domænenavne. Den blev først standardiseret i 2013, og den version, vi bruger i dag, blev standardiseret i 2019 af [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) og [RFC 8657](https://datatracker.ietf.org/doc/html/rfc8657). Som standard må alle offentlige CA udstede certifikater for ethvert domænenavn i den offentlige DNS forudsat at de validerer kontrollen med det pågældende domænenavn. That means that if there's a bug in any one of the many public CAs' validation processes, every domain name is potentially affected. CAA giver mulighed for, at indehavere af domæner kan reducere denne risiko. # Brug Af CAA Hvis du ikke bekymrer dig om CAA, behøver du generelt ikke at gøre noget (men se CAA fejl nedenfor). Hvis du ønsker at bruge CAA til at begrænse, hvilke certifikat- myndigheder der må udstede certifikater for dit domæne, du bliver nødt til at bruge en DNS-udbyder, der understøtter opsætning af CAA-poster. Tjek [SSLMate's CAA side](https://sslmate.com/caa/support) for en liste over sådanne udbydere. Hvis din udbyder er listet, du kan bruge [SSLMate's CAA Record Generator](https://sslmate.com/caa/) til at generere et sæt CAA poster med de CAA elementer, som du ønsker at tillade. -Let's Encrypt domænenavnet for CAA er `letsencrypt.org`. Dette er officielt dokumenteret [i vores erklæring om certificeringspraksis (CPS), afsnit 4.2.1](/repository). - ## Hvor skal posten placeres -Du kan indsætte CAA poster på dit hoveddomæne eller på enhvert niveau af underdomæner. For eksempel, hvis du havde `www.community.example.com`, kan du indstille CAA records for det fulde navn, eller for `community.example.com` eller for `example.com`. CAer vil kontrollere hver version, fra venstre mod højre, og stoppe, så snart de ser en CAA post. Så for eksempel, en CAA post på `community.example.com` ville have forrang frem for en på `example.com`. De fleste personer, der tilføjer CAA-poster, vil føje dem til deres registrerede domæne (`eksempel. om`), så de gælder for alle underdomæner. Bemærk også, at CAA optegnelser for subdomæner har forrang frem for deres overordnede domæner, uanset om de er mere eftergivende eller mere restriktive. Så et subdomæne kan løsne en begrænsning sat på plads af et overordnet domæne. +Generelt ønsker du at indstille CAA poster på dit registrerede domæne (såsom "example.org" eller "mysite.co.uk"). På denne måde gælder de for både dette domæne og eventuelle subdomæner, du opretter under det, såsom "community.example.org". + +Bemærk at CA vil alt tid følge den CAA post, som er *mest specifikt* i forhold til det domæne navn, som certifikatet ønskes udstedt for. Så hvis du anmoder om et cert til "www.community.example.org", vil CA'en tjekke "www.community.example.org", så "community.example.org", så "example.org", stopper ved den første CAA post, den finder. + +Det betyder, at du kan overskrive CAA for subdomæner. For eksempel, formode, at du hoster "example.org" selv, men har "api.example.org" på en cloud udbyder. Du kan bruge en CAA post på "example.org" at sige, at kun Let's Encrypt kan udstede for dette domæne og alle dets underdomæner, men også bruge en CAA post på "api.example.org" at tilsidesætte det og tillade cloud udbyder at udstede certifikater for det ene subdomæne. + +Bemærk også, at CAA kontrol følger CNAME omdirigerer, ligesom alle andre DNS anmodninger. Hvis "community.example.org" er en CNAME til "example.forum.com", vil CA respektere enhver CAA poster, der er indstillet på "example.forum.com". Det er ikke tilladt for et domænenavn med en CNAME-post at have andre poster, så der ikke kan være konflikter mellem CAA-optegnelser på det oprindelige navn og CAA-optegnelser om målet for omdirigeringen. + +## Hvad skal man sætte i posten + +Alle CAA poster følger det samme grundlæggende format: + +``` +CAA +``` + +De **flag** er blot et heltal, og bør næsten altid bare være heltal `0`, hvilket indikerer at ingen flag er blevet sat. Hvis du ønsker det, kan du indstille flagene til heltals `128`, hvilket indikerer at den "kritiske bit" er indstillet, og at CA'er bør straks standse og ikke udstede et certifikat, hvis de ikke genkender indholdet af tag-feltet. + +**tag** er en streng, der angiver, hvilken type CAA post dette er: enten `issue` eller `issuewild` i de fleste tilfælde. Mere om disse nedenfor. + +Endeligt er **værdien ** en streng, der indeholder højst en CA-identifikator (såsom "letsencrypt.org") og nogle valgfrie semikolonseparerede parametre, som også er beskrevet nedenfor. + +### Egenskaberne `issue` og `issuewild` + +Poster med `issue` tag kontrollerer blot, om en CA kan udstede certifikater for dette domæne og dets underdomæner. Generelt er dette den eneste post, du har brug for, da det styrer både normal (fx "example.org") og jokertegn (f.eks. "*.example.org") udstedelse i mangel af andre poster. Du styrer hvilken CA kan udstede for dette domæne ved at sætte det pågældende CA's identifikationsdomænenavn i værdidelen af CAA-posten. + +Poster med `issuewild` tagget kontrollerer, om en CA kan udstede *wildcard* certifikater (f.eks. "*.example.org"). Du behøver kun at bruge `issuewild` -poster, hvis du ønsker forskellige tilladelser til jokertegn og ikke-jokertegn. + +Bemærk, at du kan have flere posteringer med den samme ejendomstype, og de er *additive*: hvis en af disse posteringer tillader CA at udstede, så er det tilladt. + +Let's Encrypt domænenavnet for CAA er `letsencrypt.org`. Dette er officielt dokumenteret i [Afsnit 4.2.1 i vores CP/CPS](https://cps.letsencrypt.org/#4.2.1-performing-identification-and-authentication-functions). + +### Parameteren `validationmethods` + +Denne parameter kan placeres efter CA's identificerende domænenavn for at styre, hvilke valideringsmetoder, som CA kan bruge til at bekræfte kontrollen over domænet. Dette kan bruges til at begrænse validering til metoder, som du har tillid til yderligere. For eksempel, hvis du ønsker at begrænse CA til kun at bruge TLS-ALPN-01 metoden, kan du tilføje `;validationmethods=tls-alpn-01` til din CAA posts værdi. + +Let's Encrypt genkender følgende valideringsmetodestrenge: + +* `http-01` +* `dns-01` +* `tls-alpn-01` + +### Parameteren `accounturi` + +Denne parameter kan placeres efter CA's identificerende domænenavn for at styre, hvilke valideringsmetoder, som CA kan bruge til at bekræfte kontrollen over domænet. Dette kan bruges til at sikre, at en person, der midlertidigt kaprer dit domæne, men har ikke adgang til din ACME-kontonøgle, kan ikke udstede ondsindede certifikater. + +Let's Encrypt's konto URI'er ligne `https://acme-v02.api.letsencrypt.org/acme/acct/1234567890`, hvor numrene i slutningen er dit konto-id. + +### Eksempler + +En simpel CAA post, som gør det muligt for Let's Encrypt at udstede for "example.org" kan se sådan ud: + +``` +example.org CAA 0 issue "letsencrypt.org" +``` + +En mere kompleks CAA post sæt kan se sådan ud: + +``` +example.org CAA 0 issue "myca.org;validationmethods=dns-01" +example.org CAA 0 issuewild "myca.org" +example.org CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456" +``` -CAA validering følger CNAMEs, ligesom alle andre DNS anmodninger. Hvis `www.community.example.com` er et CNAME til `web1.example.com`, CA vil først anmode CAA poster for `www.community.example om`, så se, at der er en CNAME for dette domænenavn i stedet for CAA poster, vil anmode om CAA posteringer for `web1.example.net` i stedet. Bemærk, at hvis et domænenavn har en CNAME-post, er det ikke tilladt at have andre posteringer i henhold til DNS-standarderne. +I dette eksempel kan MyCA udstede for "example.org", men kun ved hjælp af DNS-01 valideringsmetoden. Det kan også udstede wildcard certifikater, ved hjælp af enhver valideringsmetode. Endelig kan OtherCA også udstede certifikater, men kun hvis anmodningen kommer fra kontonummer `123456`, og kun hvis OtherCA genkender og ved, hvordan man korrekt håndterer `accounturi` begrænsningen. -Den [CAA RFC](https://tools.ietf.org/html/rfc6844) specificerer en ekstra adfærd kaldet "træ-klatring", der kræver CAA til også at kontrollere de overordnede domæner for resultatet af CNAME opløsning. Denne yderligere adfærd blev senere fjernet af [et erratum](https://www.rfc-editor.org/errata/eid5065), så Let's Encrypt og andre CA'er ikke implementerer det. # CAA fejl @@ -30,9 +89,9 @@ Da lad os kryptere kontrollerer CAA poster før hvert certifikat, vi udsteder, n Hvis du modtager CAA-relaterede fejl, så prøv et par gange mere mod vores [iscenesættelsesmiljø](/docs/staging-environment) for at se, om de er midlertidige eller permanente. Hvis de er permanente, skal du indsende et supportproblem med din DNS-udbyder, eller skifte udbydere. Hvis du ikke er sikker på, hvem din DNS-udbyder er, så spørg din hosting-udbyder. -Nogle DNS-udbydere, der ikke er bekendt med CAA i første omgang besvare problem rapporter med "Vi understøtter ikke CAA poster. Din DNS-udbyder behøver ikke for specifikt at understøtte CAA-poster; det behøver kun at svare med et NOERROR-svar for ukendte forespørgselstyper (herunder CAA). Returnering af andre opkoder, herunder NOTIMP, for ukendte qtypes er en overtrædelse af [RFC 1035](https://tools.ietf.org/html/rfc1035)og skal rettes. +Nogle DNS-udbydere, der ikke er bekendt med CAA i første omgang besvare problem rapporter med "Vi understøtter ikke CAA poster." Din DNS-udbyder behøver ikke at specifikt at understøtte CAA-optegnelser; det behøver kun at svare med et NOERROR svar for ukendte forespørgselstyper (herunder CAA). Returnering af andre opkoder, herunder NOTIMP, for ukendte qtypes er en overtrædelse af [RFC 1035](https://tools.ietf.org/html/rfc1035)og skal rettes. -# SERVFAIL +## SERVFAIL En af de mest almindelige fejl, som folk støder på, er SERVFAIL. Oftest indikerer dette en fejl i DNSSEC-valideringen. Hvis du får en SERVFAIL fejl, bør dit første skridt være at bruge en DNSSEC debugger som [dnsviz.net](http://dnsviz.net/). Hvis det ikke virker, er det muligt, at dine navneservere kun genererer forkerte signaturer, når svaret er tomt. Og CAA svar er mest almindeligt tomme. For eksempel, PowerDNS [havde denne fejl i version 4.0.3 og under](https://community.letsencrypt.org/t/caa-servfail-changes/38298/2?u=jsha). @@ -40,6 +99,6 @@ Hvis du ikke har DNSSEC aktiveret og få en SERVFAIL, den anden mest sandsynlige Endelig kan SERVFAILs være forårsaget af udfald hos dine autoritative navneservere. Kontroller NS-poster for dine navneservere og sikre, at hver server er tilgængelig. -# Timeout +## Timeout Sommetider giver CAA forespørgsler timeout. Det vil sige, den autoritative navneserver aldrig svarer med et svar overhovedet, selv efter flere forsøg. Mest almindeligt dette sker, når din navneserver har en forkert konfigureret firewall foran det, at falder DNS-forespørgsler med ukendte qtyper. Opret en supportsag hos din DNS udbyder og spørg dem, hvis de har sådan en firewall konfigureret. diff --git a/content/da/docs/cert-compat.md b/content/da/docs/cert-compat.md index 7db1cb9650..a8ff6f1ae5 100644 --- a/content/da/docs/cert-compat.md +++ b/content/da/docs/cert-compat.md @@ -2,12 +2,12 @@ title: Certifikatets Kompatilitet slug: certificate-compatibility top_graphic: 1 -lastmod: 2021-10-31 +lastmod: 2023-08-02 show_lastmod: 1 --- -Den vigtigste afgørende faktor for, om en platform kan validere Let's Encrypt certifikater er, om platformen stoler på ISRG's "ISRG Root X1" certifikat. Før september 2021 kunne nogle platforme validere vores certifikater, selvom de ikke inkluderer ISRG Root X1, fordi de stolede på IdenTrust's "DST Root CA X3" certifikat. Efter September 2021 og fremadrettet vil kun de platforme, der stoler på ISRG Root X1 vil fortsætte med at validere Let's Encrypt certifikater ([med undtagelse af Android](/2020/12/21/extending-android-compatibility.html)). +Den vigtigste afgørende faktor for, om en platform kan validere Let's Encrypt certifikater er, om platformen stoler på ISRG's "ISRG Root X1" certifikat. Før september 2021 kunne nogle platforme validere vores certifikater, selvom de ikke inkluderer ISRG Root X1, fordi de stolede på IdenTrust's "DST Root CA X3" certifikat. Efter September 2021 og fremadrettet vil kun de platforme, der stoler på ISRG Root X1 vil fortsætte med at validere Let's Encrypt certifikater ([med undtagelse af Android][android-compat]). Hvis dit certifikat validerer på nogle af de "kendte kompatible" platforme, men ikke andre, kan problemet være en webserver fejlkonfiguration. Hvis du har et problem med moderne platforme, er den mest almindelige årsag ikke at levere den korrekte certifikatkæde. Test dit websted med [SSL Labs' Server Test](https://www.ssllabs.com/ssltest/). Hvis det ikke identificerer problemet, så spørg om hjælp i vores [Community Forums](https://community.letsencrypt.org/). @@ -25,7 +25,7 @@ Hvis dit certifikat validerer på nogle af de "kendte kompatible" platforme, men * [Java 7 >= 7u151](https://www.oracle.com/java/technologies/javase/7u151-relnotes.html) * [NSS >= 3,26](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.26_release_notes) -Browsere (Chrome, Safari, Edge, Opera) stoler generelt på de samme rodcertifikater som det styresystem, de kører på. Firefox er undtagelsen: det har sin egne rodcertifikater. Snart vil nye versioner af Chrome [også have deres egne rodcertifikater](https://www.chromium.org/Home/chromium-security/root-ca-policy). +Browsere (Chrome, Safari, Edge, Opera) stoler generelt på de samme rodcertifikater som det styresystem, de kører på. Firefox er undtagelsen: det har sin egne rodcertifikater. Snart vil nye versioner af Chrome [også have deres egne rodcertifikater][chrome-root-store]. # Platforme der stoler DST Root CA X3, men ikke ISRG Root X1 @@ -62,4 +62,14 @@ Disse platforme ville have fungeret frem til september 2021, men vil ikke længe # ISRG Root X2 (ny ECDSA root) - kommer snart -Vi har indsendt ISRG Root X2 til Microsoft, Apple, Google, Mozilla, og Oracle rod-certifikat-programmer med henblik på tilføjelse. ISRG Root X2 er allerede bredt betroet via et krydssignatur fra vores ISRG Root X1. For yderligere information, tjek vores [community forum indlæg](https://community.letsencrypt.org/t/isrg-root-x2-submitted-to-root-programs/149385). +Vi har indsendt ISRG Root X2 til Microsoft, Apple, Google, Mozilla, og Oracle rod-certifikat-programmer med henblik på tilføjelse. + +ISRG Root X2 er allerede bredt betroet via et krydssignatur fra vores ISRG Root X1. Derudover har flere rodprogrammer allerede tilføjet ISRG Root X2 som et trust anchor. + +For yderligere information, tjek vores [community forum indlæg](https://community.letsencrypt.org/t/isrg-root-x2-submitted-to-root-programs/149385). + +Mens vi venter på, at ISRG Root X2 bliver bredt betroet, er det muligt at opt-in at bruge ISRG Root X2 til dine ECDSA-certifikater. For mere information, se vores [community forum indlæg](https://community.letsencrypt.org/t/root-x2-alternate-chain-for-ecdsa-opt-in-accounts/202884). + +[android-compat]: /2020/12/21/extending-android-compatibility.html + +[chrome-root-store]: https://www.chromium.org/Home/chromium-security/root-ca-policy diff --git a/content/da/docs/ct-logs.html b/content/da/docs/ct-logs.html index 26853ad336..feff99993e 100644 --- a/content/da/docs/ct-logs.html +++ b/content/da/docs/ct-logs.html @@ -2,7 +2,7 @@ title: Certifikat Gennemsigtighed (CT) Logs slug: ct-logs top_graphic: 4 -lastmod: 2022-06-17 +lastmod: 2023-09-25 show_lastmod: 1 --- @@ -31,13 +31,7 @@

Finansiering

- Vi vil gerne takke følgende partnere for generøst at sponsorere Let's Encrypt CT log. Hvis din organisation gerne vil hjælpe os med at fortsætte dette arbejde, så overvej venligst sponsorering eller donering. -

- -

- Sectigo + Hvis din organisation gerne vil hjælpe os med at fortsætte dette arbejde, så overvej venligst sponsorering eller donering.

Arkitektur

@@ -56,7 +50,7 @@

Log Overvågning

CT Logs

-Oplysninger om de forskellige livscyklusser siger, at en CT log fremgang gennem kan findes her. +Oplysninger om de forskellige livscyklusser tilstande, som en CT log går gennem kan findes her.

{{< ct_logs data="production" >}} diff --git a/content/da/docs/dst-root-ca-x3-expiration-september-2021.md b/content/da/docs/dst-root-ca-x3-expiration-september-2021.md index 9d3215a56b..928eab3df1 100644 --- a/content/da/docs/dst-root-ca-x3-expiration-september-2021.md +++ b/content/da/docs/dst-root-ca-x3-expiration-september-2021.md @@ -2,7 +2,7 @@ title: DST Root CA X3 Udløb (september 2021) slug: dst-root-ca-x3-expiration-september-2021 top_graphic: 1 -lastmod: 2021-05-07 +lastmod: 2021-09-30 menu: main: weight: 30 @@ -10,6 +10,7 @@ menu: show_lastmod: 1 --- +> **Opdatering 30. september, 2021** Som planlagt er DST Root CA X3 cross-sign udløbet og vi bruger nu vores egen ISRG Root X1 for tillid på næsten alle enheder. For flere detaljer om planen, fortsæt læsning! Vi har også opdateret vores Production Chain Changes tråd på vores community forum - [vores team og fællesskab er her og klar til at hjælpe](https://community.letsencrypt.org/t/production-chain-changes/150739/4) med eventuelle spørgsmål, du måtte have om dette udløb. Den 30. september 2021 vil der være en lille ændring i, hvordan ældre browsere og enheder stoler på Let's Encrypt certifikater. Hvis du besøger en typisk hjemmeside, du vil ikke bemærke en forskel - langt de fleste af dine besøgende vil stadig acceptere dit Let's Encrypt certifikat. Hvis du leverer en API eller er nødt til at støtte IoT-enheder, kan du måske være nødt til at være lidt mere opmærksom på ændringen. diff --git a/content/da/stats-dashboard.html b/content/da/stats-dashboard.html index 0ffc3da3fd..da86feffef 100644 --- a/content/da/stats-dashboard.html +++ b/content/da/stats-dashboard.html @@ -11,7 +11,7 @@

Let's Encrypt Vækst-Tidslinje

-
+

{{< link "/stats" >}}

diff --git a/content/da/thankyou.html b/content/da/thankyou.html new file mode 100644 index 0000000000..6ae9ad9c6d --- /dev/null +++ b/content/da/thankyou.html @@ -0,0 +1,21 @@ +--- +title: Mange tak +slug: thankyou +top_graphic: 2 +date: 2022-12-02 +aliases: + - /thank-you +--- + + + +
+

Tak for dit bidrag

+

På vegne af alle på ISRG, tak for dit bidrag til at støtte vores arbejde.

+

En donationskvittering er blevet sendt til den e-mail-adresse, du har angivet. Internet Security Research Group er en 501(c)(3) nonprofit offentlig almennyttigt organisation. Vores EIN-kode er: 46-3344200.

+

Fordobbel din donation

+

Mange organisationer matcher donationer til nonprofit foretaget af medarbejdere. Tjek om din organisation har et matchende program og fordoble din donation!

+
+ {{< double_donation >}} +
+
diff --git a/i18n/da.toml b/i18n/da.toml index fe81b33171..bc7bcf225f 100644 --- a/i18n/da.toml +++ b/i18n/da.toml @@ -1,5 +1,5 @@ [home_hero_title] -other = "En nonprofit Certificat udsteder leverer TLS-certifikater til 260 millioner hjemmesider." +other = "En nonprofit Certificat udsteder leverer TLS-certifikater til 300 millioner hjemmesider." [home_hero_getting_started] other = "Kom i gang" @@ -11,7 +11,7 @@ other = "Donér" other = "Sponsor" [home_hero_annual_report] -other = "Vi blev tildelt Levchin-prisen for praktisk anvendt kryptografi! Læs mere" +other = "Læs alt om vores nonprofit arbejde i år i vores 2022 årsberetning." [home_major_sponsors] other = "Store sponsorer og finansieringskilder" @@ -40,9 +40,6 @@ Se vores privatlivspolitik.
Se vores varemærkepolitik. """ -[linux_foundation_trademark] -other = "Linux Foundation er et registreret varemærke tilhørende Linux-fonden. Linux er et registreret varemærke tilhørende Linus Torvalds." - [header_skip_nav] other = "Spring navigation links over" @@ -55,6 +52,9 @@ other = "Se al dokumentation" [blog_feed] other = "Let's Encrypt Blog Feed" +[diamond] +other = "Diamant" + [platinum] other = "Platinum" @@ -189,3 +189,9 @@ other = "100-999 ansatte" [1000_employees] other = "1000 + ansatte" + +[subscribe_to_newsletter_headline] +other = "Abonner på vores nyhedsbrev" + +[site_banner_text] +other = "ISRG fejrer 10 år for at hjælpe med at opbygge et lysere internet →"