Hello @Saiphani02 I'm aware the contribution period has ended but can I work on this?

Afaik, you can contribute till end of the month? Anyway, would love to know how you plan to implement this

Alright thank you! Here is my implementation proposal for the book update feature

Context: The wsindex API currently tracks book changes via a last_updated timestamp (line 22 in books/models.py), but this field is not exposed to the Kotlin app, making it impossible for users to know when downloaded books have been updated on Wikisource.

Proposed Solution: Lightweight Update Detection

Phase 1: Expose Update Metadata (Backend - wsindex API)

1. Add last_updated to API response - Modify books/serializers.py:

fields = [
    'wikidata_qid', 'title', 'title_native_language', 'languages', 
    'date_of_publication', 'authors', 'editors', 'translators', 
    'genre', 'type_of_work', 'ws_url', 'thumbnail_url', 'epub_url', 
    'wikisource_index_url', 'view_count', 'subjects',
    'last_updated'  # Add this field
]

2. Optional: Add bulk update check endpoint - New endpoint in books/views.py for efficient batch checking:

POST /books/check-updates/
Request: {"books": [{"id": "Q123", "last_updated": "2024-01-01T00:00:00Z"}, ...]}
Response: {"updates_available": ["Q123", "Q456"]}

Phase 2: Client Implementation (Wikisource Reader App)

1. Store last_updated with each download - Persist timestamp when user downloads EPUB
2. Show update indicator - Compare stored timestamp with API response on book detail view
3. Manual update flow - Add "Update Available" badge/button that re-downloads from epub_url

Why This Works

• Existing infrastructure: The last_updated field already tracks changes automatically via Django's auto_now=True (updated whenever book metadata or relationships change during the updatecatalog sync)
• No additional storage: No new database tables or fields required
• Minimal API changes: Single serializer field addition
• User control: Update is manual, avoiding unnecessary downloads
• Efficient: Timestamp comparison is extremely fast

Technical Details

The updatecatalog command (books/management/commands/updatecatalog.py) uses update_or_create() which automatically updates last_updated when:
Book metadata changes (title, date, URLs, etc.)
Relationships change (authors, genres, languages, etc.)
View count updates
Current sync runs fetch from Wikidata/Wikisource, regenerate thumbnails, recalculate view counts, and update EPUBs
The timestamp reliably indicates "something changed about this book"

Open Questions for Discussion

Granularity: Should we differentiate between metadata changes vs content changes, or is a single timestamp sufficient?
Bulk vs Individual: Should we prioritize a bulk check endpoint for checking many books at once, or rely on the existing list/detail endpoints?
Auto-download: Should updates be automatic in background, or require user confirmation?

The timestamp in the API is not about the actual content in the work. It is when the specific item's metadata is updated (currently daily). Let us wait to hear other opinions and see if we can just add an update icon beside the share icon.

Oh alright then. I’ll check out other issues if available
Thank you for the clarification