docs: add links to components from pattern articles

apps/www/app/content/patterns/en/errors.mdx

@@ -29,9 +29,10 @@ We should be able to show error messages with all types of fields in a form. The
   src='/img/errormessage-co-1.png'
   alt='Screenshot of a form with an error message. The user has entered "fdgdfgfdg" in a national ID number field. The error message states that a national ID number must contain 11 digits.'
   boxShadow={false}
-
 />
 
+See [`ValidationMessage`](/en/components/validation-message) for an example of implementation.
+
 ### Summary of multiple error messages
 
 A summary can apply to one or more errors. If users try to proceed without filling in everything, or they have made mistakes, we summarize these just above the Next/Submit button.
@@ -42,11 +43,9 @@ We recommend showing the summary near the Next button so that users understand t
 - users have been away from a form and are returning to it
 - the solution doesn't stop users from going to the next page even if there are errors on a page
 
-<br />
 <br />
 
 Make sure that:
-
 - the summary shows all error messages that apply to the page or step
 - users can go directly to the errors they need to fix, and the focus is moved there
 - the links in the summary match the error messages they link to
@@ -57,9 +56,10 @@ Make sure that:
   src='/img/errormessage-co-3.png'
   alt='Screenshot of a form with an error message. The user has entered "fdgdfgfdg" in a national ID number field. The error message states that a national ID number must contain 11 digits.'
   boxShadow={false}
-
 />
 
+See [`ErrorSummary`](/en/components/error-summary) for an example of implementation.
+
 ### It's best to avoid giving error messages
 
 When planning a solution, the goal should be to prevent errors from occurring. These points can help in the planning:

apps/www/app/content/patterns/en/systemnotifications.mdx

@@ -12,7 +12,7 @@ order: 40
 ## Introduction
 We use system notifications to inform users about errors in the system or important events they should be aware of. System notifications are *not* related to user actions, as validations are. You can find information about validation errors in the [article about user-triggered errors](/en/patterns/errors). 
 
-System notifications can come in various forms, for example as an `alert` or a `modal`. How we communicate system notifications depends on the answers to these questions:
+System notifications can come in various forms, for example as an [`Alert`](/en/components/docs/alert/overview) or a modal [`Dialog`](/en/components/docs/dialog/overview). How we communicate system notifications depends on the answers to these questions:
 - What type of information is it?
 - How serious is the information in the notification?
 - What is the context of the notification? Does it belong to a specific part of the service or does it cover the entire system?
@@ -57,19 +57,19 @@ It's important to use appropriate means to communicate severity. Misuse of notif
 Another important thing to remember is that system notifications must never overshadow notifications concerning people's lives and health. For example, if you need to notify that the water is not safe to drink. Such notifications should always take priority over technical system notifications, no matter how serious we think the system notification is. This way, we ensure that vital information always reaches the citizens. If you need to notify about serious incidents not related to the system, you should therefore *not* use the components intended for system notifications.
 
 ### A) Critical system errors
-When we have errors that affect all or large parts of the system, users should be notified early. If the system is down, the notification should be clear about it. We can communicate this in several ways, for example by changing the home page to have a different text poster than usual, or we can display a `modal` telling users about the critical errors.
+When we have errors that affect all or large parts of the system, users should be notified early. If the system is down, the notification should be clear about it. We can communicate this in several ways, for example by changing the home page to have a different text poster than usual, or we can display a modal [`Dialog`](/en/components/docs/dialog/overview) telling users about the critical errors.
 
 ### B) Important system message
-Not all errors are critical, but sometimes temporary errors affect how users experience the service. Let's say we need to notify about longer processing times for applications. Then we can place a global `alert` at the top of the page. If the message only applies to parts of the service, we should give the notification where the error applies. If the user must make an active choice, it may be better to use a `modal`. For example, to notify that you'll soon be logged out if you don't make an active choice to remain logged in.
+Not all errors are critical, but sometimes temporary errors affect how users experience the service. Let's say we need to notify about longer processing times for applications. Then we can place a global [`Alert`](/en/components/docs/alert/overview) at the top of the page. If the message only applies to parts of the service, we should give the notification where the error applies. If the user must make an active choice, it may be better to use a modal [`Dialog`](/en/components/docs/dialog/overview). For example, to notify that you'll soon be logged out if you don't make an active choice to remain logged in.
 
 ### C) System information
-Users may also need to receive less important system notifications. This could be information about scheduled maintenance or notification that a new version is available. Such messages can be displayed with an `alert`.
+Users may also need to receive less important system notifications. This could be information about scheduled maintenance or notification that a new version is available. Such messages can be displayed with an [`Alert`](/en/components/docs/alert/overview).
 
 
 ## Design and experience
 There are several different ways to present system notifications to users. We should choose the presentation method that makes users perceive the notification as useful. The notification must not create confusion or frustration.
 
-Let's take a closer look at error pages and the components `modal` and `alert`. When and how should we use them?
+Let's take a closer look at error pages and the components modal [`Dialog`](/en/components/docs/dialog/overview) and [`Alert`](/en/components/docs/alert/overview). When and how should we use them?
 
 ### When do we use error pages?
 A full error page is often appropriate when serious technical errors occur that prevent the user from continuing to use the service. The advantage of error pages is that they don't compete for attention with other elements on the page.
@@ -148,8 +148,8 @@ We recommend modals for system notifications that require users to do something
 
 **Alerts are not suitable when**
 - the error prevents all further use of the service (use an error page instead)
-- you want to draw the user's attention to errors in individual fields (use `ValidationMessage`)
-- the notifications are static info boxes (use `card`)
+- you want to draw the user's attention to errors in individual fields (use [`ValidationMessage`](/en/components/docs/validation-message/overview))
+- the notifications are static info boxes (use [`Card`](/en/components/docs/card/overview))
 - it's the only content on a page
 
 In the example below, we see a global `alert` that fills the entire width at the top of the page. This type of notification is recommended for problems that affect the entire service. We use a yellow `alert` (warning) when users can still find information and navigate the website, but where some parts of the page are unavailable.

apps/www/app/content/patterns/no/errors.mdx

@@ -23,14 +23,14 @@ Feilmeldinger kan være knyttet til ett enkelt felt eller til flere. Vi viser en
 
 ### Feilmeldinger på enkeltfelt
 
-Vi skal kunne vise feilmeldinger sammen med alle typer felt i et skjema. Meldingen skal stå nært feltet som feiler.
+Vi skal kunne vise feilmeldinger sammen med alle typer felt i et skjema. Meldingen skal stå nært feltet som feiler. 
 
 <Image
   src='/img/errormessage-co-1.png'
   alt='Skjermbilde av skjema med en feilmelding. Brukeren har skrevet "fdgdfgfdg" inn i et felt for fødselsnummer. Feilmeldingen sier at Fødselsnummer  skal inneholde 11 siffer.'
   boxShadow={false}
-
 />
+Se [`ValidationMessage`](/no/components/validation-message) for eksempel på implementasjon.
 
 ### Oppsummering av flere feilmeldinger
 
@@ -42,7 +42,6 @@ Vi anbefaler å vise oppsummeringen i nærheten av Neste-knappen for at brukerne
 - brukerne har vært ute av et skjema og går inn igjen
 - løsningen ikke stopper brukerne fra å gå til neste side selv om de har feil på en side
 
-<br />
 <br />
 
 Pass på at
@@ -57,9 +56,10 @@ Pass på at
   src='/img/errormessage-co-3.png'
   alt='Skjermbilde av skjema med en feilmelding. Brukeren har skrevet "fdgdfgfdg" inn i et felt for fødselsnummer. Feilmeldingen sier at Fødselsnummer  skal inneholde 11 siffer.'
   boxShadow={false}
-
 />
 
+Se [`ErrorSummary`](/no/components/error-summary) for eksempel på implementasjon.
+
 ### Det er best om vi kan unngå å gi feilmeldinger
 
 Når vi planlegger en løsning, bør målet være å hindre at det oppstår feil. Disse punktene kan hjelpe i planleggingen:
@@ -131,6 +131,7 @@ Vis feilmeldingsteksten nært feltet det gjelder. Vi anbefaler å ha med et ikon
 #### Fargevalg
 
 Vi bruker rød som varselfarge for feil, det vi si at feltet og selve feilmeldingen blir røde. Dette er et godt etablert mønster, som hjelper med å skille feltet fra andre felt.  
+
 Feltet må ha 3:1 kontrast til bakgrunnsfargen. Hvis vi også bruker rød tekst til feilmeldingen, må den minst ha kontrasten 4.5:1. [Les mer om kontraster hos Tilsynet for universell utforming av IKT.](https://www.uutilsynet.no/veiledning/kontrast/48)
 
 #### Slik plasserer vi en feilmelding

apps/www/app/content/patterns/no/systemnotifications.mdx

@@ -12,7 +12,7 @@ order: 40
 ## Innledning
 Vi bruker systemvarsler for å informere brukerne om feil i systemet, eller viktige hendelser de bør være oppmerksomme på. Systemvarsler er *ikke* knyttet til brukernes handlinger, slik valideringer er. Du finner informasjon om valideringsfeil i [artikkelen om brukerutløste feil](/no/patterns/errors). 
 
-Systemvarsler kan komme i ulike former, for eksempel som `alert` eller `modal`. Måten vi kommuniserer systemvarslene på avhenger av svaret på disse spørsmålene:
+Systemvarsler kan komme i ulike former, for eksempel som [`Alert`](/no/components/docs/alert/overview) eller modal [`Dialog`](/no/components/docs/dialog/overview). Måten vi kommuniserer systemvarslene på avhenger av svaret på disse spørsmålene:
 - Hvilken type informasjon er det? 
 - Hvor alvorlig er informasjonen i varselet? 
 - Hvilken kontekst kommer varselet i? Tilhører det en bestemt del av tjenesten eller dekker det hele systemet? 
@@ -57,19 +57,19 @@ Det er viktig å bruke riktige virkemidler for å kommunisere alvorlighetsgrad.
 En annen viktig ting å huske på, er at systemvarsler aldri må overskygge varsler som gjelder innbyggernes liv og helse. For eksempel dersom du skal varsle om at vannet ikke kan drikkes. Slike varsler skal alltid ha prioritet over tekniske systemvarsler, uansett hvor alvorlig vi tenker systemvarselet er. På denne måten passer vi på at livsviktig informasjon alltid når fram til innbyggerne. Hvis du skal varsle om alvorlige hendelser som ikke er relatert til systemet, bør du altså *ikke* bruke komponentene som er tiltenkt systemvarsler.
 
 ### A) Kritiske systemfeil
-Når vi har feil som påvirker hele eller store deler av systemet, bør brukerne få varsel om det tidlig. Hvis systemet er nede, skal varselet være tydelig på det. Vi kan si fra om dette på flere måter, for eksempel kan vi endre startsiden til å ha en annen tekstplakat enn den som er der til vanlig, eller vi kan vise en `modal` som forteller brukerne om de kritiske feilene. 
+Når vi har feil som påvirker hele eller store deler av systemet, bør brukerne få varsel om det tidlig. Hvis systemet er nede, skal varselet være tydelig på det. Vi kan si fra om dette på flere måter, for eksempel kan vi endre startsiden til å ha en annen tekstplakat enn den som er der til vanlig, eller vi kan vise en modal [`Dialog`](/no/components/docs/dialog/overview) som forteller brukerne om de kritiske feilene. 
 
 ### B) Viktig melding om systemet
-Ikke alle feil er kritiske, men noen ganger påvirker midlertidige feil hvordan brukerne opplever tjenesten. La oss si at vi må varsle om lengre behandlingstid på søknader. Da kan vi legge en global `alert` øverst på siden. Hvis meldingen bare gjelder deler av tjenesten, bør vi heller gi varselet der feilen gjelder. Hvis brukeren må ta et aktivt valg, kan det være bedre å bruke en `modal`. For eksempel for å varsle om at du snart blir logget ut, hvis du ikke tar et aktivt valg om å forbli innlogget.
+Ikke alle feil er kritiske, men noen ganger påvirker midlertidige feil hvordan brukerne opplever tjenesten. La oss si at vi må varsle om lengre behandlingstid på søknader. Da kan vi legge en global [`Alert`](/no/components/docs/alert/overview) øverst på siden. Hvis meldingen bare gjelder deler av tjenesten, bør vi heller gi varselet der feilen gjelder. Hvis brukeren må ta et aktivt valg, kan det være bedre å bruke en modal [`Dialog`](/no/components/docs/dialog/overview). For eksempel for å varsle om at du snart blir logget ut, hvis du ikke tar et aktivt valg om å forbli innlogget.
 
 ### C) Informasjon om systemet 
-Brukerne kan også trenge å få mindre viktige systemvarsler. Det kan for eksempel være informasjon om planlagt vedlikehold eller beskjed om at en ny versjon er tilgjengelig. Slike meldinger kan vi vise med en `alert`.
+Brukerne kan også trenge å få mindre viktige systemvarsler. Det kan for eksempel være informasjon om planlagt vedlikehold eller beskjed om at en ny versjon er tilgjengelig. Slike meldinger kan vi vise med en [`Alert`](/no/components/docs/alert/overview).
 
 
 ## Design og opplevelse
 Det finnes flere ulike måter å presentere systemvarsler til brukerne på. Vi bør velge den presentasjonsmåten som gjør at brukerne oppfatter varselet som nyttig. Varselet må ikke skape forvirring eller frustrasjon.  
 
-Vi skal se nærmere på feilsider og komponentene `modal` og `alert`. Når og hvordan skal vi bruke dem? 
+Vi skal se nærmere på feilsider og komponentene modal [`Dialog`](/no/components/docs/dialog/overview) og [`Alert`](/no/components/docs/alert/overview). Når og hvordan skal vi bruke dem? 
 
 ### Når bruker vi feilsider?
 En full feilside er ofte hensiktsmessig når det oppstår alvorlige tekniske feil som hindrer brukeren i å fortsette å bruke tjenesten. Fordelen med feilsider er at de ikke krangler om oppmerksomheten med andre elementer på siden. 
@@ -148,18 +148,18 @@ Vi anbefaler modal `Dialog` til systemvarsler som krever at brukerne må gjøre
 
 **Det passer ikke med `alert` når**
 - feilen hindrer all videre bruk av tjenesten (bruk feilside i stedet)
-- du skal gjøre brukeren oppmerksom på feil i enkeltfelt (bruk `ValidationMessage`)
-- varslene er statiske infobokser (bruk `card`)
+- du skal gjøre brukeren oppmerksom på feil i enkeltfelt (bruk [`ValidationMessage`](/no/components/docs/validation-message/overview))
+- varslene er statiske infobokser (bruk [`Card`](/no/components/docs/card/overview))
 - det er eneste innhold på en side
 
-I eksempelet under ser vi en global `alert` som fyller hele bredden øverst på siden. Denne typen varsel anbefales for problemer som gjelder hele tjenesten. Vi bruker gul `alert` (warning) når brukerne fortsatt kan finne informasjon og navigere på nettsidene, men der noen av delene på siden er utilgjengelige. 
+I eksempelet under ser vi en global `Alert` som fyller hele bredden øverst på siden. Denne typen varsel anbefales for problemer som gjelder hele tjenesten. Vi bruker gul `Alert` (warning) når brukerne fortsatt kan finne informasjon og navigere på nettsidene, men der noen av delene på siden er utilgjengelige. 
 
 <Image
   src='/img/alert-global.png'
   alt='Skjermbilde av global alert.'
 />
 
-Det neste eksempelet viser en lokal `alert` som er plassert i nærheten av der feilen oppsto. Vi bruker en rød `alert` (danger) i tilfeller der brukerne ikke kan fortsette arbeidet. Den står så lenge feilen finnes. 
+Det neste eksempelet viser en lokal `Alert` som er plassert i nærheten av der feilen oppsto. Vi bruker en rød `Alert` (danger) i tilfeller der brukerne ikke kan fortsette arbeidet. Den står så lenge feilen finnes. 
 
 <Image
   src='/img/alert-lokal.png'
@@ -189,7 +189,7 @@ Varsler som dukker opp etter at siden er lastet, kalles dynamiske varsler. Disse
 </script>
 ```
 
-Ved å bruke en tom `alert` som kan fylles med innhold dynamisk, sikrer vi at skjermlesere oppfatter varselet så snart det fylles med tekst.
+Ved å bruke en tom `Alert` som kan fylles med innhold dynamisk, sikrer vi at skjermlesere oppfatter varselet så snart det fylles med tekst.
 
 
 ### Nivåer for dynamiske varsler