Revision as of 11:43, 13 December 2010 by Uzume (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

It's a good start, but we'll need to separate requirements and design issues. I'll give it a shot later in the week unless someone else gets to it first. Ahasuerus 14:42, 14 June 2010 (UTC)

Maybe it is just me but this seems a little overkill for a good working multilingual support. I admit the current mechanisms of using the name of a publication (AKA pub_title) or the currently unused title_translator fields are inflexible and inadequate (and I am not sure how the title_relationships translation_id is supposed to work). That said, I do not see the significant benefit of adding language fields to author records. Title records (which are really literary work/potential publication contents records) already allow "variant" linking. So far this "variant" linking is really only used to specify an alternate title_title and possibly a different set of authors (e.g., a pseudonym) which I am not sure if really the right thing (since the current "title" record is logically a literary work record and not just the name of such a work) but it currently suffices. A translation is actually a separate derivative literary work so the current "variant" title mechanism seems perfectly suited for such use. The only thing that needs to be done is to specify the language(s) of each literary work (aka title) and possibly specify how things should be displayed and accessed, etc. The title_language could be specified as an enumerated type or with a separate languages table and appropriate linkages but if one wants to support the ability to specify multiple languages within a single literary work it methinks it best to make a separate languages table as well as title_languages table to link the languages to the titles allowing many to many linkage. And of course make sure to delete (after making sure such are converted and no longer used) the title_translator and translation_id fields from the applicable tables. I prefer this approach over what is currently proposed. Some of the proposed display and access concepts are good however. If the current proposal is considered deprecated I could perhaps try to write up my ideas here more formally. Uzume 20:45, 12 December 2010 (UTC)

I am glad to see that there are people who are interested in this topic! :-)
The reason why "author languages" were proposed is the existence of Collection and Omnibus titles which have no corresponding Title record in the original language. It's not uncommon for foreign publishers to put together reprint omnibuses and collections of an author's novels and stories that are not "VTs" (variant titles) in the sense that we use the term. The addition of a "language" field to the Title records (in conjunction with the previously implemented list of user-specified languages) will enable the display logic to decide whether to show a particular VT, but it will have no way of telling that a French/Polish/etc collection of Silverberg's works needs to be suppressed. The only way around it (that we could thing of) was to add a new field to the Author table to let the logic know that Silverberg's "working language" is English, so non-English canonical titles shouldn't be displayed unless they are listed as "preferred" by the user who is viewing the page.
There is a lot more about this issue over on the main design page, although some of it has probably been resolved by now. Ahasuerus 23:57, 12 December 2010 (UTC)
Thanks for the pointer. BTW, I turned your link into an internal wiki link vs. and external. Uzume 15:43, 13 December 2010 (UTC)