Wishlist: book data, catalog editing and searching
Talk Recommend Site Improvements
Join LibraryThing to post.
This topic is currently marked as "dormant"—the last message is more than 90 days old. You can revive it by posting a reply.
1circeus
-Treat secondary authors as authors or find a better way to accomodate multiple authors
I have a handful of books with secondary authors (anthologies, mostly), but you'd never know I own Sloan Wilson's Ice Brothers (in Sélection Du Livre1983) or material by Patricia Highsmith and Régine Deforges (in Histoires à Lire : Huit Nouvelles, listed under Mary Higgins Clark, because I don't have enough room to add Jean-Louis Berger-Bordes, who wrote the intro)
-Allow work renaming
This solves several issues: (1) It can be impossible to fix a mistyped work title even if you change the title of the book and are the only owner (e.g. the missing space in Sélection Du Livre1983) (2) It would allow for the original language title to be used even though all the books on LT are translations. (3) It could solve the problem caused by automatic combinations based on title and author without forcing the book owner to rename their book (by allowing the format to be integrated in the work title separating that name from the individual book titles): My Mafalda (Succès du Livre) is a best-of selection of strips distinct from the various Mafalda, but I have to change my title to avoid combination.
-Add a "secondary original language" field
If a book was original a twin publication in English and french, I have to list it as Primary: French, Secondary: English, Original: Multiple... Similarly, anthology of translated and untranslated are Primary: French, Original: Multiple languages or English, neither of which is really satisfying. Offering plural form by families for original languages ("Indo-european (multiple)") would be an interesting alternative option.
-Add an ISSN field
For serial publications, not all of which are magazines or journals: I have at least 8 or nine books from collections ISBN. Dupuis and Dargault Editions use ISSNs for ongoing graphic novel series and my Héraldique (what is going on with the touchstones there??) is part of a collection with an ISSN too. This could be of great usefulness when collection functions come around.
-Make "all field" research actually work
Attempts at research with that option that cause book indexing systematically return an error: "Can't find FULLTEXT index matching the column list - fatal error (2)".Most normal searches also cause errors.
-Integrate search in any specific field in the search function
I'd love to be able to search only the "author" field from my catalog, but right now I have to use the "all field" one, and we know how well that work... This could be simply implemented via an "show all fields"option similar to the "all pages" option for large catalogs.
-Improve the search function
You cannot make partial searches ("741.5*" for my comic books), multiple string searches ("science fiction, perry rhodan" tag search will not return anything in my catalog), or use boolean operators ("science fiction NOT space opera")
-Add a "replace tag" function
This should be easy enough: just combine the "add" and "remove tags" function the way the three language fields already are.
-When dislaying fields entered with line breaks, display the line breaks.
Multiple line publication data, for example, gets strung in a single line that can be very confusing. I don't know if it does the same to summaries and comments, though.
I have a handful of books with secondary authors (anthologies, mostly), but you'd never know I own Sloan Wilson's Ice Brothers (in Sélection Du Livre1983) or material by Patricia Highsmith and Régine Deforges (in Histoires à Lire : Huit Nouvelles, listed under Mary Higgins Clark, because I don't have enough room to add Jean-Louis Berger-Bordes, who wrote the intro)
-Allow work renaming
This solves several issues: (1) It can be impossible to fix a mistyped work title even if you change the title of the book and are the only owner (e.g. the missing space in Sélection Du Livre1983) (2) It would allow for the original language title to be used even though all the books on LT are translations. (3) It could solve the problem caused by automatic combinations based on title and author without forcing the book owner to rename their book (by allowing the format to be integrated in the work title separating that name from the individual book titles): My Mafalda (Succès du Livre) is a best-of selection of strips distinct from the various Mafalda, but I have to change my title to avoid combination.
-Add a "secondary original language" field
If a book was original a twin publication in English and french, I have to list it as Primary: French, Secondary: English, Original: Multiple... Similarly, anthology of translated and untranslated are Primary: French, Original: Multiple languages or English, neither of which is really satisfying. Offering plural form by families for original languages ("Indo-european (multiple)") would be an interesting alternative option.
-Add an ISSN field
For serial publications, not all of which are magazines or journals: I have at least 8 or nine books from collections ISBN. Dupuis and Dargault Editions use ISSNs for ongoing graphic novel series and my Héraldique (what is going on with the touchstones there??) is part of a collection with an ISSN too. This could be of great usefulness when collection functions come around.
-Make "all field" research actually work
Attempts at research with that option that cause book indexing systematically return an error: "Can't find FULLTEXT index matching the column list - fatal error (2)".Most normal searches also cause errors.
-Integrate search in any specific field in the search function
I'd love to be able to search only the "author" field from my catalog, but right now I have to use the "all field" one, and we know how well that work... This could be simply implemented via an "show all fields"option similar to the "all pages" option for large catalogs.
-Improve the search function
You cannot make partial searches ("741.5*" for my comic books), multiple string searches ("science fiction, perry rhodan" tag search will not return anything in my catalog), or use boolean operators ("science fiction NOT space opera")
-Add a "replace tag" function
This should be easy enough: just combine the "add" and "remove tags" function the way the three language fields already are.
-When dislaying fields entered with line breaks, display the line breaks.
Multiple line publication data, for example, gets strung in a single line that can be very confusing. I don't know if it does the same to summaries and comments, though.
2timspalding
Hey, one request per customer! Back of the line wi... oh, okay, here's my thoughts.
-Treat secondary authors as authors or find a better way to accomodate multiple authors
Yes. We're going to change how authors work. It's a very big change, but it's going to happen in the next month or so.
-Allow work renaming
Tell me what you think when I get the new work-scheme up. The primary benefit will be do have a "title" for a work in all langauges (ie., the language's title, or fail to English).
-Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
-Add an ISSN field
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
-Make "all field" research actually work
Okay. I know there are problems.
-Integrate search in any specific field in the search function
Maybe. Not a high-priority. The all-fields things is supposed to solve that problem without requiring searches on every field. Basically, it dumps all the fields into another table, record-by-record. Doing field-by-field searches on 6.4 million records is no fun, let me tell you.
-Improve the search function
Yes.
-Add a "replace tag" function
Okay. Not as high a priority because there's a work-around. But I intend to revamp the "tag" page to allow manipulation of tags THERE. That might be the best place to put it.
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
-Treat secondary authors as authors or find a better way to accomodate multiple authors
Yes. We're going to change how authors work. It's a very big change, but it's going to happen in the next month or so.
-Allow work renaming
Tell me what you think when I get the new work-scheme up. The primary benefit will be do have a "title" for a work in all langauges (ie., the language's title, or fail to English).
-Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
-Add an ISSN field
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
-Make "all field" research actually work
Okay. I know there are problems.
-Integrate search in any specific field in the search function
Maybe. Not a high-priority. The all-fields things is supposed to solve that problem without requiring searches on every field. Basically, it dumps all the fields into another table, record-by-record. Doing field-by-field searches on 6.4 million records is no fun, let me tell you.
-Improve the search function
Yes.
-Add a "replace tag" function
Okay. Not as high a priority because there's a work-around. But I intend to revamp the "tag" page to allow manipulation of tags THERE. That might be the best place to put it.
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
3boekerij
>2 timspalding:
One comment pro item, was it? Okay, here's my thoughts added.
1.
-Treat secondary authors as authors or find a better way to accomodate multiple authors
Yes. We're going to change how authors work. It's a very big change, but it's going to happen in the next month or so.
Thumbs up. Does this mean a "add as many more secondary author fields as you need" function, too?
2.
-Allow work renaming
Tell me what you think when I get the new work-scheme up. The primary benefit will be do have a "title" for a work in all langauges (ie., the language's title, or fail to English).
I don't get this.
I thought LibraryThing was supposed to go international and multilingual--i.e.: NOT the language's title, or fail to English.
Of course, this was a lapsus of yours, for what you meant was, with no doubt (or so I hope) :
i.e.: the language's title (subtitled with the original title in its original language or vice versa) or fail to original.
3.
-Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
That's because MARC is strongly US and English language oriented. Most people in the world or no Americans, nor do they speak neither understand any English. Imagine, the latter counts for polyglots too!
Over here, in the Low Countries, it is not uncommon that the original edition of a book is a composition appearing in some different languages.
Take e.g. De Vlaamse en Europese uitdaging : Vlaming zijn nu. The latter book is a coverage of an academic conference on, as the title says, (transl.) "The Flemish and European Challenge : Being Flemish Today", and is holding contributions by 27 different authors from all over Europe, contributing in Dutch, French, German and English respectively. At ours, educated people are supposed to understand all of those (and then some more, too).
Thus, the language(s) as well as the original language(s) of the latter work is (are) : nl + fr + de + en. Foreign editions of such work might have the number of languages reduced--for people wanting to read and understand the original are to know those four languages at least--but then again, the original is quadrilingual indeed. In our view, this is not strange--on the contrary. YMMV.
IIRC, even the original of the Max Havelaar--a very well known in Dutch (a translation into English is available, too) is containing at its first page a letter of dedication in French. Thus, in fact, the original in full is in nl + fr.
But of course, all of you do know a major example by yourself, too, don't you? Have e.g. The Holy Bible.
4.
-Add an ISSN field
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
But there is far more than just magazines in this!
Some books have an ISBN as well as an ISSN, for they are serials indeed. Take e.g. almanacs, (encyclopedic) yearbooks, etc., or other series/serials. They might have an ISBN, but some of them have an ISSN only. These are no magazines at all, but, though they are books in every common sense, serials indeed.
4bis - Talking ISBN
4bis.1 - ISBN-13 vs. ISBN-10
As we all known, ISBN as we know it (ISBN-10, that is), is going to be obsoleted by ISBN-13 (EAN type, Bookland prefix 978) soon AND a new Bookland prefix (979) is to be added soon, too.
There are and will be conversion possibilities between ISBN-10 and ISBN-13 and vice versa--i.e. reverse conversion--provided the latter (ISBN-13) is prefixed 978, for the New Bookland EAN 979 prefix ISBN cannot be converted to ISBN-10.
It might be a very good idea for LibraryThing to provide separate room--i.e. a separate field--for ISBN-10 as well as for ISBN-13, have the one next to the other, AND to autoconvert the former to the latter and vice versa (if possible). Without this (auto)converting, search and retrieve might become rather frustrating, for not all catalogus will have or know both.
Entering books now, I have both--i.e. ISBN-10 as well as ISBN-13--at hands. Witch of both should I pick to enter at LT? The one that will be obsolete soon, or the new one? Most contributing libraries provide the former only, for their catalogs have that one only.
Best tip for LT : have both, and whenever possible--i.e. except for New Bookland EAN 979 ISBN-13--if having the one, autocalculate the other, too.
4bis.2 - More ISBN Misery
Not only do some books have ISBN-10 AND/OR ISBN-13--at present, having one of those, one can calculate the other, too--AND/OR ISSN. Of course, there is worse.
Some books are co-publicated, providing them with a double ISBN--i.e. each and every copy of them is matching with an ISBN of each of its co-publishers.
Have e.g. : Hoe overleven we de vrijheid? : Modernisme, postmodernisme en het mystiek lichaam (link) by Herman De Dijn.
This book is a co-publication by Uitgeverij Pelckmans, Kapellen (B) and Uitgeverij KOK Agora, Kampen (NL), (thus) it has a double ISBN, i.e. :
ISBN 90-289-1820-5 == ISBN 90-391-0569-3
ISBN 90-289-1820-5 (Pelckmans)
ISBN 90-391-0569-3 (Kok Agora).
This is one and the same copy of one and the same book indeed. Which ISBN to pick for LT purposes?
And of course, ISBN 9789028918207 AND ISBN 9789039105696 are valid ISBN's for this same copy, too. That makes four of them indeed. For one single copy of one single book. Have fun!
I think that 4bis.1 might deserve some major attention, for time is running, and this will NOT go away, while having it rottening prepares for disaster.
5.
-Make "all field" research actually work
Okay. I know there are problems.
Confirmation. Have this fixed before you bar "beta". =)
6.
-Integrate search in any specific field in the search function
Maybe. Not a high-priority. The all-fields things is supposed to solve that problem without requiring searches on every field. Basically, it dumps all the fields into another table, record-by-record. Doing field-by-field searches on 6.4 million records is no fun, let me tell you.
Ehm, and LT is not to stick with (update) approx. 6.5 books, will it? When exactly was it LT got its 5,000,000 books catalogued party. IIRC, it was last month. The increasement rate is not exactly slowing down, is it?
7.
-Improve the search function
Yes.
8.
-Add a "replace tag" function
Okay. Not as high a priority because there's a work-around. But I intend to revamp the "tag" page to allow manipulation of tags THERE. That might be the best place to put it.
9.
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
That might be enough. For now, that is.
<bonus>
Yesterday night, I met an acquaintance of mine, which I had shown a quick glance at LibraryThing last time I met him. Tonight, after his obviously having had a closer look at it, he seemed rather enthousiastic. He had great news. "You know", he told me, "You know that that LibraryThing you told me about last week, is available in i.a. German and Dutch too?!" Yes, I knew (of course!), but still it was great news indeed. The rumours are spreading, and so is enthousiasm, too. You are doing a great job, Tim & Co. You knew this already, of course, but then again, once in a while, we have to confirm this in an explicit way--because we are so selfish, and thus want to give you a boost! =)
Note to our fine translators into German : Though my acquaintance is German--he is in his fourties and has 10,000+ books--, I had to explain to him what the Fremdwort "tag" meant. The latter was not too difficult, for one single translation (into German) did the job : "Stichwort".
</bonus>
One comment pro item, was it? Okay, here's my thoughts added.
1.
-Treat secondary authors as authors or find a better way to accomodate multiple authors
Yes. We're going to change how authors work. It's a very big change, but it's going to happen in the next month or so.
Thumbs up. Does this mean a "add as many more secondary author fields as you need" function, too?
2.
-Allow work renaming
Tell me what you think when I get the new work-scheme up. The primary benefit will be do have a "title" for a work in all langauges (ie., the language's title, or fail to English).
I don't get this.
I thought LibraryThing was supposed to go international and multilingual--i.e.: NOT the language's title, or fail to English.
Of course, this was a lapsus of yours, for what you meant was, with no doubt (or so I hope) :
i.e.: the language's title (subtitled with the original title in its original language or vice versa) or fail to original.
3.
-Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
That's because MARC is strongly US and English language oriented. Most people in the world or no Americans, nor do they speak neither understand any English. Imagine, the latter counts for polyglots too!
Over here, in the Low Countries, it is not uncommon that the original edition of a book is a composition appearing in some different languages.
Take e.g. De Vlaamse en Europese uitdaging : Vlaming zijn nu. The latter book is a coverage of an academic conference on, as the title says, (transl.) "The Flemish and European Challenge : Being Flemish Today", and is holding contributions by 27 different authors from all over Europe, contributing in Dutch, French, German and English respectively. At ours, educated people are supposed to understand all of those (and then some more, too).
Thus, the language(s) as well as the original language(s) of the latter work is (are) : nl + fr + de + en. Foreign editions of such work might have the number of languages reduced--for people wanting to read and understand the original are to know those four languages at least--but then again, the original is quadrilingual indeed. In our view, this is not strange--on the contrary. YMMV.
IIRC, even the original of the Max Havelaar--a very well known in Dutch (a translation into English is available, too) is containing at its first page a letter of dedication in French. Thus, in fact, the original in full is in nl + fr.
But of course, all of you do know a major example by yourself, too, don't you? Have e.g. The Holy Bible.
4.
-Add an ISSN field
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
But there is far more than just magazines in this!
Some books have an ISBN as well as an ISSN, for they are serials indeed. Take e.g. almanacs, (encyclopedic) yearbooks, etc., or other series/serials. They might have an ISBN, but some of them have an ISSN only. These are no magazines at all, but, though they are books in every common sense, serials indeed.
4bis - Talking ISBN
4bis.1 - ISBN-13 vs. ISBN-10
As we all known, ISBN as we know it (ISBN-10, that is), is going to be obsoleted by ISBN-13 (EAN type, Bookland prefix 978) soon AND a new Bookland prefix (979) is to be added soon, too.
There are and will be conversion possibilities between ISBN-10 and ISBN-13 and vice versa--i.e. reverse conversion--provided the latter (ISBN-13) is prefixed 978, for the New Bookland EAN 979 prefix ISBN cannot be converted to ISBN-10.
It might be a very good idea for LibraryThing to provide separate room--i.e. a separate field--for ISBN-10 as well as for ISBN-13, have the one next to the other, AND to autoconvert the former to the latter and vice versa (if possible). Without this (auto)converting, search and retrieve might become rather frustrating, for not all catalogus will have or know both.
Entering books now, I have both--i.e. ISBN-10 as well as ISBN-13--at hands. Witch of both should I pick to enter at LT? The one that will be obsolete soon, or the new one? Most contributing libraries provide the former only, for their catalogs have that one only.
Best tip for LT : have both, and whenever possible--i.e. except for New Bookland EAN 979 ISBN-13--if having the one, autocalculate the other, too.
4bis.2 - More ISBN Misery
Not only do some books have ISBN-10 AND/OR ISBN-13--at present, having one of those, one can calculate the other, too--AND/OR ISSN. Of course, there is worse.
Some books are co-publicated, providing them with a double ISBN--i.e. each and every copy of them is matching with an ISBN of each of its co-publishers.
Have e.g. : Hoe overleven we de vrijheid? : Modernisme, postmodernisme en het mystiek lichaam (link) by Herman De Dijn.
This book is a co-publication by Uitgeverij Pelckmans, Kapellen (B) and Uitgeverij KOK Agora, Kampen (NL), (thus) it has a double ISBN, i.e. :
ISBN 90-289-1820-5 == ISBN 90-391-0569-3
ISBN 90-289-1820-5 (Pelckmans)
ISBN 90-391-0569-3 (Kok Agora).
This is one and the same copy of one and the same book indeed. Which ISBN to pick for LT purposes?
And of course, ISBN 9789028918207 AND ISBN 9789039105696 are valid ISBN's for this same copy, too. That makes four of them indeed. For one single copy of one single book. Have fun!
I think that 4bis.1 might deserve some major attention, for time is running, and this will NOT go away, while having it rottening prepares for disaster.
5.
-Make "all field" research actually work
Okay. I know there are problems.
Confirmation. Have this fixed before you bar "beta". =)
6.
-Integrate search in any specific field in the search function
Maybe. Not a high-priority. The all-fields things is supposed to solve that problem without requiring searches on every field. Basically, it dumps all the fields into another table, record-by-record. Doing field-by-field searches on 6.4 million records is no fun, let me tell you.
Ehm, and LT is not to stick with (update) approx. 6.5 books, will it? When exactly was it LT got its 5,000,000 books catalogued party. IIRC, it was last month. The increasement rate is not exactly slowing down, is it?
7.
-Improve the search function
Yes.
8.
-Add a "replace tag" function
Okay. Not as high a priority because there's a work-around. But I intend to revamp the "tag" page to allow manipulation of tags THERE. That might be the best place to put it.
9.
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
That might be enough. For now, that is.
<bonus>
Yesterday night, I met an acquaintance of mine, which I had shown a quick glance at LibraryThing last time I met him. Tonight, after his obviously having had a closer look at it, he seemed rather enthousiastic. He had great news. "You know", he told me, "You know that that LibraryThing you told me about last week, is available in i.a. German and Dutch too?!" Yes, I knew (of course!), but still it was great news indeed. The rumours are spreading, and so is enthousiasm, too. You are doing a great job, Tim & Co. You knew this already, of course, but then again, once in a while, we have to confirm this in an explicit way--because we are so selfish, and thus want to give you a boost! =)
Note to our fine translators into German : Though my acquaintance is German--he is in his fourties and has 10,000+ books--, I had to explain to him what the Fremdwort "tag" meant. The latter was not too difficult, for one single translation (into German) did the job : "Stichwort".
</bonus>
4MMcM
>3 boekerij:.2
I am intellectually in accord with you on falling back to the original, but I frankly have to question the practical side.
Suppose there is no Oorlog en vrede. Do you want Война и мир?
Suppose there is no Citaten van voorzitter Mao Tsetoeng. Do you want 毛主席语录?
Suppose there is no Wij-zangen. (Gitanjali). Do you want গীতাঞ্জলি?
I support the idea of highlighting the original language version(s) in the long list of editions. But at the head of the page, I suspect it will just turn up obscure sometimes.
>3 boekerij:.3
Doesn't KB use UNIMARC? MARC doesn't seem particularly US or English oriented to me. It's 1970's data processing oriented. (Granted it was funded by a US government agency, but it was developed by a librarian. Just as the Internet was funded by a US government agency, but was developed by a hippie in an office overlooking the Marina del Rey.) Some of the codespaces are English-based, but that does not seem relevant to their population. I believe the point was that MARC records as commonly returned by the libraries currently used do not often have more than one original language field. Not that the MARC standard did not allow this, which it does. Perhaps you are saying that other libraries will return this more often. Which would be a critique of the current library selection and not of MARC.
>2 timspalding:.9
I sometimes put an English translation of the publication info on a first line and a literal transcription of what's inside the book on a second line. Libraries do something in between and put a transliteration in the 260 (with the original script in an 880 if the record is new enough). But cities and publishing houses often have English names. Of course, IANAL.
It's never really bothered me that these newlines do not render properly everywhere.
I am intellectually in accord with you on falling back to the original, but I frankly have to question the practical side.
Suppose there is no Oorlog en vrede. Do you want Война и мир?
Suppose there is no Citaten van voorzitter Mao Tsetoeng. Do you want 毛主席语录?
Suppose there is no Wij-zangen. (Gitanjali). Do you want গীতাঞ্জলি?
I support the idea of highlighting the original language version(s) in the long list of editions. But at the head of the page, I suspect it will just turn up obscure sometimes.
>3 boekerij:.3
Doesn't KB use UNIMARC? MARC doesn't seem particularly US or English oriented to me. It's 1970's data processing oriented. (Granted it was funded by a US government agency, but it was developed by a librarian. Just as the Internet was funded by a US government agency, but was developed by a hippie in an office overlooking the Marina del Rey.) Some of the codespaces are English-based, but that does not seem relevant to their population. I believe the point was that MARC records as commonly returned by the libraries currently used do not often have more than one original language field. Not that the MARC standard did not allow this, which it does. Perhaps you are saying that other libraries will return this more often. Which would be a critique of the current library selection and not of MARC.
>2 timspalding:.9
I sometimes put an English translation of the publication info on a first line and a literal transcription of what's inside the book on a second line. Libraries do something in between and put a transliteration in the 260 (with the original script in an 880 if the record is new enough). But cities and publishing houses often have English names. Of course, IANAL.
It's never really bothered me that these newlines do not render properly everywhere.
5timspalding
Failing to English:
In contexts other than a work page--where I will be showing the original title--it will fail to English. I understand the arguments against this, and also appreciate MMcMs counter-arguments. In general, I feel that English is the most common shared language on the site, and will be so for years. Also, and not unimportantly, I've designed the db in a way that makes it easier to fail to English. Since 95% of the site traffic is English, the database is optimized to accomodate that.
MARC:
MMcM's points are good. Also, MARC is the standard I have. I could invent my own standard--the perfect one--but it would be forking LibraryThing data away from the one good standard for bibliographic data in wide use. MARC has problems, but staying within the MARC sphere has strong advantages as well.
Authors:
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
In contexts other than a work page--where I will be showing the original title--it will fail to English. I understand the arguments against this, and also appreciate MMcMs counter-arguments. In general, I feel that English is the most common shared language on the site, and will be so for years. Also, and not unimportantly, I've designed the db in a way that makes it easier to fail to English. Since 95% of the site traffic is English, the database is optimized to accomodate that.
MARC:
MMcM's points are good. Also, MARC is the standard I have. I could invent my own standard--the perfect one--but it would be forking LibraryThing data away from the one good standard for bibliographic data in wide use. MARC has problems, but staying within the MARC sphere has strong advantages as well.
Authors:
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
6circeus
It's good to know that changes are already planned regarding several of these, and I'll make sure to give feedback when thse roll out!
Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
I don't think there's anything inherently wrong with having some data field that are not already worked into MARC, but are specific to LT. The already existing "tags" and "comments" field certainly come to mind...
If by "show up both", be counted twice under "original languages", I fail to see why they shouldn't, since you are already counting works twice in the basic language field with no qualms.
search engine
I actually noticed that book covered several of the fields I wanted separately, making my research easier, but it still upset me that a research throw up a string in the "publication" as well as "title" fields... I also hoped for an easy wayto return material from a range of record numbers. (eg. 843.* formy French fiction)
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
I use the "publication" field to list, with line breaks, elements like "foreword by:", "collection:" and "translation:", which end up concatenated so that my record for
Shows up as "Pocket (1997), Paperback Collection: Pocket, 10273 Translation: Dominique Haas" in my catalog. Not very practical. Especially as comments are displayed with their line breaks.
And, by the way, am I correct in saying that the book owner is the only one who is ever going to see the "Summary line" data? (in the "recently catalogued" bit of the add book page and in the "you own the following copies" part of a work page)
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
I can't wait to see that!
Add a "secondary original language" field
I feel strange about this, since it's not commonly in the MARC. Would a book so marked show up both lists?
I don't think there's anything inherently wrong with having some data field that are not already worked into MARC, but are specific to LT. The already existing "tags" and "comments" field certainly come to mind...
If by "show up both", be counted twice under "original languages", I fail to see why they shouldn't, since you are already counting works twice in the basic language field with no qualms.
search engine
I actually noticed that book covered several of the fields I wanted separately, making my research easier, but it still upset me that a research throw up a string in the "publication" as well as "title" fields... I also hoped for an easy wayto return material from a range of record numbers. (eg. 843.* formy French fiction)
-When dislaying fields entered with line breaks, display the line breaks
I think it works for other fields. The publication field is not understood by me at least to be multi-line. Can you give me an example of how that would make sense? It's not too hard to implement.
I use the "publication" field to list, with line breaks, elements like "foreword by:", "collection:" and "translation:", which end up concatenated so that my record for
Pocket (1997), Paperback
Collection: Pocket, 10273
Translation: Dominique Haas
Shows up as "Pocket (1997), Paperback Collection: Pocket, 10273 Translation: Dominique Haas" in my catalog. Not very practical. Especially as comments are displayed with their line breaks.
And, by the way, am I correct in saying that the book owner is the only one who is ever going to see the "Summary line" data? (in the "recently catalogued" bit of the add book page and in the "you own the following copies" part of a work page)
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
I can't wait to see that!
7kathrynnd
circeus: And, by the way, am I correct in saying that the book owner is the only one who is ever going to see the "Summary line" data? (in the "recently catalogued" bit of the add book page and in the "you own the following copies" part of a work page)
The summary field can be seen by anyone looking at your catalog, ( the same as title, or author) as long as the field is one of the items selected for the display view. The summary is also used in the list of recently added books on your profile page ( plus any other authors, which is nice ).
The work page links to your catalog so that users can find out the information about your edition. It would be so nice is this could be found on the work page, but it's not.
The summary field can be seen by anyone looking at your catalog, ( the same as title, or author) as long as the field is one of the items selected for the display view. The summary is also used in the list of recently added books on your profile page ( plus any other authors, which is nice ).
The work page links to your catalog so that users can find out the information about your edition. It would be so nice is this could be found on the work page, but it's not.
8circeus
"The summary is also used in the list of recently added books on your profile page"
I think that is only the one originally generated or entered manually, so later updates don't apply to that particularuse of thefild.
I think that is only the one originally generated or entered manually, so later updates don't apply to that particularuse of thefild.
9boekerij
>4 MMcM:
4.3.2
I am intellectually in accord with you on falling back to the original, but I frankly have to question the practical side.
Suppose there is no Oorlog en vrede. Do you want Война и мир?
Suppose there is no Citaten van voorzitter Mao Tsetoeng. Do you want 毛主席语录?
Suppose there is no Wij-zangen. (Gitanjali). Do you want গীতাঞ্জলি?
Even if there is a translation in subtitled at least with the original title in its original language.
I fail to understand why English should be pushed as being more prominent than
I do understand some might have some problems with reading non-Latin script languages. The latter might be a problem to be solved still. Nevertheless, as I read the proposal now, we are talking even Latin script languages.
Thus, e.g. even when I the original French is available--it might reside in my collection--and my preferred language 'd be Dutch, unless there is a Dutch translation at LT's, too, I am to stick with the English translation as the work title? I don't get this, and I think I even don't want to get this.
I thought LT was out for internationalisation. It is not. It is out for imperialisation into (American) English. I am sorry, but the latter is not my cup of tea. Neither do I think it's a Good Thing.
Mark, too, that the present authoritative name of the despot Mao seems to Zedong Mao.
I support the idea of highlighting the original language version(s) in the long list of editions. But at the head of the page, I suspect it will just turn up obscure sometimes.
Obscure? I might not understand the meaning of the latter word.
As I said, though using them--i.e. : non-Latin script languages, too--, however radical this solution might be, it would be intellectually right.
I do understand non-Latin script languages might give rise to some problems, making them less practical in some circumstances.
But I do not understand why the radical solution the other way round--i.e. the radical and extremely narrow-minded one--would gain higher preference. Unless some people think--and for shure they do--that American English is the only decent language possible and that the whole world 'd better get used to that and comply with it--for the better or for the worse.
Most people--even those that are literate and educated, including polyglots--do not speak English. Is this frightening? I don't know. It might be even more frightening that perhaps most people who do speak English as their native tongue, are locked up in English only. I do know the same is counting for i.a.. people having French as their mother tongue.
Regarded from an American perspective, I might have some rather unusual thought on this. I do not like the idea of one languagedominating trying to dominate wherever in the world. I think it is no good. Worse : it 'd be a horror. I do not look forward to living in a Brave New World indeed, for it would be a guarantee for catastrophe--at best.
4.3.3
Doesn't KB use UNIMARC? MARC doesn't seem particularly US or English oriented to me.
Uhm. You know for sure that ISO 639-2B (the English-centric variant of ISO 639-2, for ISO 639-2T is rather mnemonic in the language it codes) is having a successor, being ISO 639-3. The latter is having codes for many more languages AND is reassuming not the anglocentric ISO 639-2B codes, but rather the less narrow-minded ISO 639-2T codes.
Please tell me whether you think having e.g. "ger" (ISO 639-2B or MARC) instead of "de" (ISO 639-1) or "deu" (ISO 639-2T as well as ISO 639-3) for Deutsch (in English : German) is seeming particularly US or English oriented or not. The same is counting for e.g. "dut" instead of "nl" or "nld" for Nederlands (in English : Dutch) and for "fre" instead of "fr" or "fra" for français (in English : French) and so on.
Thus: Yes, "MARC" IS particularly US or English oriented. Clues for ISO 639-2B (MARC) are in English only. True enough, particularly US or English language oriented people might feel happy with this. But please refrain from telling you 'd think this 'd not be particularly US or English oriented--for it is.
It's 1970's data processing oriented. (Granted it was funded by a US government agency, but it was developed by a librarian. Just as the Internet was funded by a US government agency, but was developed by a hippie in an office overlooking the Marina del Rey.)
Though we know about ARPA and DARPA and so on, leading to the Internet indeed, you, too, might know about the origins of hypertext and the World Wide Web. This concept grew from the minds of two engineers working with CERN (Conseil Européen pour la Recherche Nucléaire), based at Geneva, CH. Robert Cailliau (*) (°Tongeren, Flanders, 1947) and Tim Berners-Lee (°London, England, 1955) were overlooking not the Marina del Rey, but rather the Lake of Geneva/Lac Leman. Oops, that's sounding European and rather multilingual an environment indeed--it is.
(*) Have a look at Robert Cailliau's rather hilarious (for those who appreciate this kind of humor) Who, Where, Why... and of course at James Gillies's and his How the Web Was Born : The Story of the World Wide Web (OUP, de, it).
(The latter book is having the double author problem, too.)
Some of the codespaces are English-based, but that does not seem relevant to their population. I believe the point was that MARC records as commonly returned by the libraries currently used do not often have more than one original language field. Not that the MARC standard did not allow this, which it does. Perhaps you are saying that other libraries will return this more often. Which would be a critique of the current library selection and not of MARC.
I stick with the idea that MARC and so-called MARC Standards are rather Americanocentric.
I do not have any problem with any specialistic and specifically machine readable code strongly leaning on whatever language.
But I think LT is not about specialists and (other) trained professional librarians, but rather about users--i.e. : it is about "ordinary" book lovers : us, all of us, Thingamabrarians.
The question as I see it is this : Should each and every Thingamabrarian (present or future) know English?
If the answer be : "yes", or even : "he 'd better"--and thus LT can stick with and give preference to i.a. ISO 639-2/B rather than ISO 639-1 (whenever available) or ISO 639-3/T or ISO 639-3--I think the whole so-called multilinguality and internationalisation of LT might become a bad joke. Though the latter might sound rude--I am aware of that--I am sorry about the latter, the more I am sorry about this what I think is a fact.
Unless the user LT is having in mind and is looking for is to be a technical specialist and/or is to be English language only, having Americanocentric and/or Anglocentric particularities as i.a. ISO 639-2/B ("MARC Standard") presented to the user is, uhm, not quite smart. Methinks.
Then again, dealing with real multilinguality might be rather new to most present LT (power) users and to LT staff.
The success mantra : "Think global, act local" has to do with the user feeling at home--i.e. as if the service was locally founded indeed.
I think that one of the main reasons i.a. Microsoft could grow to a major global success--even while their technical, uhm, features could give rise to some, uhm, unpleasant experiences--is that MS has understood what it means to act local.
Though e.g. their browser might have somebugs particular features--and it has, I know--their strategy has brought a USP by incorporating a yet simple though major--if not critical--usability feature: "Pick your language" (and have the latter in your own language, too).
4.3.2
I am intellectually in accord with you on falling back to the original, but I frankly have to question the practical side.
Suppose there is no Oorlog en vrede. Do you want Война и мир?
Suppose there is no Citaten van voorzitter Mao Tsetoeng. Do you want 毛主席语录?
Suppose there is no Wij-zangen. (Gitanjali). Do you want গীতাঞ্জলি?
Even if there is a translation in subtitled at least with the original title in its original language.
I fail to understand why English should be pushed as being more prominent than
I do understand some might have some problems with reading non-Latin script languages. The latter might be a problem to be solved still. Nevertheless, as I read the proposal now, we are talking even Latin script languages.
Thus, e.g. even when I the original French is available--it might reside in my collection--and my preferred language 'd be Dutch, unless there is a Dutch translation at LT's, too, I am to stick with the English translation as the work title? I don't get this, and I think I even don't want to get this.
I thought LT was out for internationalisation. It is not. It is out for imperialisation into (American) English. I am sorry, but the latter is not my cup of tea. Neither do I think it's a Good Thing.
Mark, too, that the present authoritative name of the despot Mao seems to Zedong Mao.
I support the idea of highlighting the original language version(s) in the long list of editions. But at the head of the page, I suspect it will just turn up obscure sometimes.
Obscure? I might not understand the meaning of the latter word.
As I said, though using them--i.e. : non-Latin script languages, too--, however radical this solution might be, it would be intellectually right.
I do understand non-Latin script languages might give rise to some problems, making them less practical in some circumstances.
But I do not understand why the radical solution the other way round--i.e. the radical and extremely narrow-minded one--would gain higher preference. Unless some people think--and for shure they do--that American English is the only decent language possible and that the whole world 'd better get used to that and comply with it--for the better or for the worse.
Most people--even those that are literate and educated, including polyglots--do not speak English. Is this frightening? I don't know. It might be even more frightening that perhaps most people who do speak English as their native tongue, are locked up in English only. I do know the same is counting for i.a.. people having French as their mother tongue.
Regarded from an American perspective, I might have some rather unusual thought on this. I do not like the idea of one language
4.3.3
Doesn't KB use UNIMARC? MARC doesn't seem particularly US or English oriented to me.
Uhm. You know for sure that ISO 639-2B (the English-centric variant of ISO 639-2, for ISO 639-2T is rather mnemonic in the language it codes) is having a successor, being ISO 639-3. The latter is having codes for many more languages AND is reassuming not the anglocentric ISO 639-2B codes, but rather the less narrow-minded ISO 639-2T codes.
Please tell me whether you think having e.g. "ger" (ISO 639-2B or MARC) instead of "de" (ISO 639-1) or "deu" (ISO 639-2T as well as ISO 639-3) for Deutsch (in English : German) is seeming particularly US or English oriented or not. The same is counting for e.g. "dut" instead of "nl" or "nld" for Nederlands (in English : Dutch) and for "fre" instead of "fr" or "fra" for français (in English : French) and so on.
Thus: Yes, "MARC" IS particularly US or English oriented. Clues for ISO 639-2B (MARC) are in English only. True enough, particularly US or English language oriented people might feel happy with this. But please refrain from telling you 'd think this 'd not be particularly US or English oriented--for it is.
It's 1970's data processing oriented. (Granted it was funded by a US government agency, but it was developed by a librarian. Just as the Internet was funded by a US government agency, but was developed by a hippie in an office overlooking the Marina del Rey.)
Though we know about ARPA and DARPA and so on, leading to the Internet indeed, you, too, might know about the origins of hypertext and the World Wide Web. This concept grew from the minds of two engineers working with CERN (Conseil Européen pour la Recherche Nucléaire), based at Geneva, CH. Robert Cailliau (*) (°Tongeren, Flanders, 1947) and Tim Berners-Lee (°London, England, 1955) were overlooking not the Marina del Rey, but rather the Lake of Geneva/Lac Leman. Oops, that's sounding European and rather multilingual an environment indeed--it is.
(*) Have a look at Robert Cailliau's rather hilarious (for those who appreciate this kind of humor) Who, Where, Why... and of course at James Gillies's and his How the Web Was Born : The Story of the World Wide Web (OUP, de, it).
(The latter book is having the double author problem, too.)
Some of the codespaces are English-based, but that does not seem relevant to their population. I believe the point was that MARC records as commonly returned by the libraries currently used do not often have more than one original language field. Not that the MARC standard did not allow this, which it does. Perhaps you are saying that other libraries will return this more often. Which would be a critique of the current library selection and not of MARC.
I stick with the idea that MARC and so-called MARC Standards are rather Americanocentric.
I do not have any problem with any specialistic and specifically machine readable code strongly leaning on whatever language.
But I think LT is not about specialists and (other) trained professional librarians, but rather about users--i.e. : it is about "ordinary" book lovers : us, all of us, Thingamabrarians.
The question as I see it is this : Should each and every Thingamabrarian (present or future) know English?
If the answer be : "yes", or even : "he 'd better"--and thus LT can stick with and give preference to i.a. ISO 639-2/B rather than ISO 639-1 (whenever available) or ISO 639-3/T or ISO 639-3--I think the whole so-called multilinguality and internationalisation of LT might become a bad joke. Though the latter might sound rude--I am aware of that--I am sorry about the latter, the more I am sorry about this what I think is a fact.
Unless the user LT is having in mind and is looking for is to be a technical specialist and/or is to be English language only, having Americanocentric and/or Anglocentric particularities as i.a. ISO 639-2/B ("MARC Standard") presented to the user is, uhm, not quite smart. Methinks.
Then again, dealing with real multilinguality might be rather new to most present LT (power) users and to LT staff.
The success mantra : "Think global, act local" has to do with the user feeling at home--i.e. as if the service was locally founded indeed.
I think that one of the main reasons i.a. Microsoft could grow to a major global success--even while their technical, uhm, features could give rise to some, uhm, unpleasant experiences--is that MS has understood what it means to act local.
Though e.g. their browser might have some
10boekerij
>5 timspalding:
Failing to English:
In contexts other than a work page--where I will be showing the original title--it will fail to English. I understand the arguments against this, and also appreciate MMcMs counter-arguments. In general, I feel that English is the most common shared language on the site,
Of course it is! Until some weeks ago, it was the only language even possible at this site. That's not a feeling, that's a fact. And we all do know, don't we.
Then again, the question is not : "Where have we been ?", but rather : "Where are we going ?" as well as : "Where do we want to go ?".
LibraryThing was launched more than a year, i.e. next to 14 months ago, where as LibraryThing in your language was launched only 2 weeks ago.
This "argument" of yours must be a joke. Methinks.
and will be so for years.
This might depend--depend on LT's choices indeed. For if LT is not wanting to deliver full support for whatever languages it pretends to support--as with : "Failing to English" indeed--LT's success with "foreign" languagesmight will be far less than it could be.
Lots of people have been investing large amounts of their time and effort to try and help LT in rolling out in different languages. What they hear now is kind of : "Big deal. You should have known. Read the fine print (in English, of course). It was just a major joke. Shut up!"--or, as thebuzz Home page says : "Go away!"
One is temped to asking whether LT staff maybe is kind of afraid of risking a major success in other languages, too--and wonder.
Also, and not unimportantly, I've designed the db in a way that makes it easier to fail to English.
That's a clear and understandable argument. Then again, it doesn't explain why LT 'd be to stick with that Anglocentric behaviour, this the more while LT maintains it is driving for internationalisation and multilingualism--i.e. providing locally adapted versions.
Since 95% of the site traffic is English,
Of course, it is. Then again, don't you think that gaining a 5% share in less than 2 weeks (compared to the about 60 weeks LT is in the air now) is rather impressive (and maybe some frightening, too, indeed). The more while we all know even "international"--i.e. "foreign" language--versions of LT, however incomplete they are--are still suffering from falling back to the English language version, too.
I for myself think that the gaining of a 5% share in that short a period of time is ratherimpressive overwhelming, for it is beyond any reasonable expectations, I think.
the database is optimized to accomodate that.
Uhm. Mightn't want think : "to keep it that way"?
MARC:
MMcM's points are good. Also, MARC is the standard I have. I could invent my own standard--the perfect one--but it would be forking LibraryThing data away from the one good standard for bibliographic data in wide use. MARC has problems, but staying within the MARC sphere has strong advantages as well.
Sure it has. But I think i.a. MARC (language code) standards (ISO 639-2B) is expected to be superseded by ISO 639-3 in due time. Please mark the latter is based not on ISO 639-2B, but on ISO 639-2T indeed--i.e. i.a. it is dealing better with internationalisation (or internationalization, as you wish).
Authors:
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
Having that, you might think about prolonging the Title field, too. For, dealing with e.g. UTF-8, it might be rather tight now.
Final remarks (for now that is, of course):
Though I do understand my remarks and commentaries as presented above might sound rather harsh, please do understand I, nor they, do not have whatever intention to harm LT. On the contrary. Then again, they might express some disappointments indeed. However, the reason for my expressing them over here, is not to have the latter be final.
I think providing and accepting opinion, too, might be a major contribution to help and steer LT to success. Very often, dissenting opinions are the most interesting ones. One who's looking for applause and confirmation only, 'd better hire a valet. Methinks.
Putting things straight : Keep up with the good work. Please.
Failing to English:
In contexts other than a work page--where I will be showing the original title--it will fail to English. I understand the arguments against this, and also appreciate MMcMs counter-arguments. In general, I feel that English is the most common shared language on the site,
Of course it is! Until some weeks ago, it was the only language even possible at this site. That's not a feeling, that's a fact. And we all do know, don't we.
Then again, the question is not : "Where have we been ?", but rather : "Where are we going ?" as well as : "Where do we want to go ?".
LibraryThing was launched more than a year, i.e. next to 14 months ago, where as LibraryThing in your language was launched only 2 weeks ago.
This "argument" of yours must be a joke. Methinks.
and will be so for years.
This might depend--depend on LT's choices indeed. For if LT is not wanting to deliver full support for whatever languages it pretends to support--as with : "Failing to English" indeed--LT's success with "foreign" languages
Lots of people have been investing large amounts of their time and effort to try and help LT in rolling out in different languages. What they hear now is kind of : "Big deal. You should have known. Read the fine print (in English, of course). It was just a major joke. Shut up!"--or, as the
One is temped to asking whether LT staff maybe is kind of afraid of risking a major success in other languages, too--and wonder.
Also, and not unimportantly, I've designed the db in a way that makes it easier to fail to English.
That's a clear and understandable argument. Then again, it doesn't explain why LT 'd be to stick with that Anglocentric behaviour, this the more while LT maintains it is driving for internationalisation and multilingualism--i.e. providing locally adapted versions.
Since 95% of the site traffic is English,
Of course, it is. Then again, don't you think that gaining a 5% share in less than 2 weeks (compared to the about 60 weeks LT is in the air now) is rather impressive (and maybe some frightening, too, indeed). The more while we all know even "international"--i.e. "foreign" language--versions of LT, however incomplete they are--are still suffering from falling back to the English language version, too.
I for myself think that the gaining of a 5% share in that short a period of time is rather
the database is optimized to accomodate that.
Uhm. Mightn't want think : "to keep it that way"?
MARC:
MMcM's points are good. Also, MARC is the standard I have. I could invent my own standard--the perfect one--but it would be forking LibraryThing data away from the one good standard for bibliographic data in wide use. MARC has problems, but staying within the MARC sphere has strong advantages as well.
Sure it has. But I think i.a. MARC (language code) standards (ISO 639-2B) is expected to be superseded by ISO 639-3 in due time. Please mark the latter is based not on ISO 639-2B, but on ISO 639-2T indeed--i.e. i.a. it is dealing better with internationalisation (or internationalization, as you wish).
Authors:
Yes. As many authors as you like (there might be some large practical limit, so you don't put the phonebook in), plus a "role" for each.
Having that, you might think about prolonging the Title field, too. For, dealing with e.g. UTF-8, it might be rather tight now.
Final remarks (for now that is, of course):
Though I do understand my remarks and commentaries as presented above might sound rather harsh, please do understand I, nor they, do not have whatever intention to harm LT. On the contrary. Then again, they might express some disappointments indeed. However, the reason for my expressing them over here, is not to have the latter be final.
I think providing and accepting opinion, too, might be a major contribution to help and steer LT to success. Very often, dissenting opinions are the most interesting ones. One who's looking for applause and confirmation only, 'd better hire a valet. Methinks.
Putting things straight : Keep up with the good work. Please.
11MMcM
I do not have any special insight into the workings behind LT. But as just another user, I have not seen anything that would indicate that Tim's motivations even remotely resemble those that you ascribe to this site. They seem simply to be pragmatic.
Would it seem better if instead of picking English explicitly it picked the most prevalent title regardless of language? This is, first try the most popular in your language; then the most popular in any language. Speaking practically, as I have been trying to all along, I suspect that this would be the same. If we assume for the moment that a foreign title may be a problem for a given user, absent a database of all the languages you read and how well, this would seem to minimize the probability of that overall. Or is that mob rule?
I still fail to see what the MARC language codes have to do with the number of such codes that appears in a given record. You're quite right that the codes, which are only intended to be read by machines, are English in origin. But how does that help or hinder one from having two or more of them? That was, I believe, the issue at hand this time.
I like WWW as much as the next person, but I believe that most people consider hypertext to originate with Vannevar Bush's famous 1945 article. I myself had the good fortune to be involved with some hypertext systems before WWW. And on multilingual computing systems before Unicode, when one had to worry a lot about finding enough memory for a Kanji font. And from there I will stand by my original point that the country of origin or funding source is at best a secondary influencer of a system's suitability for one thing or another and that hidden agendas are rare.
Would it seem better if instead of picking English explicitly it picked the most prevalent title regardless of language? This is, first try the most popular in your language; then the most popular in any language. Speaking practically, as I have been trying to all along, I suspect that this would be the same. If we assume for the moment that a foreign title may be a problem for a given user, absent a database of all the languages you read and how well, this would seem to minimize the probability of that overall. Or is that mob rule?
I still fail to see what the MARC language codes have to do with the number of such codes that appears in a given record. You're quite right that the codes, which are only intended to be read by machines, are English in origin. But how does that help or hinder one from having two or more of them? That was, I believe, the issue at hand this time.
I like WWW as much as the next person, but I believe that most people consider hypertext to originate with Vannevar Bush's famous 1945 article. I myself had the good fortune to be involved with some hypertext systems before WWW. And on multilingual computing systems before Unicode, when one had to worry a lot about finding enough memory for a Kanji font. And from there I will stand by my original point that the country of origin or funding source is at best a secondary influencer of a system's suitability for one thing or another and that hidden agendas are rare.
12timspalding
The argument for failing to English:
1. First, actual work pages will show all languages. We're talking about lists of recommendations, of top-tagged books, etc.
2. Second, none of this affects your data--only how your data relates to the larger community's data.
3. Failing to English is easier on the database. Because--at present--95% of the usage of LibraryThing is in English, the database it optimized for that.* Developers make pragmatic decisions like that all the time. It would ne nice if there were no limits--if every time you hit the fiction page it gave you up-to-the-second stats on over 500,000 books tagged fiction. If every list of works was filtered through a list of each user's languages. But resources aren't limitless.
4. At present, English is the most common second language on LibraryThing. True, this is in part a historical result. But it remains true. If by some chance, LibraryThing took off very hard in a country where the most common second language was not English, that would be a powerful argument to change the fail-over, at least in that language. LibraryThing has and will react flexibly to circumstances.
5. Like it or not, English is the most common second-language taught and known in the EU, and, I suspect, in the world. This may change some day, but I can program faster than it will change.
6. Failing over to the original language involves non-Latin scripts, sure to turn users off more than English-language fail over. There is also the problem of transliterations. Get an Arabic, Greek or Chinese MARC record from a US library and you're likely to get a transliterated title.
7. The idea that LibraryThing's use of non-standard subdomains and (underneath) "Americacentric" MARC files makes internationalization a "bad joke" seems a bit extreme and off-point, like telling me I can't go to France unless I install French windows in my home.
8. Using English as a fail-over has the virtue of consistency. Almost all books on LibraryThing HAVE an English fail-over. The same is not true for other languages. I suspect, for example, that a list of Arabic books, or an Arabic-related tag would present many books with no cataloged Arabic original. And if it had one, it might well be a transliterated one, which would annoy as much as it pleased. Besides, where do you fail if both domain language and the original language fail?
To open things up, I want to strike a blow against the idea that people should get all wount up over standard which arose out of a particular linguistic or national context. There is something a little silly about railing against these standards, as if they really have a zombie-like force over our lives. True, the United States has the prime spot in the international phone numbers--1. And MARC standards have abbreviations based (often) on the English name. Most of the top-level non-national domains are based on English words (.com, org, etc.). But chemists the world over go about their work, undisturbed by the dread hand of Roman Imperialism and its hegemony over chemical nomenclature. Waiters in San Francisco and Beijing cook whatever they please, untroubled by the French language's grip on gastronomic language. And we all have clocks running off multiples of 12, yet remain blissfully unopressed by the malign influence of Sumerian globalization.
*Strictly speaking, this means that each work knows the default title (which is English unless there is no English). To get to other language titles it needs to "join" to another table, which it will only do if you're in another language. Asking for the original language would require a second join.
PS: Title field. Yes. I think the length of the title field need to be increased. Again, it's about resources. But I understand how UTF8 has changed the game.
1. First, actual work pages will show all languages. We're talking about lists of recommendations, of top-tagged books, etc.
2. Second, none of this affects your data--only how your data relates to the larger community's data.
3. Failing to English is easier on the database. Because--at present--95% of the usage of LibraryThing is in English, the database it optimized for that.* Developers make pragmatic decisions like that all the time. It would ne nice if there were no limits--if every time you hit the fiction page it gave you up-to-the-second stats on over 500,000 books tagged fiction. If every list of works was filtered through a list of each user's languages. But resources aren't limitless.
4. At present, English is the most common second language on LibraryThing. True, this is in part a historical result. But it remains true. If by some chance, LibraryThing took off very hard in a country where the most common second language was not English, that would be a powerful argument to change the fail-over, at least in that language. LibraryThing has and will react flexibly to circumstances.
5. Like it or not, English is the most common second-language taught and known in the EU, and, I suspect, in the world. This may change some day, but I can program faster than it will change.
6. Failing over to the original language involves non-Latin scripts, sure to turn users off more than English-language fail over. There is also the problem of transliterations. Get an Arabic, Greek or Chinese MARC record from a US library and you're likely to get a transliterated title.
7. The idea that LibraryThing's use of non-standard subdomains and (underneath) "Americacentric" MARC files makes internationalization a "bad joke" seems a bit extreme and off-point, like telling me I can't go to France unless I install French windows in my home.
8. Using English as a fail-over has the virtue of consistency. Almost all books on LibraryThing HAVE an English fail-over. The same is not true for other languages. I suspect, for example, that a list of Arabic books, or an Arabic-related tag would present many books with no cataloged Arabic original. And if it had one, it might well be a transliterated one, which would annoy as much as it pleased. Besides, where do you fail if both domain language and the original language fail?
To open things up, I want to strike a blow against the idea that people should get all wount up over standard which arose out of a particular linguistic or national context. There is something a little silly about railing against these standards, as if they really have a zombie-like force over our lives. True, the United States has the prime spot in the international phone numbers--1. And MARC standards have abbreviations based (often) on the English name. Most of the top-level non-national domains are based on English words (.com, org, etc.). But chemists the world over go about their work, undisturbed by the dread hand of Roman Imperialism and its hegemony over chemical nomenclature. Waiters in San Francisco and Beijing cook whatever they please, untroubled by the French language's grip on gastronomic language. And we all have clocks running off multiples of 12, yet remain blissfully unopressed by the malign influence of Sumerian globalization.
*Strictly speaking, this means that each work knows the default title (which is English unless there is no English). To get to other language titles it needs to "join" to another table, which it will only do if you're in another language. Asking for the original language would require a second join.
PS: Title field. Yes. I think the length of the title field need to be increased. Again, it's about resources. But I understand how UTF8 has changed the game.
13BoPeep
the malign influence of Sumerian globalization
That sounds like a particular sort of short story title... I may borrow the line. :D
That sounds like a particular sort of short story title... I may borrow the line. :D
14timspalding
Well, if it won't for the whole base 12 and 60 thing, the US Army would probably not be in Iraq.
15wyvernfriend
maybe what needs to happen is that the default language of a text on a sub-site is the primary language of the sub-site, having english as a secondary default. Leaving the mainsite defaulting to English.
16timspalding
The system is now in place for one page--the main work page.
Witness, Eco's "The name of the rose"
English, The name of the Rose
French, Le Nom de la rose
Slokav, Meno ruže
The suggestions on that page are also in the local language, failing to English.
I've only done one page because I want to watch database performance.
I've run into problems with the "original language." I was listing it up with the title, but it turns out that the language of a book and its title are not always in synch. This is particularly true with (Ancient) Greek and Latin, where a Greek book is more likely to have a Latin or English title than a Greek one. But it shows up quite frequently. Saying "Title: The Odyssey; original title: The Odyssey (Loeb Classical Library)" gives me the chills.
I think that work pages will continue to use the local title, failing to English. The "original title" and all other-language titles will show up on book information, but down the page a little so that problems aren't as jarring.
I should look at the MARC field for "original title" and see if it has a lower screwup rate.
Witness, Eco's "The name of the rose"
English, The name of the Rose
French, Le Nom de la rose
Slokav, Meno ruže
The suggestions on that page are also in the local language, failing to English.
I've only done one page because I want to watch database performance.
I've run into problems with the "original language." I was listing it up with the title, but it turns out that the language of a book and its title are not always in synch. This is particularly true with (Ancient) Greek and Latin, where a Greek book is more likely to have a Latin or English title than a Greek one. But it shows up quite frequently. Saying "Title: The Odyssey; original title: The Odyssey (Loeb Classical Library)" gives me the chills.
I think that work pages will continue to use the local title, failing to English. The "original title" and all other-language titles will show up on book information, but down the page a little so that problems aren't as jarring.
I should look at the MARC field for "original title" and see if it has a lower screwup rate.
17circeus
Coming back on the publication data thing.
The problem goes:
On the book data enteing pages, this fieldis a textarea, with everything that entails (i.e., you can have line breaks inside). However, it is displayed and edited in the catalog as an input field (typing a line breaks causes the field to be saved, as with the "author"field), but when editing, the line breaks still show as if the field, like comments, allowed line breaks to be entered, so thatto adda line breaks (that STILL won'tdisplay), you need to edit the book separately.
The problem goes:
On the book data enteing pages, this fieldis a textarea, with everything that entails (i.e., you can have line breaks inside). However, it is displayed and edited in the catalog as an input field (typing a line breaks causes the field to be saved, as with the "author"field), but when editing, the line breaks still show as if the field, like comments, allowed line breaks to be entered, so thatto adda line breaks (that STILL won'tdisplay), you need to edit the book separately.
18cad_lib
Hope this is a good placefor this question/suggestion:
What about a field for Book Series informatin? The most "famous" perhaps is a field where one could have the Loeb Classical Library info. Would be a great way for consistent cataloging of works in the Loeb Lib.
E.g. I am amazed to find only one instance of the 1st volume of Augustine's Confessions already present in LT
Alternately: how do folks handle Titles that are part of a series, since that is technically part of the official and or authoritative data about a title/work?
Admit I havent (yet)read all the messages in this thread, just the first and Tim's reply...
What about a field for Book Series informatin? The most "famous" perhaps is a field where one could have the Loeb Classical Library info. Would be a great way for consistent cataloging of works in the Loeb Lib.
E.g. I am amazed to find only one instance of the 1st volume of Augustine's Confessions already present in LT
Alternately: how do folks handle Titles that are part of a series, since that is technically part of the official and or authoritative data about a title/work?
Admit I havent (yet)read all the messages in this thread, just the first and Tim's reply...
19circeus
Most series are in the form
Series Title, volume X: Volume name
Except with "tome" for volume, because it,s the french word and replacing i every timeis getting annoying >.>
Series Title, volume X: Volume name
Except with "tome" for volume, because it,s the french word and replacing i every timeis getting annoying >.>
20rjohara
Add an ISSN field
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
I'd put in strong vote for this. I've got a whole group of serials cataloged in my library. They already exist in the Z39.50 databases LT uses (for the most part), the data is generally of good quality, and there are only a few missing elements (like the ability to record/manipulate ISSNs) needed within LT to bring it right up to speed. The other big missing element is holdings data; there's a whole MARC standard for that, but maybe population of an ISSN field could automagically make a holdings field appear in the record. (Ordinary users would never notice it; only serials geeks.)
Interesting. We've been thinking of doing magazines and etc. This might be a way to get into them.
I'd put in strong vote for this. I've got a whole group of serials cataloged in my library. They already exist in the Z39.50 databases LT uses (for the most part), the data is generally of good quality, and there are only a few missing elements (like the ability to record/manipulate ISSNs) needed within LT to bring it right up to speed. The other big missing element is holdings data; there's a whole MARC standard for that, but maybe population of an ISSN field could automagically make a holdings field appear in the record. (Ordinary users would never notice it; only serials geeks.)
