Closed Mandabar closed 7 months ago
I acknowledge that's a typo.
But by my understanding of transifex.com, fixing it will invalidate the 11 existing translations into other languages for that string. I'm not sure it's worth fixing in that case.
It's just a minor typo, and at least it's the right sound so it's easy enough to understand what it's supposed to be. And it's rarely even seen, I've been using this plugin for forever and I can't remember seeing it before. Though realistically I should have and probably just glazed over it.
If you say it's going to break the translations then, it's your decision, but I just leave it as is then I guess. I didn't even think of the translations but I would have thought it would have just left them incorrect not broken. Oh well, tried to help!
The translation system uses the original English string as the key into the translated files. Example.
If I had taken the time to give each string a unique key and make a separate English translation file, we probably wouldn't have this problem. But there's 500+ strings and I couldn't be bothered to retrofit all that.
I don't know if I even could now. Just adding a en.mo
file doesn't override the coded value.
Interesting to know, thanks! Yeah it's going to probably have to stay that way then. Almost sounds like those horror stories of code where you change one thing and 40 other things break.
Thanks for the thought taken into this. 👍
(Should I be hitting to close button as the opener, or you as the dev?)
For future reference: The reason a en.mo
file doesn't work is because of a Calibre optimization to explicitly assume English is the coded language and never needs translation.
From: https://github.com/kovidgoyal/calibre/blob/v6.29.0/src/calibre/customize/zipplugin.py#L118
from calibre.utils.localization import get_lang
lang = get_lang()
if not lang or lang == 'en': # performance optimization
_translations_cache[zfp] = None
return
Which would also prevent explicit unique string keys, so at least I don't feel bad about not going that anymore.
Knowing this, I could provide my own implementation of load_translations()
or otherwise work around it and then correct English language strings in a en.mo
.
But IMO, it's inevitable that I (or someone else) would eventually try to change some previously 'corrected' string in code and be baffled for hours why it doesn't work, not remembering (or never knowing) about the en.po/mo
override.
So I am closing this, but at least it's documented. I also added a comment in the code by the typo.
On a failure to update an Anthology (Ctrl+U), I got this pop-up dialog box with a minor typo. v4.29.0
No good stories/updates where downloaded, Anthology creating/update aborted.
Should be
Thanks, Jim for your work and amazing plugin! <3