Skip to content

Drop stale "instantly" claim from panic_note's source defaultValue - #1674

Open
krishrathi1 wants to merge 1 commit into
permissionlesstech:mainfrom
krishrathi1:fix/panic-note-stale-instantly-claim
Open

Drop stale "instantly" claim from panic_note's source defaultValue#1674
krishrathi1 wants to merge 1 commit into
permissionlesstech:mainfrom
krishrathi1:fix/panic-note-stale-instantly-claim

Conversation

@krishrathi1

Copy link
Copy Markdown
Contributor

Tiny follow-up to #1588, found while checking whether #152 was resolved.

#1588 correctly updated Localizable.xcstrings's app_info.settings.danger.panic_note entry to drop the "instantly" claim once the triple-tap wipe gained a confirmation dialog. It didn't update the matching defaultValue: in AppInfoView.swift's String(localized:defaultValue:) call -- that's just the extraction fallback (the catalog entry is what actually renders, since it exists), so nobody sees the wrong text today. But it's a live discrepancy in source: a future catalog regen or extraction pass reading only the Swift default would resurface "triple-tapping the bitchat/ logo does the same, instantly" as the caption text, silently reintroducing the exact claim #1588 removed.

One line, brings the fallback back in sync with the catalog value.

No Xcode/Swift toolchain available here, so this is verified by reading -- confirmed the new defaultValue is character-for-character identical to the current Localizable.xcstrings en value for this key, and that panicNote has exactly one other call site (AppInfoView.swift:572, unaffected -- it renders the catalog value, not the default).

permissionlesstech#1588 updated the Localizable.xcstrings catalog entry for
app_info.settings.danger.panic_note to drop "instantly" once the
triple-tap wipe gained a confirmation dialog, but left this Swift
source's inline defaultValue (the extraction fallback, not what
actually renders since the catalog entry takes precedence) still
claiming the old instant, unconfirmed behavior. Brings the fallback
back in sync with the catalog so a future extraction pass or catalog
regen can't resurface the stale claim.

Noticed while checking whether permissionlesstech#152 was resolved by permissionlesstech#1588 -- it was;
this is the one loose end.

@Chessing234 Chessing234 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this defaultValue never renders — the catalog entry is what shows. please fold the string into a real code pr rather than a one-line fallback that nobody sees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants