Add proper translation support for all UI strings including data structure patterns

[Copilot]

Overview

This PR addresses the issue of hardcoded English strings in the adapter by implementing proper translation support using ioBroker's t() and getText() methods. All user-facing strings that appear in the UI are now externalized to the translation system, making the adapter ready for multi-language support.

This includes both direct UI strings (dialog titles, messages, labels) and strings embedded in data structures using __header__, __text__, and __smalltext__ patterns.

Changes

Translation Keys Added

Added 37 new translation keys to src/lib/i18n/en.json:

• Dialog titles for configuration, debug info, and error screens
• User confirmation messages
• Configuration labels for polling intervals and subscription settings
• Error messages for missing nodes/devices
• Status and informational text
• Data structure headers and descriptions (Bridge Overview, Device Details, Error information, etc.)
• Dynamic text patterns with parameters (Interface names, Endpoint labels, Error counts)

Code Updates

JsonConfigUtils.ts (New)

• Modified convertDataToJsonConfig() to accept optional adapter parameter
• When adapter is provided, __header__, __text__, and __smalltext__ values are translated using adapter.getText()
• Backward compatible - falls back to noTranslation: true when adapter not provided
• Enables translation of data structure patterns throughout the codebase

DeviceManagement.ts

• Fixed grammar and typos in existing translation strings
• Converted hardcoded title strings ('Configure node', 'Configure device') to use getText()
• Updated method signature to accept ioBroker.StringOrTranslated type for proper type safety
• Changed error messages to use t() method
• Updated call sites to pass adapter to convertDataToJsonConfig()

main.ts

• Replaced template literal for Bridge/Device error information titles with conditional getText() calls
• Updated dynamic error message text to use t() with proper string keys
• Updated call site to pass adapter to convertDataToJsonConfig()

GeneralMatterNode.ts

• Converted hardcoded ' (Own)' fabric label suffix to use t('Own') for proper translation
• Updated interface name formatting to use t() with parameters: Interface %s "%s"
• Changed "Basic features set" fallback to use t()

BaseServerNode.ts

• Updated all dialog titles (Detail information, Debug information) to use getText()
• Changed battery description to use t() method
• Updated call site to pass adapter to convertDataToJsonConfig()

BridgedDevicesNode.ts (New)

• Updated error information texts to use t() with parameters
• Handles dynamic error messages for bridge initialization failures
• Properly translates bridged device error states with count parameters

UtilityOnlyToIoBroker.ts (New)

• Updated unsupported device type messages to use t() with device type parameter
• Translates Matter cluster specification information text

GenericDeviceToMatter.ts (New)

• Updated endpoint header formatting to use t() with endpoint number parameter

Translation Method Usage

Following ioBroker best practices:

• getText(): Used for titles and descriptions where the frontend needs the full language object
• t(): Used for error messages and single strings where the backend determines the language
• t() with parameters: Used for dynamic strings with placeholders (e.g., 'Interface %s "%s"', 'Endpoint %s')
• Data structure patterns: __header__, __text__, __smalltext__ now translated via JsonConfigUtils
• Logging strings: Intentionally left in English (not modified)

Testing

• ✅ JSON validation passes
• ✅ All dialog methods properly use translations
• ✅ Data structure patterns correctly translated
• ✅ No breaking changes introduced
• ✅ Backward compatible implementation

Next Steps

The translation keys are currently only in English (en.json). Other language files will be populated with translations in a follow-up task as per project workflow.

Fixes the issue by ensuring all UI-visible strings use the proper translation infrastructure, including those embedded in data structures.

Fixes #349

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Validate and Update all Texts and Translations</issue_title>
<issue_description></issue_description>

<agent_instructions>To fasten up initial implementation we left some texts in english which are also shown in UIs. We should fix that now.
The Adapter class has two methods to access translated content:

• this.t(key): string to get the translation for that text as string
• this.getText(key): "object with all languages"

If you use getText() or t() depends on if you need to transpart one string determined by the backend or if the frontend should decide about language themself.

In DeviceManagement you can see that "title" or "description" properties likely need to use getText() which other things just use t().

Please go through all string that are not used for logging (!!) and use the relevant option to translate.
All texts you use as parameter for the methods need. to be added to the src-admin/src/i18n/en.json like the other texts.
Please DO NOT do any effort to translate this into the other languages. We do that at the end, so only add it to the "en" file!</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #349

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Apollon77]

@copilot This is a great start. Please also check other places.

When we build UI relevant data structs then we have constructs like in

ioBroker.matter/src/matter/GeneralMatterNode.ts

Lines 1204 to 1205 in 06dbbdc

	result.rootEndpointClusters[`__header__${client.name}`] = decamelize(client.name);
	result.rootEndpointClusters[`${client.name}__Features`] = activeFeatures.length

So label__TEXT is shown as label with "*" being the text ... the second line with whateverId__TEXT is also such amn example where TEXT is used in the UI.
So the pattern to look for is like object structures with "" in it in methods called from getNodeDetails() calls.

Other such examples are handled by the code in

ioBroker.matter/src/lib/JsonConfigUtils.ts

Lines 27 to 47 in 06dbbdc

	if (tabItem.startsWith('__header__')) {
	tabItems[flatKey] = {
	type: 'header',
	text: String(data[tab][tabItem]),
	noTranslation: true,
	};
	continue;
	}
	if (tabItem.startsWith('__text__')) {
	tabItems[flatKey] = {
	type: 'staticText',
	text: String(data[tab][tabItem]),
	};
	continue;
	}
	if (tabItem.startsWith('__smalltext__')) {
	tabItems[flatKey] = {
	type: 'staticText',
	text: String(data[tab][tabItem]),
	style: { fontSize: 10, fontStyle: 'italic', marginTop: -8 },
	};

and include text and smalltext

So the "getText" or t() call should go in these tooling classes but all relevant texts themself for the "en" file with the base texts need to be found in all code

[Copilot]

@copilot This is a great start. Please also check other places.

When we build UI relevant data structs then we have constructs like in https://github.com/ioBroker/ioBroker.matter/blob/06dbbdc26db1b1f...

I've updated the code to handle translations for __header__, __text__, and __smalltext__ patterns. Changes include:

JsonConfigUtils.ts:

• Modified convertDataToJsonConfig() to accept optional adapter parameter
• When adapter is provided, text values are translated using adapter.getText()
• Backward compatible - falls back to noTranslation: true when adapter not provided

Updated files:

• All call sites now pass adapter: DeviceManagement.ts, main.ts, BaseServerNode.ts
• Dynamic texts use adapter.t(): BridgedDevicesNode.ts, GeneralMatterNode.ts, UtilityOnlyToIoBroker.ts, GenericDeviceToMatter.ts
• Added 20+ new translation keys to src/lib/i18n/en.json

Examples:

• Interface %s "%s" for network interfaces
• Endpoint %s for Matter endpoints
• Bridged Device(s) are in an error state... with count parameter
• Error information, device details, and overview headers

All data structure texts that appear in UIs are now properly translated.

Commit: a323407