docs:fix broken links for developer portal

docs/docs/components/alertbar.md

@@ -154,7 +154,7 @@ Read more about the `useAlert()` hook at the [App Runtime documentation](https:/
 
 -   Alert bar labels should be clear, concise, and easy to understand. Remember, `info` and `success` alert bars dismiss automatically.
 -   Don't use unclear labels like _Success_, _Failed_, or vague descriptions like _There was a problem_. Be clear and precise.
--   Check the [A-Z glossary](../patterns/glossary.md) and [communication guidelines](../principles/content-communication.md) for more tips for writing useful labels.
+-   Check the [A-Z glossary](/ui/patterns/glossary) and [communication guidelines](/ui/principles/content-communication) for more tips for writing useful labels.
 
 #### Display
 

docs/docs/components/inputfield.md

@@ -137,7 +137,7 @@ Inputs width should reflect the expected content.
 ### Validation
 
 -   Validating the type of data entered isn't part of the components themselves.
--   Read more about [form handling in DHIS2](../utilities/forms/react-final-form.md).
+-   Read more about [form handling in DHIS2](/ui/utilities/forms/react-final-form).
 
 ### Read-only
 
@@ -174,7 +174,7 @@ Inputs width should reflect the expected content.
 
 -   Use an error state if there's a problem with the content of the input, or if it's required but empty.
 -   Don't show an error too early, give the user a chance to finish entering data.
--   The error text should help the user fix the problem. Refer to the [error writing guidelines](../principles/content-communication.md) for examples.
+-   The error text should help the user fix the problem. Refer to the [error writing guidelines](/ui/principles/content-communication) for examples.
 
 ### State: Disabled
 

docs/docs/components/menu.md

@@ -32,7 +32,7 @@ A menu gives access to menu items, through a panel that opens from a trigger ele
 
 -   Menu item labels should be short and easy to understand.
 -   One or two words is often enough to explain the action.
--   Refer to the [writing guidelines](../patterns/writing.md) and [glossary](../patterns/glossary.md) for more information about writing useful labels.
+-   Refer to the [writing guidelines](/ui/patterns/writing) and [glossary](/ui/patterns/glossary) for more information about writing useful labels.
 
 ##### Order and grouping
 

docs/docs/components/notice-box.md

@@ -111,7 +111,7 @@ A notice box shows important information about a situation.
 
 -   Notice box titles should be a short summary to help the user scan elements the page.
 -   Notice box text should be clear and informative. Explain what the situation is and, if relevant, offer a solution.
--   Check the [writing guidelines](../patterns/writing.md) for more information.
+-   Check the [writing guidelines](/ui/patterns/writing) for more information.
 
 ## Options
 

docs/docs/components/popover.md

@@ -29,7 +29,7 @@ A popover is used to show more information when a user interacts with a trigger
 ### Format
 
 -   A popover doesn't offer any default content styling.
--   Include padding between the popover frame and the content inside. The amount of padding depends on the content and density of the interface. Use a [spacer constant](../utilities/constants.md) for a consistent visual experience.
+-   Include padding between the popover frame and the content inside. The amount of padding depends on the content and density of the interface. Use a [spacer constant](/ui/utilities/constants) for a consistent visual experience.
 
 ## API Reference
 

docs/docs/components/select.md

@@ -221,7 +221,7 @@ Selects are used to choose one or more items from a list of options.
 
 -   Use an error state if there's a problem with the chosen option, or if it's required but empty.
 -   Don't show an error too early, give the user a chance to make a choice.
--   The error text should help the user fix the problem. Refer to the [error writing guidelines](../principles/content-communication.md) for examples.
+-   The error text should help the user fix the problem. Refer to the [error writing guidelines](/ui/principles/content-communication) for examples.
 
 ### State: Disabled
 

docs/docs/components/transfer.md

@@ -150,7 +150,7 @@ The footer component is as follows:
 
 -   Different types of data will need different loading strategies.
 -   Use a [`Loader`](loading.md) to block interaction if using the transfer while loading is taking place can cause problems.
--   A common pattern is loading more options as a user scrolls. See the [Transfer: Infinite Loading recipe](../recipes/transfer-infinite-loading-all-options-selected.md) for more information.
+-   A common pattern is loading more options as a user scrolls. See the [Transfer: Infinite Loading recipe](/ui/recipes/transfer-infinite-loading-all-options-selected) for more information.
 
 ## API Reference
 

docs/docs/principles/forms.md

@@ -46,17 +46,17 @@ Forms are made up of different types of inputs. There are various inputs availab
 
 | Input                                    | Usage                                                                                                              | Notes                                                                                                                                                             |
 | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [Text](../components/inputfield.md)      | Enter free text input                                                                                              | There are multiple types of text input that accept different formats. See the input documentation for details.                                                    |
-| [Single select](../components/select.md) | Select a single option from a list of many                                                                         | A select should be used when there are more than 5-7 options instead of radio buttons.                                                                            |
-| [Multi select](../components/select.md)  | Select multiple options from a list of many                                                                        | A select should be used when there are more than 5-7 options instead of checkboxes                                                                                |
-| [Checkbox](../components/checkbox.md)    | Single: toggle an option between yes/no, true/false, on/off. Multiple: select multiple options from a list of few. | Single checkboxes must never be a required input as there is no neutral state. Do not use a list of checkboxes for many (7+) options, use a multi select instead. |
-| [Radio](../components/radio.md)          | Select a single option from a list of few                                                                          | Do not use a list of radio buttons for many (7+) options, use a single select instead.                                                                            |
-| [File input](../components/fileinput.md) | Select a file                                                                                                      | Accepted file type and size should be made clear to the user before uploading                                                                                     |
-| [Transfer](../components/transfer.md)    | Select and order multiple options from a list of many in different categories.                                     | Use for complex selections that require specific ordering and filtering of categories.                                                                            |
+| [Text](/docs/ui/components/inputfield)      | Enter free text input                                                                                              | There are multiple types of text input that accept different formats. See the input documentation for details.                                                    |
+| [Single select](/docs/ui/components/select) | Select a single option from a list of many                                                                         | A select should be used when there are more than 5-7 options instead of radio buttons.                                                                            |
+| [Multi select](/docs/ui/components/select)  | Select multiple options from a list of many                                                                        | A select should be used when there are more than 5-7 options instead of checkboxes                                                                                |
+| [Checkbox](/docs/ui/components/checkbox)    | Single: toggle an option between yes/no, true/false, on/off. Multiple: select multiple options from a list of few. | Single checkboxes must never be a required input as there is no neutral state. Do not use a list of checkboxes for many (7+) options, use a multi select instead. |
+| [Radio](/docs/ui/components/radio)          | Select a single option from a list of few                                                                          | Do not use a list of radio buttons for many (7+) options, use a single select instead.                                                                            |
+| [File input](/docs/ui/components/fileinput) | Select a file                                                                                                      | Accepted file type and size should be made clear to the user before uploading                                                                                     |
+| [Transfer](/docs/ui/components/transfer)    | Select and order multiple options from a list of many in different categories.                                     | Use for complex selections that require specific ordering and filtering of categories.                                                                            |
 
 ## Form actions
 
-A form should always have a single, clear primary action. Often this action is 'Submit' or 'Save data'. Make sure the user understands what will happen when they submit a form. Additional options, like 'Save and add another', can be offered, but only a single primary action should be included. Make sure the action button label accurately describes the action. See the [content and communication section](../principles/content-communication.md) for more information of writing effective button labels.
+A form should always have a single, clear primary action. Often this action is 'Submit' or 'Save data'. Make sure the user understands what will happen when they submit a form. Additional options, like 'Save and add another', can be offered, but only a single primary action should be included. Make sure the action button label accurately describes the action. See the [content and communication section](/ui/principles/content-communication) for more information of writing effective button labels.
 
 ![example of clear form actions](/images/forms/actions.png)
 

docs/docs/principles/layout.md

@@ -132,8 +132,8 @@ The DHIS2 design system defines fives stack layers:
 | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Base Application Layer (0–1999) | Contains all components, controls and data for the main application. The application can define its own layering from 0 to 1999.                                                                                                                                       |
 | Application Top Layer (2000)    | Protected components that always layer over the top of the base application layer. This layer is reserved for controls such as dropdowns and popovers that functionally must always display above the application content.                                             |
-| Blocking Layer (3000)           | Blocks the application and its controls. Only use for actions that are intentionally interrupting. This layer contains a screen cover that blocks the layers beneath. Child elements, such as [modals](../components/modal.md) or loaders, can be added to this layer. |
+| Blocking Layer (3000)           | Blocks the application and its controls. Only use for actions that are intentionally interrupting. This layer contains a screen cover that blocks the layers beneath. Child elements, such as [modals](/docs/ui/components/modal) or loaders, can be added to this layer. |
 | Reserved (4000–9998)            | Reserved for future development.                                                                                                                                                                                                                                       |
-| Alert Layer (9999)              | The top layer is reserved for displaying [alert bars](../components/alertbar.md). Alert bars can contain critical information and so must always be displayed above all other content.                                                                                 |
+| Alert Layer (9999)              | The top layer is reserved for displaying [alert bars](/docs/ui/components/alertbar). Alert bars can contain critical information and so must always be displayed above all other content.                                                                                 |
 
 Note: the stacking system is not a technical implementation of `z-index` values. See the DHIS2 ui library for implementation details.