MobileRead Forums - View Single Post - Reflections about how "translatable" Calibre is

arspr · 09-19-2014, 05:51 PM

Hi, guys, sorry because this post is going to be quite long... But I really think it's necessary. Even if you just read the very first lines I really thank you nevertheless.

I want to start this thread just to arise future thinking about a possible weakness Calibre has. Calibre in theory is an English software but in theory is "easily" translated to any other language. And this is in general quite true, but recent experiences have shown me that when you work with custom columns, the aforementioned statement starts to fail... And specially it really, really fails if you intend to switch the GUI language while working on the very same library...

Sure, that is not a common situation at all and maybe fixing it is not worth the effort. Maybe it would suppose a complete overhaul of the code or whatever, (I'm in no way a code expert), and some of the "bugs/feature requests" I've opened in launchpad have been dismissed or have received alternate solutions (which are somehow "hackish" sometimes).

I don't intend to demand for better solutions, (no user of this GREAT software has that right when the software is just donation-ware) but I think that you, Kovid, and your team of coders should spend a little of time giving a second thought on this "problem" from a general point of view rather than thinking on specific issues. Maybe at the end you just decide that Calibre is perfect as it is, or that you will continue putting partial patches in the critical issues that might arise, or that even if there could be much better solutions, you just don't have enough time/energies to spend on it. Whatever you decide is just great but please just be fully conscious that in this specific area of custom columns, when they are complex, Calibre is just an English software in a multi-language "disguise".

I insist, no personal problem at all, if you decide that this is the way Calibre is going to be because of whatever reasons, it's just perfect.

After this long introduction I'm going to post some of the examples I've found. Possibly some of them are just plain misuse of Calibre's features because of my own ignorance. But it's also really feasible that these are not the only issues Calibre might have... So I think that reading them as a whole, (rather than as individual issues), they can be a good description of the general situation.

Custom columns names cannot be automatically translated I mean when you change from English to Spanish, "Author(s)" and "Language(s)" automatically change into "Autor(es)" and "Idiomas", but that's not possible with my custom columns names. In fact you have to manually change the custom column name. There's no "table", "list" or similar place where you could put the Custom Column name in any of the possible languages.

Custom template functions help cannot be translated The very same situation.

Some troubles with yes/no columns when they are calculated
Official Yes/No-type columns work really fine but in one issue which is not language related: they cannot be selected to appear in the Tag Browser.

But there's a really useful trick: copying them into an auxiliary extra column ({#my_original_yes_no_column}) which can be shown in Tag Browser.

And then, specially after this patch, you can say that they work in any language. Their "Yes/No" values are transparently translated into "Sí/No", "Oui/Non" or whatever in either the table view (I mean, #my_original_yes_no_column) and in Tag Browser (through its copied column).

But the real problem arises when you calculate a custom column through whichever chain of functions which gives a "Yes/No" result. What do you do in that case?:

If you hardcode "Yes" and "No" as the possible result values (or "Sí/No" or "Oui/Non" depending on your primary used language), it perfectly works within that original language. You get the green tick / red cross and that column is virtually undistinguishable from a built-in Yes/No-type.
But if you change the GUI language, then it doesn't work anymore because, in Spanish or French, "Yes/No" have no meaning as key-words.
Instead of this way, you could hardcode "True"/"False" which are actually the real key-words inside a Yes/No column.
Ok, if you do this, then the Calibre table view works perfectly, (you get the correct icons), no matter what language you select in the GUI. But then the Tag Browser is somehow weird, because the native yes/no columns would say "Sí/No" (or whatever other words in each particular language) and the calculated pseudo-yes/no columns would say "True/False". It just doesn't look fine.

Possible solution, but rejected in this bug ticket: implementing yes_in_GUI_language() and no_in_GUI_language() template functions...

Problems with languages-like column
Well, the problem here is that there aren't language-type custom columns... Languages is a tricky kind of column because it actually stores language codes (Spanish is "spa", English is "eng", ...), but it shows the readable and conventional name of that language in the GUI selected language. So spa appears as "Spanish", "Español", "Espagnol", ... based on GUI language.

But then, I do have an extra pseudo-language-like custom column: #original_language of the ebook. As you can imagine, I've just selected a Tag-Like custom column which actually contains the conventional name of that original language...

Problems:

When I switch to other GUI language, languages is automatically updated but #original_language is not. And it looks weird.
Comparisons between languages and #original_language are really, really tricky. (I make this comparison to detect and classify which books are translations and which ones aren't).
You have to use the language_codes() and language_strings() functions which have very limited GUI language support. In my particular library case, they work because I've filled #original_language in English. But imagine that I had set it as #langue_originale (I mean in French) and I had set the GUI language to Spanish... It's just impossible to make comparisons between languages and #langue_originale in that case...

Possible best solution (but partially rejected quite long ago):

Enable TRUE language-type custom columns, and
Add full arbitrary language support, (through an extra argument), to language_code() and language_strings() functions, and
Add a "mask as language" option on calculated custom columns. In this way this kind of column containing language codes, (the result of whichever calculations), would be shown as their human readable names in the GUI language.

Additional translation values for Tags and Tag-like custom columns
I mean if I set Tag as "Novel", "Thriller", "Fantasy" or whatever, maybe I would like getting "Novela", "Suspense", "Fantástico"... in Spanish. But it is not possible.

And of course it's the same with tag-like columns. I have an #edit_tweaks_made_by_me_on_the_ebook column where I have introduced "Justify text", "Typos", "Remove page margins"... which I would like to see as "Justificar texto", "Erratas", "Eliminar márgenes de página"... in Spanish.

09-19-2014, 05:51 PM	#1
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	Reflections about how "translatable" Calibre is - Custom columns. Hi, guys, sorry because this post is going to be quite long... But I really think it's necessary. Even if you just read the very first lines I really thank you nevertheless. I want to start this thread just to arise future thinking about a possible weakness Calibre has. Calibre in theory is an English software but in theory is "easily" translated to any other language. And this is in general quite true, but recent experiences have shown me that when you work with custom columns, the aforementioned statement starts to fail... And specially it really, really fails if you intend to switch the GUI language while working on the very same library... Sure, that is not a common situation at all and maybe fixing it is not worth the effort. Maybe it would suppose a complete overhaul of the code or whatever, (I'm in no way a code expert), and some of the "bugs/feature requests" I've opened in launchpad have been dismissed or have received alternate solutions (which are somehow "hackish" sometimes). I don't intend to demand for better solutions, (no user of this GREAT software has that right when the software is just donation-ware) but I think that you, Kovid, and your team of coders should spend a little of time giving a second thought on this "problem" from a general point of view rather than thinking on specific issues. Maybe at the end you just decide that Calibre is perfect as it is, or that you will continue putting partial patches in the critical issues that might arise, or that even if there could be much better solutions, you just don't have enough time/energies to spend on it. Whatever you decide is just great but please just be fully conscious that in this specific area of custom columns, when they are complex, Calibre is just an English software in a multi-language "disguise". I insist, no personal problem at all, if you decide that this is the way Calibre is going to be because of whatever reasons, it's just perfect. After this long introduction I'm going to post some of the examples I've found. Possibly some of them are just plain misuse of Calibre's features because of my own ignorance. But it's also really feasible that these are not the only issues Calibre might have... So I think that reading them as a whole, (rather than as individual issues), they can be a good description of the general situation. Custom columns names cannot be automatically translated I mean when you change from English to Spanish, "Author(s)" and "Language(s)" automatically change into "Autor(es)" and "Idiomas", but that's not possible with my custom columns names. In fact you have to manually change the custom column name. There's no "table", "list" or similar place where you could put the Custom Column name in any of the possible languages. Custom template functions help cannot be translated The very same situation. Some troubles with yes/no columns when they are calculated Official Yes/No-type columns work really fine but in one issue which is not language related: they cannot be selected to appear in the Tag Browser. But there's a really useful trick: copying them into an auxiliary extra column ({#my_original_yes_no_column}) which can be shown in Tag Browser. And then, specially after this patch, you can say that they work in any language. Their "Yes/No" values are transparently translated into "Sí/No", "Oui/Non" or whatever in either the table view (I mean, #my_original_yes_no_column) and in Tag Browser (through its copied column). But the real problem arises when you calculate a custom column through whichever chain of functions which gives a "Yes/No" result. What do you do in that case?: If you hardcode "Yes" and "No" as the possible result values (or "Sí/No" or "Oui/Non" depending on your primary used language), it perfectly works within that original language. You get the green tick / red cross and that column is virtually undistinguishable from a built-in Yes/No-type. But if you change the GUI language, then it doesn't work anymore because, in Spanish or French, "Yes/No" have no meaning as key-words. Instead of this way, you could hardcode "True"/"False" which are actually the real key-words inside a Yes/No column. Ok, if you do this, then the Calibre table view works perfectly, (you get the correct icons), no matter what language you select in the GUI. But then the Tag Browser is somehow weird, because the native yes/no columns would say "Sí/No" (or whatever other words in each particular language) and the calculated pseudo-yes/no columns would say "True/False". It just doesn't look fine. Possible solution, but rejected in this bug ticket: implementing yes_in_GUI_language() and no_in_GUI_language() template functions... Problems with languages-like column Well, the problem here is that there aren't language-type custom columns... Languages is a tricky kind of column because it actually stores language codes (Spanish is "spa", English is "eng", ...), but it shows the readable and conventional name of that language in the GUI selected language. So spa appears as "Spanish", "Español", "Espagnol", ... based on GUI language. But then, I do have an extra pseudo-language-like custom column: #original_language of the ebook. As you can imagine, I've just selected a Tag-Like custom column which actually contains the conventional name of that original language... Problems: When I switch to other GUI language, languages is automatically updated but #original_language is not. And it looks weird. Comparisons between languages and #original_language are really, really tricky. (I make this comparison to detect and classify which books are translations and which ones aren't). You have to use the language_codes() and language_strings() functions which have very limited GUI language support. In my particular library case, they work because I've filled #original_language in English. But imagine that I had set it as #langue_originale (I mean in French) and I had set the GUI language to Spanish... It's just impossible to make comparisons between languages and #langue_originale in that case... Possible best solution (but partially rejected quite long ago): Enable TRUE language-type custom columns, and Add full arbitrary language support, (through an extra argument), to language_code() and language_strings() functions, and Add a "mask as language" option on calculated custom columns. In this way this kind of column containing language codes, (the result of whichever calculations), would be shown as their human readable names in the GUI language. Additional translation values for Tags and Tag-like custom columns I mean if I set Tag as "Novel", "Thriller", "Fantasy" or whatever, maybe I would like getting "Novela", "Suspense", "Fantástico"... in Spanish. But it is not possible. And of course it's the same with tag-like columns. I have an #edit_tweaks_made_by_me_on_the_ebook column where I have introduced "Justify text", "Typos", "Remove page margins"... which I would like to see as "Justificar texto", "Erratas", "Eliminar márgenes de página"... in Spanish. Last edited by arspr; 09-19-2014 at 05:55 PM.