[mb-style] Re: RFV: Translation Transliteration Relationship Type

[Alexander Dupuy]

DonRedman writes:

>I have made a terrible hack to give a better display. The downside is that  
>the names of the values are now tructed to "tranliterat" and "translat".  
>As I said. Terrible :-)
>  
>

In some ways, it's not as bad as my transl{iter}ation hack. I changed 
the attribute name from "transtype" to "transl-at" so that the link type 
in the pull-down is now "is the original track listing of the 
{transl-at}ion." That's a lot of punctuation, but it's a slight 
improvement over the former. However, I'm not really happy with it, 
because most people will interpret that to mean that the second release 
is a transl*ation of the first, when in fact only the titles have been 
transl*ated. I'd suggest something like "is the original un{transl-ated} 
track listing of" to be clearer.

The link phrase in the reverse direction is shorter, clearer, and works 
better in either case: "is the {transl-ated} track listing of." Perhaps 
it would make sense to reverse the directionality of this AR? (That is, 
exchange forward and reverse link phrases - we did this for another AR 
early on in the days of ARs). There are only 60 edits up to the current 
moment (5864247) using this AR, so it would still be feasible to do this 
manually. If we decide to do this, it needs to happen by Friday at the 
latest. Reversing the direction of the AR would make it match all but 
one ("is the earliest release of") of the other ARs in its class, where 
the forward phrase connects the derivative release to the original.

Dustin (Kerensky97) writes:

> I'm not a programmer so if I'm missing something just say so but can't we
> just spell out the full word in the transtype drop down so the chioces are
> "[select transtype] Translation or Transliteration". And the AR choice
> would be "is the original track listing of the {transtype}"?


You're missing the fact that the {words} in the link phrases get 
replaced with the selected value. So if the variable part is "translat" 
or "transliterat", as DonRedman has set up, those have to be the values. 
For options that have only one value, you can use things like 
{additional:additionally} which uses the keyword "additional" and if 
that is present, substitutes "additionally" in the link phrase. This 
could be used for my {iter} hack (not yet on the server, perhaps I'll 
put it up on Friday), to name the keyword "same-language" and use 
"transl{same-language:iter}ated" in the link phrase, so that the choice 
would be "[select same-language]" (and would be left unset by the user 
if the languages where different).

> I want the full translation to english. With the current method I can see
> which is which is the translation between the two identical titles. If
> there is no distinction between the two titles, it's just:
> "is the original tracklisting of the transl{iter}ations: CRAZY ABOUT YOU,
> Crazy About You."
> I have to open both in a new window to find out which is which. The 
> problem
> multiplies with more translations; imagine finding the transliteration 
> in a
> row of 5 transl{iter}ations all with the same title.


I do understand this desire - in fact I felt it immediately when I 
started creating entries. The problem is that getting the "transl*ation" 
information isn't enough. To take the example of Twelve Girls Band 
"Beautiful Energy" album, there are two translations (one into 
English/Latin, and another into Japanese/Latin) which also have the same 
(English) release title. Breaking out transliterations from translations 
doesn't help distinguish these. You can actually see this better on the 
artist page, since it shows the language (zho, eng, jpn) but it's not 
shown in the release relationships.

Now we could add the language as another attribute of the AR (this was 
proposed back in July by Bogdan), but then we would be *really* 
duplicating the release information and introducing possibilities for 
inconsistency - not to mention dumping 800+ languages into an attribute 
tree already groaning under the length of the instrument list!

The only way to really solve this problem is as part of the release page 
server - the web code can easily get the lang attribute from the DB when 
it looks up the title, and display that, using very simple logic to 
decide whether to call it a translation or transliteration. This is what 
I have always been arguing for - I don't want to eliminate the 
distinction between translation and transliteration, I just want the 
distinction to be automatically computed. That enhancement doesn't 
require NGS.

@alex

-- 
mailto:alex.dupuy at mac.com