docs: Add calendar resource strings documentation.

[damyanpetev]

Description

Addition to #286 for the calendar resource strings, since those need to be reviewed specially and/or updated.

Type of Change (check all that apply):

• Bug fix
• New functionality
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (no functional changes)
• Documentation
• Demos
• CI/CD
• Tests
• Changelog

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code
• This PR includes API docs for newly added methods/properties
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes behavioral changes and the feature specification has been updated with them
• Accessibility (ARIA, keyboard navigation, focus management) has been verified

[Copilot]

Pull request overview

Adds XML documentation to IgbCalendarResourceStrings, improving discoverability and clarifying how calendar/date-picker localization strings map to UI (including notes about defaults and an explicitly non-functional string).

Changes:

• Added a class-level <summary> explaining where the resource strings are exposed (ResourceStrings on IgbCalendar / IgbDatePicker).
• Added <summary> / <remarks> documentation for the individual resource string [Parameter] properties (header titles, placeholders, week label, and aria-label strings).

Suppressed comments (7)

src/components/Blazor/CalendarResourceStrings.cs:48

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the header button that switches the calendar to the years view.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:182

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the days view one month back.
        /// Defaults to <c>Previous Month</c>.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:204

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the days view one month forward.
        /// Defaults to <c>Next Month</c>.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:226

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the months view one year back.
        /// Defaults to <c>Previous Year</c>.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:248

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the months view one year forward.
        /// Defaults to <c>Next Year</c>.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:270

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the years view one page back.
        /// Defaults to <c>Previous {0} Years</c>, where <c>{0}</c> is the number of years on a page.
        /// </summary>

src/components/Blazor/CalendarResourceStrings.cs:292

• XML documentation doesn’t interpret Markdown backticks; use for inline code so the attribute name renders correctly in generated docs.

        /// <summary>
        /// The accessibility attribute `aria-label` of the navigation button that moves the years view one page forward.
        /// Defaults to <c>Next {0} Years</c>, where <c>{0}</c> is the number of years on a page.
        /// </summary>

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[damyanpetev]

@skrustev "Accessible name" would the technically correct term, but to avoid relying on users being familiar w/ the ARIA glossary, went with using "label" instead. However, that was still in general term, without disclosing actual implementation (yes it's aria-label attribute now, can be internals, aria-labelledby, title tomorrow). Or more.

So either the original "Accessible label" which I think was well clear, or if that's too "ordinary English" - ARIA label I suppose. Still can't make Claude agree that's better and it's active fighting against it, but ¯_(ツ)_/¯

[damyanpetev]

Yeah, actually nvm, just spent over 30mins I'm not getting back arguing with a bot to get it to like the other naming.
And it's right, some of the options are not even considered ARIA, and the category/purpose is better;

@copilot just replace all instances of "accessibility attribute aria-label" back with "accessible label"

[Copilot]

Replaced all instances of "accessibility attribute aria-label" with "accessible label" in commit.

[skrustev]

I think we agreed on the "ARIA labels" or something like that? "Accessible label" to me is too broad term and could mean something else imo, like an actual <label> that is accessible? Not necessarily accessibility, which if I am just opening that property would probably scratch my head where is that?
Even "accessibility labels" is better term imo but that's my two cents.

[damyanpetev]

That's precisely the point, it can be an actual <label> or title attribute (or both along with the ARIA attribute). The implementation is not part of the goal of the resource string and the broad term is use is intentional. And no, I don't think it's that confusing what "accessible" means in this context, should be pretty well established, being its the A in ARIA;