Testers needed for Reading Tracker plugin

[dunhill]

Hi, Varia

I’ve been reviewing the translation structure for the plugin, and I’d like to suggest some technical improvements to ensure that multi-language support doesn't break the tracker’s core functionality. Currently, there are a few critical points that could affect users who don’t use calibre in English:

1. Separation of Logic and Presentation (UI vs. Data):
The plugin currently uses a list of statuses like STATUSES = [_('Reading'), _('Finished')...]. The issue here is that when these strings are translated, the plugin will attempt to query the Calibre database using the translated terms (e.g., "Leyendo", "Terminado", "Lendo", or "Fini"). If a user already has their books tagged as "Reading" or "Finished", the plugin will fail to find them as soon as they switch languages.

Alternative Suggestion (Standardized Keywords): To keep the logic simple, the plugin could enforce Internal Standard Keywords for the database entries (e.g., Reading, Finished, TBR) while using the translation engine only for the UI labels. This way, the database remains consistent even if the display label changes.

2. Dynamic Status Mapping:
Given that users often have their own naming conventions (e.g., using "Read" instead of "Finished", or "Leído" in Spanish), it would be ideal to allow users to define in the settings which value from their custom column corresponds to each of the plugin's logical statuses.

3. Flexible Layouts for Romance Languages:
Languages like Spanish, French, and Portuguese are typically 20–30% more verbose than English. I noticed several widgets with fixed widths (setFixedWidth). For example:

English: "Edit Mode" (short)

Spanish: "Modo Edición" (longer)

French: "Mode d'édition" (even longer)

Suggestion: I recommend using dynamic layouts or minimumSizeHint instead of hardcoded widths to prevent the UI from clipping or breaking when labels expand.

4. Date and Month Parsing Normalization:
When translating month abbreviations (e.g., Jan -> Ene/Janv), we must ensure that the date parsing functions (_parse_date) are robust and bidirectional. If a user switches the plugin language mid-year, the logic shouldn't fail to recognize dates stored in the previous language format.

I hope these suggestions help make the plugin more robust and user-friendly for the global calibre community.

Best regards,

[varia]

Originally Posted by dunhill

Hi, Varia

I’ve been reviewing the translation structure for the plugin, and I’d like to suggest some technical improvements to ensure that multi-language support doesn't break the tracker’s core functionality. Currently, there are a few critical points that could affect users who don’t use calibre in English...

Hi Dunhill, thank you very much.
To the greatest extent I want the plugin to be flexible in terms of language. Great suggestions, and I have added these all to the project coding map.

Best regards,
VariaM

[dunhill]

Furthermore, I'm trying to get translation support, and when I try again, the plugin won't load. I'll retrace my steps; first, I'll try translating what I can see, and then I'll test it more thoroughly.

[DNSB]

I tried installing v1.1.1 and noticed two things. I get an error about #finished_date (which was set to Kobo Last Read date (#kobolastread) when I configured the earlier version. When I looked at reconfiguring, checking the plugin in preferences, there are no customization options and no way I can see to open a customization dialog from the Tracker icon.

Edit: wiped the setup and went through configuration. Seems to be working now but complains on first start about #my_rating being missing. Which it is since I don't rate my books so My Ratings is not mapped.

[CAIArchive]

Quick non-programmer thing to try to get your dashboard to possibly have info.
restart calibre.
right click the plugin icon/or the context menu item
go to the columns tab
click save once or twice
go to the tracker tab
click refresh once or twice
go back to dashboard tab
click refresh once or twice
I have had it be blank when loading into the plugin, and by doing the above it had info populating the fields. Though I do suspect if its a hardcoding issue, it may not do anything, but worth a shot?

[JSWolf]

@varia, you have too many unneeded required columns. Some of them really need to be optional.

Tracked, my review, and type should all be optional.

As for tracked, see how Reading List adds books to your lists without the need for a column to add them.

Start date and finished date should just be one date column. If you look at Kobo Utilities, you'll see it tracks reading position on a Kobo Reader. There is % & timestamp That timestamp is the only date I would need.

[MSWallack]

Just seeing this (I've been out of town) and it looks really, really cool! I'll try to download and start testing this week. One thought (which may have already been addressed): I'd much prefer to track by words instead of pages.

[varia]

As best as can be determined, Reading Ttracker version 1.1.1 works as is, hardcoded, within the parameters it establishes.

For the rest of us with the vast array of Calibre setups, tracking preferences, etc, I have a road map in the works for this overhaul.

Hardcoding appears to be the core reason for inflexibility so the next plugin iteration will attempt some major changes:

Global hardcode
Decoupling hardcode and moving to an event-based model which should eliminate reliance on most if not all custom columns creation, unwanted persistence behaviour, and book selection inflexibility. Theoretically this should seamlessly support tracking of rereads, reading multiple formats of the same books, and similar reading events.

Translations
Establishing parameters needed for expanded translation support such as flexible layout, proper date parsing, etc.

Book inclusion
api.search('#tracked:true') becomes:
Manual → tracker_data["books"].keys()
Search → api.search(search_expression)
All → api.all_book_ids()
Eliminates the need for a custom column to track books, but still uses fast database access protocols.

Dashboard
The intent has always been to show analytics and reading wrap-ups. (Think Storygraph, Hardcover app, etc), charts, graphs, and so on. Ideally the dashboard should be fully modular and user-configurable. This would allow a user to track by words if they preferred instead of pages, ¼ star ratings, etc.

Export
Expanding the current formats (previous plans included use of templates) and multi-year compilations. Improving CSV exports.

Supporting readers who like and want detailed tracking is the goal, keeping flexibility at the forefront.
As I mentioned in the intro, I am not a coder/developer. I have three days left to work on this. Thanks for all the input, suggestions, explanations and requests. Any additions that would further this project is welcomed. Meanwhile, I will do my best.

[JSWolf]

Originally Posted by varia

As best as can be determined, Reading Ttracker version 1.1.1 works as is, hardcoded, within the parameters it establishes.

For the rest of us with the vast array of Calibre setups, tracking preferences, etc, I have a road map in the works for this overhaul.

Hardcoding appears to be the core reason for inflexibility so the next plugin iteration will attempt some major changes:

Global hardcode
Decoupling hardcode and moving to an event-based model which should eliminate reliance on most if not all custom columns creation, unwanted persistence behaviour, and book selection inflexibility. Theoretically this should seamlessly support tracking of rereads, reading multiple formats of the same books, and similar reading events.

Translations
Establishing parameters needed for expanded translation support such as flexible layout, proper date parsing, etc.

Book inclusion
api.search('#tracked:true') becomes:
Manual → tracker_data["books"].keys()
Search → api.search(search_expression)
All → api.all_book_ids()
Eliminates the need for a custom column to track books, but still uses fast database access protocols.

Dashboard
The intent has always been to show analytics and reading wrap-ups. (Think Storygraph, Hardcover app, etc), charts, graphs, and so on. Ideally the dashboard should be fully modular and user-configurable. This would allow a user to track by words if they preferred instead of pages, ¼ star ratings, etc.

Export
Expanding the current formats (previous plans included use of templates) and multi-year compilations. Improving CSV exports.

Supporting readers who like and want detailed tracking is the goal, keeping flexibility at the forefront.
As I mentioned in the intro, I am not a coder/developer. I have three days left to work on this. Thanks for all the input, suggestions, explanations and requests. Any additions that would further this project is welcomed. Meanwhile, I will do my best.

Can you please make the my review, type, and date started columns optional?

[varia]

Originally Posted by JSWolf

Can you please make the my review, type, and date started columns optional?

Yes, that's the goal by removing much of the hardcoding. I can't really say how that will look visually, as far as dashboard stats, for those who prefer not to track certain things. Eg, no date started wouldn't allow for a monthly reads graph. (Unless there is some other coding logic that can be applied there). I'm expecting the modular redesign would prevent "no data" gaps.

[sgmoore]

Originally Posted by varia

Yes, that's the goal by removing much of the hardcoding. I can't really say how that will look visually, as far as dashboard stats, for those who prefer not to track certain things. Eg, no date started wouldn't allow for a monthly reads graph.

If you have a Finish date but no Start date you can still see the monthly reads graph.
When you are viewing a particular year then the status breakdown section does not really provide much detail as the only books shown for a year are the finished books and the number of tracked books is always going to the same as the books finished. But both of these sections would show information when you are displaying data for all years.

If you don't have a custom type column, then that section could be replaced with for example a breakdown of the formats used.

If you allow all columns to be selected in your columns combobox (rather than just custom columns), then you can use the standard ratings column so that section will display correctly.
And if the user is running calibre 9, then the standard pages column can be used rather than requiring a custom column.

[varia]

Originally Posted by sgmoore

If you have a Finish date but no Start date you can still see the monthly reads graph.

Seeing, yes, but without a start date, books couldn't be assigned to a specific month and the graph would be empty. Unless you mean there is another way to populate monthly read without a start date ?

Originally Posted by sgmoore

When you are viewing a particular year then the status breakdown section does not really provide much detail as the only books shown for a year are the finished books and the number of tracked books is always going to the same as the books finished. But both of these sections would show information when you are displaying data for all years.

In the original version the tracked and finished books aren't the same. Click the KPI cards to see the search string in Calibre. The status breakdown shows Finished, Reading, TBR, Paused, and DNF, if those statuses are assigned to any of your books. Unless all tracked books were labeled finished, then yes, that is the only detail you would see in the status breakdown pie chart.

Originally Posted by sgmoore

If you allow all columns to be selected in your columns combobox (rather than just custom columns), then you can use the standard ratings column so that section will display correctly.
And if the user is running calibre 9, then the standard pages column can be used rather than requiring a custom column.

(Rating was separated, because some users rate separately from their downloaded metadata rating and want to see the difference).

The standard columns that do not reflect on the Dashboard and can possibly be aggregated into specific charts:
Series
Rating*
Date (added to Calibre)
Published
Publisher
Language
File Format
Which would you be interested in seeing analytics as a reader?

Originally Posted by sgmoore

If you don't have a custom type column, then that section could be replaced with for example a breakdown of the formats used.

Formats, meaning book format? (ie, Epub, pdf, etc)


As mentioned previously version 2 is focused on a more flexible way of tracking books, with less reliance on hard coded custom columns. After that it would be a matter of determining which statistics show on the dashboard, other than what is already there.

[sgmoore]

Originally Posted by varia

Seeing, yes, but without a start date, books couldn't be assigned to a specific month and the graph would be empty. Unless you mean there is another way to populate monthly read without a start date ?

Taking a quick look at the current code, the MonthlyBarChart is based on the month of the finish date and doesn't use the start date.

The number of books tracked does include books started in a year, but it only counts pages, types, authors, genre and ratings if the book is finished/complete or completed and the finish year matches. (I'm not saying that is wrong as that is probably the way I would want it to work even if I had a start date).

Originally Posted by varia

The standard columns that do not reflect on the Dashboard and can possibly be aggregated into specific charts:

Which would you be interested in seeing analytics as a reader?

Do you need to know which fields would be used? What I mean is - do you need to do anything special to support displaying any string column on the dashboard?

For example, you currently have a type column which is restricted to three pre-defined types. It is fairly trivial to change this to build the dictionary based on the actual values and then display the top 10 values.

Having done that, if I point 'type' to any column, like 'author', 'series', 'format', 'Publisher' or Language it will display a graph of that usage.

The only difficult part would be that the name/title would have to be changed, rather than being hardcoded to say 'type breakdown' but from other messages that appears to something others non-english users are looking for.

I understand it may take more work with date columns, but I'm not sure how people would want that to work.

[varia]

Originally Posted by sgmoore

Do you need to know which fields would be used? What I mean is - do you need to do anything special to support displaying any string column on the dashboard?

For example, you currently have a type column which is restricted to three pre-defined types. It is fairly trivial to change this to build the dictionary based on the actual values and then display the top 10 values.

Theoretically I think it is doable; the main challenge there would be striking a balance between flexible stats and a cohesive graphical layout. There is always the question, do people want to see a single snapshot of highlights and charts with minimal scrolling, or do they want expanded options to see "top 10 genres", "top 5 authors", etc. Then how that would be integrated and exported in the wrap-up is another consideration. With time, I'm sure anything can be figured out.

[JSWolf]

Originally Posted by varia

Theoretically I think it is doable; the main challenge there would be striking a balance between flexible stats and a cohesive graphical layout. There is always the question, do people want to see a single snapshot of highlights and charts with minimal scrolling, or do they want expanded options to see "top 10 genres", "top 5 authors", etc. Then how that would be integrated and exported in the wrap-up is another consideration. With time, I'm sure anything can be figured out.

Are the books being tracked kept in a json file?