Initial commit

skills/next-intl/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: next-intl-skill
+description: ALWAYS use this skill if the user asks anything about next-intl or translations
+allowed-tools: Bash, Glob, Grep, LS, Read, Edit, MultiEdit, Write, TodoWrite, mcp__plugin_automation_context-forge-mcp__update_subtask_content
+---
+
+You are an expert in internationalization and localization, specifically with the next-intl library in Next.js projects. Your primary responsibility is managing translations in the messages/de.json file and ensuring all text in the codebase uses proper translation keys.
+
+ALWAYS start by reading the `./reference/general-information.md` file!
+
+## Adding translations
+
+1. Look up the correct documentation for a given featureType inside `./reference/features/`. There is one Markdown file for each featureType that explains the translations.
+2. Based on the reference and the context that you receive correctly add the translation to the `de.json` file.
+3. Build the answer according to the `./reference/response.md` file

skills/next-intl/reference/features/form.md

@@ -0,0 +1,44 @@
+# Form Translations
+
+## General translation structure
+
+```json
+"{featureName}.{product}.{role}.forms.{formName}": {
+   "fields": {
+    // add translations for all fields here
+   }
+}
+```
+
+## FieldName structure
+
+For fields that are not Array fields the translations are pretty stright forward and you can add them base on the context. Some fields will have an item property where you will get the key and translation from as well. Here is an example
+
+```json
+"fields": {
+    "{fieldName}": {
+        "label": "Label Translation",
+        // all other translations here,
+        "items": {
+            "up_to_2_years": "bis 2 Jahre",
+            "up_to_3_years": "bis 3 Jahre",
+        }
+    }
+}
+```
+
+## Array Field Structure
+
+Array fields will have a parent field name and will have a list of all child fields as keys. Here it is how it will look like:
+
+```json
+"fields": {
+    "{arrayFieldName}": {
+        "add": "Add Button Caption",
+        "{childField}": {
+            "label": "Label Translation",
+            // all other translations as for the normal fields
+        }
+    }
+}
+```

skills/next-intl/reference/features/inquiry-process.md

@@ -0,0 +1,23 @@
+# Inquiry Process Translations
+
+```json
+"{featureName}.{product}.{role}": {
+   "progressBar": {
+      "groups": {
+        "{groupName}": "Group Translation"
+      },
+      "steps": {
+         "{stepName}": "StepName Translation"
+      },
+   },
+   "{steps}": { // <-- Add one object for each step that is provided
+    "title": "StepTitle",
+    "description": "Description",
+    "fields": {} // add this in preparation
+   }
+}
+```
+
+# Inquiry Process Form / Step
+
+The inquiry process will have multiple steps which each are a single form. Add the translations to the fields for the steps that are already prepared!

skills/next-intl/reference/features/list.md

@@ -0,0 +1,120 @@
+# List Translations
+
+```json
+{
+    "{featureName}.{product}.{role}.lists.{listName}": {
+        "title": "",
+        "columns": {
+            // translations for all columns
+        },
+        "noItems": "",
+    }
+}
+```
+
+## List Actions
+
+Some lists have the ability to filter / sort / group the list. There we will need some more translations in the following form:
+
+```json
+{
+    "{listName}": {
+      "actions": {
+        "label": "Suchen & Filtern",
+        "search": { // only add this if searching is enabled
+            "label": "Suche",
+            "placeholder": "Suche nach Anfragen",
+        },
+        "groupBy": { // only add this if grouping is enabled
+            "label": "Gruppieren nach",
+            "options": {
+                "none": "Keine Gruppierung",
+                "status": {
+                   "label": "",
+                    "titles": {
+                        // one title for each status item
+                    }
+                },
+                // for each group by enum the same as for status
+            }
+        },
+        "sortBy": { // only add this if sorting is enabled
+            "label": "Sortieren nach",
+            "options": {
+                "none": "Keine Sortierung",
+                "createdAtAsc": "",
+                // for each sorting option a translation
+            }
+        },
+        "reset": "Zurücksetzen"
+    }
+    }
+}
+```
+
+## Grouping and Sorting translations
+
+In your context you will receive a swagger documentation that looks like this:
+
+```yaml
+get:
+  summary: Gets the list of financing cases
+  tags:
+    - Financial Service Providers
+  security:
+    - apiToken: []
+  parameters:
+    - name: q
+      in: query
+      style: deepObject
+      schema:
+        type: object
+        properties:
+          status_eq:
+            type: string
+            enum:
+              - unmapped
+              - incomplete
+              - awaiting_market_value_indication
+              - awaiting_offers
+              - awaiting_contract_details
+              - awaiting_contract
+              - awaiting_signature
+              - active_contract
+              - archived
+          case_manager_id_eq:
+            type: string
+          hoa_already_customer:
+            type: boolean
+          management_already_customer:
+            type: boolean
+          search_term:
+            type: string
+          sort:
+            type: string
+            enum:
+              - submitted_at asc
+              - submitted_at desc
+              - created_at asc
+              - created_at desc
+              - status asc
+              - status desc
+              - property_management asc
+              - property_management desc
+            description: Sort options. Default is `submitted_at desc, created_at desc`.
+
+```
+
+### Sorting
+
+For sorting you look for the `sort` parameter and add translations for all enums. Just use the correct german translations for this
+
+### Grouping 
+
+Grouping is a bit trickier. IGNORE all keys that are `sort`, `search_tearm` or that have the type: `string`. For all others either use the `enum` values and translate them to german or for booleans you can just go with `true` and `false` as keys and translate them to `Ja` and `Nein`
+
+From the example above there is `case_manager_id_eq: type: string`. Just ignore this since there are no sensible values for groupings. Do this with ALL properties from type string!
+
+
+
+

skills/next-intl/reference/features/modal.md

@@ -0,0 +1,10 @@
+# Modal Translations
+
+## General translation structure
+
+```json
+"{featureName}.{product}.{role}.modals.{modalName}": {
+    "title": "",
+    // all other translations that are needed
+}
+```

skills/next-intl/reference/features/page.md

@@ -0,0 +1,14 @@
+# Page translations
+
+## General translations
+
+The structure for pages is pretty simple. Portal pages will just have a title and Inquiry Pages will have a title and a description.
+
+Follow the general-information structure and afterwards add the following keys / translations:
+
+```json
+{
+    "title": "",
+    "description": "" // <-- add description where applicable
+}
+```

skills/next-intl/reference/features/task-groups.md

@@ -0,0 +1,43 @@
+# Task Group Translations
+
+## General translation structure
+
+```json
+"{featureName}.{product}.{role}.taskGroups": {
+      "{taskGroupName}": {
+         "label": "",
+         "taskPanels": {},
+         "actionPanel": {}
+      }
+   }
+}
+```
+
+## Task Panel translations
+
+```json
+{
+    "{taskPanelName}": {
+        "label": "",
+        // some custom properties might be mentioned in the context as well
+        // if there are subtasks
+        "subtasks": {
+            "{subTaskName}": {
+                "title": "",
+                "actionLabel: ""
+            }
+        }
+    }
+}
+```
+
+## Action Panel translations
+
+```json
+{
+    "{actionPanelName}": {
+        "title": "",
+        "disabledHint": ""
+    }
+}
+```

skills/next-intl/reference/general-information.md

@@ -0,0 +1,50 @@
+# General information
+
+This file explains some general concepts for translations with the finstreet boilerplate.
+
+The `de.json` file that contains all of the projects translations follows a strict structure. First of all there are some general translations for `buttons`, `notifications`, `validations`
+
+```json
+{
+  "buttons": {
+    "cancel": "Abbrechen",
+    "back": "Zurück",
+    "next": "Weiter",
+    "submit": "Speichern"
+  },
+  "notifications": {},
+  "validations": {}
+}
+```
+
+Afterwards we structure our validations in the following way:
+
+```json
+{
+  "{featureName}": {
+    "{product}": {
+      "{role}": {
+        // translations
+      }
+    }
+  }
+}
+```
+
+Sometimes it's
+
+```json
+{
+  "{featureName}": {
+    "{product}": {
+      "{role}": {
+        "{subFeatureNames}": {
+          // translations
+        }
+      }
+    }
+  }
+}
+```
+
+`Product` and `role` might not be available. These are ALWAYS optional and you can just leave them out if they are not provided

skills/next-intl/reference/response.md

@@ -0,0 +1,7 @@
+# Response
+
+I want you to ALWAYS answer in the following format:
+
+# Translations
+
+List all of the keys with their respecitve translations so that other Agents can use this as documentation for known translations