Add interactive TUI browser subcommand (`python -m wn browse`)

[Salah-Sal]

Is your feature request related to a problem? Please describe.

Yes. I'm frequently frustrated when I need to explore wordnet relationships and hierarchies because it requires:

• Writing Python scripts for every query
• Understanding the full API before getting started
• Mentally reconstructing hierarchies from programmatic output

This creates significant barriers for linguists, students, and researchers without programming backgrounds who want to explore semantic relationships visually. Even for developers, quick lookups during development require context-switching to write and run code.

Describe the solution you'd like

I'd like an interactive Text User Interface (TUI) browser accessible via a new subcommand:

python -m wn browse              # Launch interactive TUI
python -m wn browse --lang en    # Browse specific lexicon

Key features:

• Visual tree navigation: Use arrow keys to explore hypernym/hyponym hierarchies
• Interactive search: Type a word → see all senses → select one → explore relationships
• Full-text search: Find synsets by searching definitions
• Multi-language: Browse any installed lexicon
• Export: Save tree views to files for documentation

User experience:
Type "dog" → Select sense → View tree (↑hypernyms, ↓hyponyms) → Navigate with arrows → Press Enter on any synset to re-root the tree there.

Technical approach:

• Optional dependencies (Rich, Textual) via pip install wn[tui]
• New wn/browser/ module with adapter to bridge TUI → wn API
• Leverages existing wn.Synset methods (.hypernyms(), .hyponyms(), .definition())
• SQL backend provides 10-100x faster queries than in-memory alternatives

Describe alternatives you've considered

1. Separate package (wn-tui): Would work but harder to discover and requires separate maintenance
2. Web interface only: Already have wn.web for that use case; TUI serves different niche (terminal-native, no server)
3. Enhanced CLI with flags: Less intuitive than interactive navigation; doesn't provide visual feedback
4. Keep using NLTK-based standalone tool: Works but doesn't leverage wn's superior SQL backend and multi-language support

Additional context

• Proof of concept: I have a working TUI using NLTK backend (~500 LOC) with navigation, search, export, and Arabic support. Ready to adapt for wn.
• Unique feature: Would be the first interactive TUI in the Python wordnet ecosystem
• Educational value: Visual tool for teaching semantic concepts in classrooms
• Implementation timeline: 2-3 weeks for MVP
• Commitment: I'm willing to implement, test, document, and maintain this feature long-term

Integration assessment: I've analyzed the technical feasibility in detail and found 90%+ API compatibility between requirements and existing wn.Synset interface. Happy to share the full technical design document if helpful.

here some screenshots:

[goodmami]

@Salah-Sal hi and thanks for the suggestion and the detailed request.

This looks very useful and I like the idea. I'm not entirely sold on including it in the Wn library rather than as a separate application, though. One reason is a matter of principle: Wn is a library, not an application (I may even prefer to move wn.web to a separate repository, although I have no immediate plans). The second is a matter of practicality: I don't think I can manage the time to maintain another submodule.

1. Separate package (wn-tui): Would work but harder to discover and requires separate maintenance

This would be my preference. As for discovery, I'm happy to link to it from the Wn documentation, as long as it remains functional. As for maintenance, that's up to the maintainer. I would suggest having unit tests that run on some schedule (e.g., weekly) to check if Wn has a new release and running the tests if so.

Also, regarding "separate" maintenance, simply being in the Wn project does not mean it stays up-to-date with the core API. API changes would still need to be performed in the affected modules.

There are some other projects that have used this approach:

• https://github.com/mufeedali/Wordbook is a GNOME dictionary application using Wn as the backend
• https://github.com/Hypercookie/wn-editor is a library extension for editing wordnet data

Finally, if I weren't the only active maintainer of Wn, it might be easier to accept new modules.

Commitment: I'm willing to implement, test, document, and maintain this feature long-term

If that's true, then I would be willing to consider a PR. If the code is clean and not too large, then I may be convinced. Even if not, the PR should be easy to convert into a separate package.

---

note: I've been preparing a 1.0 release for some months now in my limited spare time. It shouldn't break too many things, but there's a chance it might affect something you've implemented.