You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+3-26Lines changed: 3 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,38 +88,15 @@ Accessibility is an integral part of any UI component. We as a team are committe
88
88
2.`status: localized` this status is for issues that were with a pending translation status and have already been localized. Place this status label once these translation changes have been included in the current pull request, or the changes are already pulled with a different pull request.
89
89
90
90
## Localization (i18n) - applicable to components' string resources
91
-
There are several ways to localize components' string resources:
91
+
There are several ways to localize components' string resources. For more information on how it works, refer to our [Documentation - Localization (i18n)](https://www.infragistics.com/products/ignite-ui-angular/angular/components/general/localization#localization-i18n-1).
92
92
93
-
1. Using custom resource strings:
94
-
1.1. Localize a given instance of component - each component which supports localization has input property `resourceStrings`. Setting a newly instantiated object to this property will localize only that given component's instance.
95
-
1.2. Localize all resources for a component type - each component which supports localization has input property `resourceStrings`. To localize all instances of a given component in the application the following steps should be performed - get the value of the input property `resourceStrings` of the component to be localized; do not create a new instance but replace the existing strings within the object. By default all components of a given type in an application share one instance of the resource strings. Replacing a value in that instance affects all components of that type in the application.
96
-
1.3. Localize all resources for all components - use global method `getCurrentResourceStrings` to get an object containing current resource strings for all components. To provide localized resources just pass an object of type `IResourceStrings` to the global method `changei18n`.
97
-
1.4 As of 21.1.x the localization has new implementation and you can use the new API `registerI18n` to register resource string for a component or all components for the whole app, as well as which locale it corresponds to. To localize a single component you will need to get is corresponding resource string keys using one of the available resources and provide only those keys.
93
+
**NOTE** As of 21.1.x, the localization resource strings have been moved to the [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n) repository under `projects/igniteui-i18n-resources`. The package `igniteui-angular-i18n` under `./projects/igniteui-angular-i18n` remains as a source of the localization resources for Ignite UI for Angular, that derives the resources from [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n).
98
94
99
-
2. Using npm package:
100
-
We've created new repository which will hold the resource strings for languages different than English:
101
-
https://github.com/IgniteUI/igniteui-angular-i18n
102
-
103
-
**NOTE** The localization repo has been moved to live inside the `igniteui-angular` repository under `./projects/igniteui-angular-i18n`
104
-
**NOTE** As of 21.1.x the localization resource strings have been moved to the [`igniteui-i18n`](https://github.com/IgniteUI/igniteui-i18n) repository under `projects/igniteui-i18n-resources`.
95
+
**NOTE (21.0.x and lower)** The localization resource strings live inside the `igniteui-angular` repository under `./projects/igniteui-angular-i18n`.
105
96
106
97
A npm package should be published each time we release new version of Ignite UI for Angular. Its version should correspond to the version of the igniteui-angular npm package.
107
98
One could localize an application by importing the corresponding localized resource strings from the localization package (`igniteui-angular-i18n`) and use the methods described in the previous bullet to localize the whole application or part of it.
108
99
109
-
**Example:**
110
-
111
-
Inside app.module you can perform:
112
-
```ts
113
-
import { IgxResouceStringsJA } from ‘igniteui-angular-i18n’;
114
-
changei18n(IgxResouceStringsJA);
115
-
```
116
-
117
-
**Example new API:**
118
-
```ts
119
-
import { ResouceStringsJA } from ‘igniteui-i18n-resources’;
120
-
registerI18n(IgxResouceStringsJA, 'ja');
121
-
```
122
-
123
100
### Resource strings keys naming convention
124
101
Each key in the `IResourceStrings` (and `IGridResourceStrings`, `ITimePickerResourceStrings`, etc.) is prefixed with components' selector and followed by the resource string key. Having components' selectors as prefixes allows us to have same resource strings keys for more than one component.
- Reuse existing repository patterns before introducing new abstractions.
51
-
- Read existing source and tests before editing.
52
-
- Run `npm run lint:lib` and the relevant test suite before considering work complete.
59
+
- Read the original request, existing source, and existing tests before editing.
60
+
- Read the relevant skill file before modifying component code.
61
+
- If a skill points to reference files, read the relevant reference files before editing.
62
+
- If the task changes behavior or fixes a bug, write or update failing tests before production code.
63
+
- Reuse the existing spec structure whenever possible.
64
+
- Run the smallest relevant test suite and `npm run lint:lib` before considering work complete.
65
+
- Run additional checks when applicable, such as `npm run lint:styles`, `npm run test:styles`, `npm run test:schematics`, `npm run build:migrations`, or i18n-specific checks.
53
66
- Export new public symbols from `<component>/index.ts`.
- Add JSDoc with `@param`, `@returns`, and `@example` on every new public member.
70
+
- Treat SCSS, theme wiring, and style-test work as dedicated theming/styles follow-through, and validate it with the relevant style checks when needed.
57
71
- Add or update `ng update` migrations for true breaking changes such as removals, renames, moved entry points, selector changes, or incompatible default-behavior changes.
58
-
- Update the component `README.md` when the public API surface changes.
59
-
- Update relevant Agent skills if a change is significant and/or you need to tell other agents how to use the newly introduced feature.
72
+
- Update the component `README.md` when public API, documented usage, or documented behavior changes, including new features, renamed or deprecated API, and behavior changes.
60
73
- Consider demo/sample updates in `src/app/` only for explicitly requested user-visible changes.
61
-
- Update `CHANGELOG.md` for new features, deprecations, breaking changes, and notable user-visible fixes when they fit the existing changelog section structure.
74
+
- Update `CHANGELOG.md` for new features, deprecations, breaking changes, behavioral changes, and notable user-visible fixes when they fit the existing changelog section structure.
75
+
- Update relevant Agent skills if a change is significant and/or you need to tell other agents how to use the newly introduced feature.
62
76
63
77
### Never
64
78
65
-
- Skip steps in the implementation.
79
+
- Skip steps in the implementation.
66
80
- Commit secrets, tokens, or credentials.
67
81
- Introduce `eval()` or dynamic code execution.
68
82
- Modify `package.json`, `package-lock.json`, or any other dependency manifest or lock file. If a dependency change appears truly necessary, ask for approval first. Never commit `package-lock.json` unless you have been explicitly approved to make dependency changes — committing unintended lock file changes can break builds.
@@ -110,23 +124,28 @@ Domain-specific knowledge for AI assistants:
110
124
111
125
## Custom Agents
112
126
113
-
Feature implementation is handled by a set of specialized agents in `.github/agents/`:
127
+
The repository provides a set of agents in `.github/agents/`. Orchestrators analyze requests, define scope, and route work to the right specialists; they do not implement code directly. Specialists handle focused implementation and follow-through tasks.
114
128
115
-
| Agent | File | Purpose |
116
-
|---|---|---|
117
-
|`feature-orchestrator-agent`|`feature-orchestrator-agent.md`| Orchestrates end-to-end feature implementation via TDD |
118
-
|`bug-fixing-orchestrator-agent`|`bug-fixing-orchestrator-agent.md`| Orchestrates end-to-end bug fixing via TDD |
119
-
|`tdd-test-writer-agent`|`tdd-test-writer-agent.md`| Writes failing tests (RED phase) for features and bug fixes |
120
-
|`feature-implementer-agent`|`feature-implementer-agent.md`| Implements features and refactors (GREEN + REFACTOR phases) |
121
-
|`bug-fixing-implementer-agent`|`bug-fixing-implementer-agent.md`| Implements the minimum bug fix (GREEN phase) |
|`demo-sample-agent`|`demo-sample-agent.md`| Updates existing demo/sample areas in `src/app/` when a demo is explicitly requested for a user-visible feature or bug fix |
124
-
|`component-readme-agent`|`component-readme-agent.md`| Updates affected component `README.md` files for public API and documented behavior changes |
125
-
|`migration-agent`|`migration-agent.md`| Creates `ng update` migration schematics for breaking changes |
126
-
|`changelog-agent`|`changelog-agent.md`| Updates `CHANGELOG.md` following repo conventions |
127
-
128
-
Feature and bug orchestrators route work in this order:
|`feature-orchestrator-agent`| Orchestrator |`feature-orchestrator-agent.md`| Analyzing feature requests, defining scope, deciding which specialists are needed, and routing the work. Does not implement code directly. |
132
+
|`bug-fixing-orchestrator-agent`| Orchestrator |`bug-fixing-orchestrator-agent.md`| Analyzing bug reports, confirming likely scope and root-cause direction, deciding which specialists are needed, and routing the work. Does not implement code directly. |
133
+
|`tdd-test-writer-agent`| Specialist |`tdd-test-writer-agent.md`| Writing small failing tests before production code for features and bug fixes |
134
+
|`feature-implementer-agent`| Specialist |`feature-implementer-agent.md`| Implementing a feature or feature-side refactor after scope and tests are clear |
135
+
|`bug-fixing-implementer-agent`| Specialist |`bug-fixing-implementer-agent.md`| Implementing the minimum safe bug fix once reproduction and root cause are known |
|`demo-sample-agent`| Specialist |`demo-sample-agent.md`| Updating existing `src/app/` demo/sample areas for explicitly requested user-visible changes |
138
+
|`component-readme-agent`| Specialist |`component-readme-agent.md`| Updating affected component `README.md` files when public API or documented behavior changes |
|`changelog-agent`| Specialist |`changelog-agent.md`| Updating `CHANGELOG.md` for notable user-visible changes |
141
+
142
+
These agents are available as specialized helpers for repository work. Select and use the relevant subagent when it adds clarity, specialization, or better task separation, but do not treat subagent use as mandatory — an agent may decide to handle the work directly as long as it follows the same repository workflow, standards, and validation steps.
143
+
144
+
## Workflow
145
+
146
+
### Standard default flow
147
+
148
+
TDD (write or update failing tests first) → feature implementation or bug-fix implementation → theming/styles follow-through (only when the change affects SCSS, theme wiring, or style-test validation) → demo/sample update (only if explicitly requested) → component README update (when needed) → migration (for breaking changes) → changelog update (when needed).
0 commit comments