|
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,
|