Skip to content

Fix pre-existing QML issues in settings components (i18n, state sync, label fallback) #14217

@DonLakeFlyer

Description

@DonLakeFlyer

Pre-existing QML issues surfaced by the Copilot code review on #14216. These are not regressions — they existed in the original hand-coded QML pages and were carried over during the settings restructuring.

i18n / locale issues

1. Hard-coded English strings in RemoteIDGpsLocation.qml

gpsDisabled ("Disabled") and gpsUdpPort ("UDP Port") are plain English strings not wrapped in qsTr(). Downstream comparisons also rely on these English literals rather than indices or enum values.

2. Untranslated fallback in RemoteIDGpsLocation.qml

The "Serial <none available>" fallback entry appended to the combo model is not wrapped in qsTr().

3. Locale-broken visibility in NmeaGpsSettings.qml

Combo box entries use qsTr("Disabled") / qsTr("UDP Port") but visibility bindings compare currentText against hard-coded English strings. This breaks visibility logic in non-English locales. Should compare by index or underlying setting value instead.

Logic issues

4. State inconsistency in PX4LogUploadSettings.qml

saveItems() unchecks autoUploadCheck when the email address is empty, but never sets _mavlinkLogManager.enableAutoUpload = false in that branch. This can leave the manager state enabled while the UI shows it disabled.

5. Fact::label() empty fallback

Fact::label() returns the raw metadata label, which can be empty for older JSON/C++ metadata that has not been updated with a "label" field. Consider falling back to shortDescription() then name() when the label is empty. Currently a qCCritical log catches missing labels at startup, but the UI still shows blank.

Related PR: #14216

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions