View Single Post
Old 09-26-2011, 12:23 PM   #15
chaley
"chaley", not "charley"
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: 5,520
Karma: 855450
Join Date: Jan 2010
Location: France
Device: Many android devices
Quote:
Originally Posted by arspr View Post
Although, in order to prevent further work I would code (if easy):

Code:
list_equal(list1, list2, ','(for list1), ','(for list2), yes_value, no_value).
In this way you would have a fully robust comparison function fully independent from the separator.
That is what I was thinking. I don't want to introduce parameters that have no purpose, but your argument below solves that.
Quote:

Just one doubt. How will it behave with "Greek, Modern (1453-)"?
I feel that you have one serious inconsistency here. If languages_string gives the values separated with commas, commas shouldn't be used within the names.
This is well-and-truly a problem. Not only will the proposed list_equal not work -- none of the current list functions work either.

My opinion is that the language names should not have commas in them. I would instead use semicolons. Unfortunately the language names come from elsewhere, and we have no control over them. For example, the German translation uses semicolons where all the other languages use commas!

I am not sure what to do. One possibility to add an argument (or change the current second argument) to language_strings, telling it to convert commas to semicolons. This will make the comma separator work correctly, but will have the side effect of making the results of language_string be different from that shown in the language column. Your 'system' would work only if you used semicolons instead of commas in your #original_language field. I would also need to make the language_codes function accept either style.

Another solution would be to preprocess the language code tables to convert all commas to semicolons. My guess is that Kovid would not be in favor of this approach, but I haven't asked him.

It might be that the right solution is the one that I don't want to do: a custom column that knows the contents are language codes. My problem is that creating a new column type has *many* ramifications throughout calibre, with a high probability that I will seriously break something.

More thought is required.
chaley is offline   Reply With Quote