Languages in Common Knowledge #2: "Borrowing" data between languages

Following the addition of Common Knowledge "visibility" (see this thread), I've introduced another feature to Common Knowledge, both more useful and potentially more contentious: cross-language display.

Basically, CK now show your language data if it's there, and data from another language if it is not.

This screenshot, from the German site's page on The Girl with Dragon Tattoo, shows the message when the data is drawn from another site. (The yellow wording is because the words haven't yet been translated into German.)



This screenshot, from the English site's page for Dr. Faustus, shows it without the yellow wording, showing Italian data poking through onto the English site.



You can convert data from "borrowed data" to your language's data by editing it and clicking save.

Notes:

1. This feature is new. It is rolled out in full knowledge it will have various bugs.
2. At present, if you don't have data in your language it picks from the version that has the most data for the book (eg., Italian has more than German above). This solution is not, however, going to work everywhere on the site. We may need to establish a formal pecking order--for example, by total edits across the language-site.
3. I experimented with different looks, like putting the language within the text block itself. In some ways, that looks better, but it completely hoses the way the code is written--editing was picking up the name of the language. Now I'm growing to like it as it is. It is perhaps clearer.
4. Tweaks aside, this is the path I've chosen--over the path of designating some fields as shared between versions, and some not. There is, finally, no field that is entirely flat data—without the possibility of text in your language. We could, I suppose, pick some fields to "not borrow" (eg., quotations), but I think I prefer more data—and the invitation to correct data that's not in your language.
5. Neither language-CK features extend to authors yet. I want to fix bugs before I spread the feature too widely.

I'm assuming that any edits done to CK apply to the common work, not my personal library. Sounds obvious, but I still get tripped up on the data dictionary so I've stated that in the event I need to be corrected.

Questions:

1. Should we suggest / request that a user "translate" the borrowed CK before editing and saving? (Is that possible?) Or leave it up to the user? Or should instead, the user only save borrowed data in that language (not translate)?

I think it will be tempting to translate rather than find the corresponding data in translation, but it would make tracing the source more difficult.

2. In your screenshot for Dragon Tattoo the text box for Einheitssachtitel is shaded pale yellow, while the text box for Originaltitel is not. Any reason for this? Both have borrowed data, and both do not have the explanatory text translated from English to German, so that shouldn't be the cause.

ETA viewing in XP / Chrome (Question 1)

2> the text box for Einheitssachtitel is shaded pale yellow, while the text box for Originaltitel is not.

The field turns pale yellow when your mouse hovers over it, or when you are editing it. That's all there is to that.

I've already found an interesting use for this - I saw a couple Japanese Publisher Series entries that might be just lists of the publisher's imprint. I'll have to research to be sure, but it could turn out to be an interesting way to catch stray CK that doesn't belong from other languages.

>2 elenchus:

The degree of translation will depend. Often, no translation is actually needed. I'd rather rely on people here. Certainly, CK is not necessarily the easiest thing to understand ab novo. But then neither is Wikipedia editing. In general, I think more verbiage will not actually help.

No, the yellow is an accident. It yellows when you mouse over it. My mouse was over it.

If you don't want any of the data to show through, can you prevent it by clicking and deleting, on the English site (as in the case of the alternate titles above)?

Depends on the meaning of "want." If you personally don't want it, let's talk. If you think it's wrong for the site, by all means delete it.

Ok, what I mean is what if there is data coming through that is not appropriate for the site it's bleeding into, AND there's no appropriate data in that language to replace it with: can we make it go away?

Yeah, delete.

>7 rsterling:, 8

And by deleting, it's removed from the language site the user is logged into, not from the original source site?

I'm not clear on the usage of "site" in your posts above: LT generally, or a language-specific site within LT.

Right, I just want to make sure I'm clear. I would want to delete it from the English site, but not the Italian one. So clicking edit, then delete, will accomplish that?

>9 elenchus:

Right. It only changes it on your site. I'll change the wording.

Ah, wording is okay, eg., "Information from the English Common Knowledge. Edit to add it to the German one."

This is great! Thanks, Tim!

Looks good, apart from this:

5. Neither language-CK features extend to authors yet.

... with the implication that you will extend this to authors. I don't want to see this happen before author disambiguation is in place. I know it might point up where there are authors with the same name with data on other language sites, but it will make unpicking the code and data that much more difficult when you eventually get around to it.

Wondering about the Original Title specifically; on the Doctor Faustus page you use as an example it says "Information from the Italian Common Knowledge. Edit to add it to the English one." Assuming that the original title actually is the Italian one that's already there coming through from the Italian site, should we be encouraging people to enter the same data on the other language sites?

Assuming that the original title really is the original title, it should be in the original language, and therefore the same across languages.

Right, so for Original Title at least, once correct data is entered in any site, it shouldn't say "Edit to add it to the English one." because it sounds like it's telling people to enter the original English title.

Original Publication Date would have the same problem. If 1947 had been entered in the Italian site, it would not be necessary to enter it on any other site. Although I wouldn't consider it wrong to add the original English publication date, as has been done, as long as the original original publication date from the Italian site wasn't lost.

Assuming this is the right place for bugs:

I can't actually see the CK anymore. I get the grey box showing what's available in different languages, but then it goes straight to the bar for Publsihed reviews. Even the hint text is missing.

However, if I'm logged out I can see CK, but there is no option to see it in different languages.

I'm using IE7 on WinXP Pro.

I don't want to see this happen before author disambiguation is in place.

No, I think it's better to do it. It's inconsistent to have CK work one way one place and another another.

The basic rule for CK on split authors is to have it apply to the largest author, which should also be the number 1 author. This doesn't change site-to-site.

Assuming that the original title really is the original title, it should be in the original language, and therefore the same across languages.

Okay, so I think we should be agreed that that field and that field alone should be truly and irrevocably shared across the sites, right?

>19 Scorbet:

Anyone else not seeing it?

>19 Scorbet:

You didn't shut it, did you (compare these two):

>21 timspalding:

I checked that first of all. No, it's definitely open.

But clicking on the "xx-more" link appears to display everything.

http://www.librarything.com/topic/107849#2459622

is actually reporting the same problem.

20> No, I think it's better to do it. It's inconsistent to have CK work one way one place and another another.

Do you feel it is better to have the system work "consistently" if it means the helpers will throw their hands up and stop fixing the data?

Never mind. It appears to be IE-general.

Okay, so I think we should be agreed that that field {original title} and that field alone should be truly and irrevocably shared across the sites, right.

And Original Publication Date.

No, because people say:

1959 (French edition)
1962 (British edition)

etc. Only original title explicitly says to do it only in the original language.

Tim: I think we should be agreed (Original Title) and that field alone should be truly and irrevocably shared across the sites, right?

I did mention Original Publication Date as another worth thinking about.

I think those two are special because a) they're both "Original" and b) they're both language independant (i.e. the correct value on the Italian site is the same as the correct value on the US site).

>27 r.orrison:

I type faster than you! :)

So the Original Publication Date instructions need to be changed to reflect that. If people are going to enter the original publication date for every different edition, they should specify what edition they're referring to.

It just seems you're confusing users with the term "Original" meaning two different things in two boxes that are practically next to each other. In one, it means Original in the world, in the other it means Original in the country (or is it language?). Would it make more sense if "Original publication date" was changed to "Original publication dateS"? Still seems a bit confusing.

I was one of the early suggesters for an "Original Publication Date", and I meant the original publication date. THE. Not, first publication in this language, or that edition, or whatever; I've seen all kinds of stuff -- including simply multiple editions -- listed in the OPD field. It seems most intuitively named to mean one, original date. "Original publication dates", plural, is bizarre. There's only one "original". Let's change the instructions to reflect what the fieldname logically means, please!

Removing my "L" and speaking as a member, I have to say I agree with lquilter et al. on this one - there should only be one "Original Publication Date": the first time the work was published in any language. We could add "First Publication in Language X," but I think "Original Publication Date" should be just that. No?

Expanding a bit on what I just said - if we use the current instructions for OPD, even if people do the "1893 (eng.)", "1895 (esp.)", "1897 (deu.)" thing with separate lines for each, that should be "shareable" through all languages.

31> I agree with that. Each thing is a piece of data that might be interesting, but I think the interestingness of the original original original publication date is far higher than the original publication date in Zimbabwe.

Though I can see the argument that putting multiple OPDs in there doesn't get rid of the oldest one. At some point it gets a bit silly, though.



It's like they're trying to create an editions layer using only OPD...

31> Yes, but sometimes it can be very useful to know when a translation was first available, and where else can that information go? I also like doing an original publication date for an anthology as well as the dates for items in that anthology - for example, with a Norton Critical Edition, the date for the first NCE, and also for the title text (at least until we have working contains/contained in functions).

Though the ONLY times I can see using the OPD for anything other than a single, first date of publication is when there are two versions that can't be split (there are two books in the Bobbsey Twins series with the same title and no ISBN, but the second was rewritten to have very little resemblance to the first), when there are other languages involved (with notations of the language), or when it is an anthology/collection of works previously published.

Thus, the OPD should always be shareable, since it would be the same for all languages, even if there are multiple ones.

What about adding a separate CK field for translation dates?

I don't think translations covers it, though.

So you really do want CK to be used for an attempted edition-layer?

If you really want to be able to add the publication date of every edition then you should do that in a separate Publication Date field and leave OPD for the real original date. But a Publication Date field would really be duplicative of data that is already in people's catalogs. Perhaps you should auto-generate such a field from the catalog data, but that's getting pretty far into an edition layer which you said you doubted was possible.

39> After giving it some more thought it seems that Tim is trying to mix two different ways of representing languages making it very confusing. CK could have been designed from the beginning as just one CK with people appending the language info to the data. So the Canonical Title field could have had "The Hobbit (English)", "Der Hobbit (Deutch)" and so on. But instead he developed a system with more separation between the languages so that if you wanted to see the German data you would have to go to German site. Now, he's modified that so its easier to get to the data for the other languages.

However, the data for OPD has been treated differently it seems. Instead of putting the OPD for English on the English site and the OPD for German on the German site in some cases it's been added on separate lines on each site. I guess that's because OPD is really independent of language but people wanted to layer additional publication date info onto the field. That worked ok as long as the language data was separate as it was, but now with more integration between languages, do we really want all this data duplicated across all the languages?

Ugh, that multiple original publication dates thing is one of my pet peeves. I'm not sure I've ever seen a case where I've thought it's made sense to have more than one date.

Nice new feature! Just a minor suggestion from an interface consistency standpoint: would it make sense to have automatic suggestions appear in green, with double-click to edit to make them permanent, just as LC and Dewey are now?

43 - I think that's a good idea. Have the suggestions in some other color, or gray, or something that helps distinguish them.

41> I think that's a pretty good summation of the problem, though there's also the issues of people using it for things completely apart from language like in the screenshot I posted.

But the real question is how you would go about fixing it. I'm guessing there's a LOT of these fields filled out with something other than a simple date. It'd be a bear to get it all sorted out, even programmatically (which usually just lets you make more mistakes/sec). The language specific ones might be an easy case, but anything more complicated starts being... well, more complicated.

I like this feature very much. Thank you!

Author CK is now in the system.

It's a great feature!
However, the fields for birth places and death places have disappeared. I entered quite a lot of those; all for nothing?

Hmmm... I'm logged in to the english site. When I call up http://www.librarything.com/author/alighieridante-1 and click Dutch (9) nothing actually seems to happen, i.e. no Dutch CK shows up, and the legend opposite 'Relationships' says 'Information from the Portuguese (Portugal) Common Knowledge. Edit to localize it to the English one.' which is another clue we haven't switched away from English.

However, the fields for birth places and death places have disappeared. I entered quite a lot of those; all for nothing?

I'm seeing them all over (eg., http://www.librarything.com/author/careylisa). Where aren't you seeing them?

When I call up http://www.librarything.com/author/alighieridante-1 and click Dutch (9) nothing actually seems to happen

The click now works. Thanks.

I hadnt noticed yet, but henkl is right. I'm no longer seeing birth places and death places either - anywhere. (Not on your example either).

>50 timspalding: I don't see them anywhere, not on the page of Jacob Groot (where I first discovered the new feature), nor on the page of Wiljan van den Akker, where I added birthplace yesterday, nor on Lisa Carey's page. I do see date of birth, date of death and places of residence, but not place of birth or place of death. When I click on "view history" on Wiljan van den Akker's page, I can see that I did enter his birthplace.

Okay, try now.

Thank you, Tim.

Ugh, that multiple original publication dates thing is one of my pet peeves. I'm not sure I've ever seen a case where I've thought it's made sense to have more than one date.

It makes sense for omnibuses; dates for the parts and the whole.

I think it makes sense in a lot of cases. For example:
Alice's adventures in Wonderland was first published in 1865, but Alicia in Terra Mirabili - separate because of the dead language exception rule - was first published in 1964. I kind of like seeing both dates on the latter.

> 55: Omnibuses and other compilation works really ought to be handled through the works-relationship feature. IMO, "Original publication date" still ought to refer to the "work" -- in this case, the omnibus volume, or whatever. Yes, I know that data is of less interest than the OPD of the included works, but if the works system is to maintain its integrity, then the CK data ought to be about the work. Which is the omnibus/anthology/etc.

> 56: The dead language exception rule is an exception, which means that everything related to it is exceptional. So I don't think that it really counts as a decent example.

> 57: Yes, fair enough, it is an exception. But there are many of these around on LT - Asterix and Harry Potter in Latin, Peter Rabbit in hieroglyphics, etc. Just pointing out why I would hate to see this limited to field that couldn't have multiple entries.

#57: Once you get to Alice's Adventures in Wonderland (pop-up book), Alice's Adventures in Wonderland (Norton Critical Edition), Alice's Adventures in Wonderland and other stories, I don't think Alicia in Terra Mirabili is all that exceptional. Even the works relationship feature, when it comes, won't handle all the cases; Selected Poems of Burns having an original publication date of 1962 is a little misleading and unhelpful, even if all the poems are sub-work.

I like having dates for OPD in different languages. I like to know if there has been a short or a long time for a translation to appear.

There are fields on the author page that can be shared across languages: Date of birth, Date of death, and Gender. Possibly Legal name?

No, dates can not be shared. There's over a hundred years of history with different dates in different parts of western Europe, two hundred more with differences between western Europe and Russia. "BC" and "AD" (or whatever you prefer) are not used in other languages. Sometimes there are comments attached to the dates - Shakespeare has one about the 23rd of April being a supposed birth date.

Open/Closed CK now fixed.

Now I'm seeing notices like :

"Information from the English Common Knowledge. Edit to localize it to the English one."

Which isn't really a problem, but slightly weird.

62:
Ok. Any reason for not sharing Gender?

#64: And if you edit it, you get two english (n) sections above the CK fields.

>64 Nicole_VanK:

Should be fixed.

>62 andejons: :Take a look at Michaela Morgan for instance - #2 is really Michael A. Morgan.

Okay, I've fixed a rather serious bug--the bug that was creating new "English"-es when you edited the CK on author pages.

The problem was that the language was being entered wrong. It was being entered as your user number, not as the language.

There is, unfortunately, no way to restore the 800 edits that were made in this way. I can't know what their language was, pure and simple. I will work on a tool for members to see them, and re-add them, choosing the language.

See http://www.librarything.com/topic/108110