Maybe rename “Category” to “Short Description” 
1 Like
Please make the Configure option label (Show 'Url' column) match the Column header text (Website URL)
@Nick-Hall
the subject of suppressing the before-and-after redundancy when labeling checkboxes in Configure dialogs has come up before. But I do not recall seeing a solution.
Is there a recommended example of making a Configure checkbox (and/or radio buttons) without the redundant leading label?
Or maybe it should be : Website URL column ☑ Show or Show ☑ Website URL column ? Probably the second. Since that supports a group labeled “Show” checkboxes (with an All) options naturally evolving without a major GUI re-organizing.
1 Like
Description or Title would be better. They already exist as translated strings.
We don’t use a leading label for checkboxes.
1 Like
Done, local update at the moment.
1 Like
Title is better because Description is a bit similar to Comment
1 Like
Done and released.
- ‘Comment’ column is added
- Additional setting is added
- Category is renamed to Title ewerywhere including CSV files
Release v0.35.20 · jurchello/WebSearch · GitHub
1 Like
Give me know pls what can I do for MediaWiki additionally. Thanks!
There’s a placeholder page (based on your simplified README.md) now. Lots of work to do.
Could you do a new screen capture? Something not in Dark Mode with the Gramplet undocked, With some representative rows (Person with a followed link, Place, Source search, plus at least 1 UID, the AI bottombar active and a context menu active.)
Something like:
but populated. (I haven’t set up the AI configuration yet.)
Just discovered that the UID Attribute name for a FamilySearch profile could be either _FSFTID or _fsftid
So how do we set up the JSON for case insensitive matching?
I need make a small fix to ignore letters case in attributes.
1 Like
I can not show all supported Nav types (People, Sources, Families, and Places) in one screenshot. All the screensots above are shown for People page. Do you need all others Nav types as separate screenshots?
1 Like
Done. Now comparison by attribute name is case insensitive
1 Like
It is probaby overkill for the 1st draft of the wiki… but it may help us identify oddities.
For example, I think the context menu may be missing the menu item for write to Note when the Nav type isn’t “People”
for the MVP version I’ve decided show it for People only.
if nav_type == SupportedNavTypes.PEOPLE.value:
#add_attribute_item.show()
self.ui.context_menu_items.add_note.show()
else:
#add_attribute_item.hide()
self.ui.context_menu_items.add_note.hide()
It need additional testing (especially new attributes adding). I had some bug with it and I think it should be good tested before release because it updates the DB.
1 Like
It lacks feedback that something occurred. And if the created Note was attached anywhere.
I wonder if it wouldn’t be better to open a Note Editor window with the data and let the User decide whether to click Cancel or OK? Because it also seems likely the next step would be to scrape some data from the linked webpage into the Note. Such as the pre-formatted Citation from a FindAGrave memorial:
Find a Grave, database and images (George Washington (1732-1799) - Find a Grave Memorial accessed March 21, 2025), memorial page for George Washington (22 Feb 1732–14 Dec 1799), Find a Grave Memorial ID 6781, citing Mount Vernon Estate, Mount Vernon, Fairfax County, Virginia, USA; Maintained by Find a Grave.
And should the Type of Note be General? I think that adding a Note from the Person Editor defaults to Person Note
1 Like
you are right. I will add the task for future
1 Like
Agree. Added to the planned tasks for future.
1 Like
