View Single Post
Old 07-09-2022, 05:01 PM   #4
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,471
Karma: 8025600
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by thiago.eec View Post
Aren't translators supposed not to translate such strings?
I don't understand. Translators won't see strings in user-defined templates, so there is no opportunity to make the choice.

Templates operate on displayed (formatted) values. For something like a Yes/No column, calibre displays the translated value for the column. You probably would see the same for "Unknown" in authors & titles. That is one reason the check_yes_no() function was added -- to remove dependency on displayed values for yes/no columns in a template. But your question did remind me of another workaround. The template could use raw_field() to get an untranslated value ('true', 'false', 'none'), as in
Code:
{:'switch($$#read, 'true', 'Gelesen', 'false', 'Nicht Gelesen', 'Nicht Gelesen')'}
You might see similar problems with localized dates. If the date display format contains string days or months then the template will see them translated. If one is not careful then the locale order can also be a problem, where the template must know about mm/dd and dd/mm. The template writer can work around this by formatting the raw value and checking that.
chaley is offline   Reply With Quote