530 Messages
•
12.6K Points
No roman numeral for dead actors - name page gives dates instead of (II) suffix
I've noticed that the roman numeral disambiguation (eg (II)) for cast/crew is no longer displayed for people who have died. In its place are their dates. For example Jim Allen (II) nm0020653 is displayed as
Jim Allen (1926-1999) on his page https://www.imdb.com/name/nm0020653/?ref_=fn_al_nm_1, with no way (that I can see) of displaying his name with the disambiguation suffix.
This is is a problem if you want to copy and paste his details from one title/episode to another, as I've been doing a lot. It used to be possible to:
- click on his name for the existing title
- this displays his name on his page
- copy that name and paste it to the new title
That works fine for living people, because the name is displayed as (for example) Jim Allen (II) which can be pasted into a new title, but for dead people, the text Jim Allen (1926-1999) is not recognised as a person. The only workaround I can find is to extract the nm0020653 from the page URL and paste this as the unambiguous reference to the person.
Is this another case of style over functionality?
It highlights that there are two very different classes of site user: those who are browsing for information (in which case the dates are probably useful); and those who are submitting information, who need the "name (II)" syntax in all cases, even for people who are no longer alive, because that is the syntax that the submission process needs.
I have a suggestion: the name page https://www.imdb.com/name/nm0020653/?ref_=fn_al_nm_1 should display the name as "Jim Allen (II) (1926-1999)" which satisfies both types of people at the same time - submitters just need to highlight the "Jim Allen (II)" part of the name so it can be pasted into a new title.
While I'm at it, the name-search should accept "Allen, Jim (II)" syntax, since that is how the name is given in the submission-confirmation email; it saves having to modify the name to "Jim Allen (II)" before searching for it. If a name or title is given in a certain syntax in a submission email, it should be searchable using that syntax. Try searching for name "Allen, Jim (II)" or episode title ""Crown Court" (1972) {...Or Was He Pushed?: Part 3 (#5.8)}" - you can't do it and have to seach by title "Or Was He Pushed?: Part 3" or else by going to the series entry "Crown Court" and searching then by season and episode - perfectly possible, but unnecessarily tedious.
Please, IMDB, when making all the so-called improvements to the site (improvements for the benefit of "readers" of the information), remember not to break functionality for submitters.
Col_Needham
Employee
•
5.7K Messages
•
160K Points
5 months ago
@martin_695862 Thanks for the observations. We have flagged these ideas for the appropriate teams as the search technology is still evolving. This was originally raised here but your comments extend across both the search results and the contribution UI, so we are keeping this post separate for the time being.
Note that the solution, as you suggest, is to ensure all of the IMDb search interfaces can locate the correct name(s) and that they provide enough context in the results to disambiguate the person (and to solve the problem without necessarily depending upon roman numerals -- see our reply to @gromit82's post in the previosuly referenced thread above).
Hope this helps.
0
martin_695862
530 Messages
•
12.6K Points
5 months ago
Glad to hear that there is a commitment to allow searching and disambiguation using the formats that IMDB "spits out" eg in the comfirmation email.
Searching by full episode path of the form "Crown Court" (1972) {...Or Was He Pushed?: Part 3 (#5.8)}" is something that has been broken for several years, and was a casualty of an improvement. It would be nice if it could be re-enabled because when locating an episode that has previously been submitted (eg to add or correct information), it is the quickest way of locating the episode without having to search for it from the series and then drilling down to season and episode. This is especially true when an episode title is so common than if you search by episode title, you get lots of irrelevant matches as well as the one you are looking for.
I'm sure searching for "surname, firstname (II)" used to work until very recently - I think it stopped working several weeks after the introduction of the new name page format, so wasn't broken by the introduction of that page format.
The new name page title, with a person's years as opposed to their (I) disambiguation, for people who are no longer alive, is a very recent thing - I'd guess within the last week. That is definitely a retrograde step and needs to be addressed fairly urgently.
0
martin_695862
530 Messages
•
12.6K Points
5 months ago
Another suggestion for an improvement. With a very common episode title, which occurs for many TV programmes, it would be useful if you could first search for the series and then do a search for episode title(s) that only relate to the series, so as not to find all the episodes for other series. Here's an example: I know that there is an episode of "Casualty" (1986) called "Hide and Seek" but I;ve no idea which season it's in. I want to find it by its episode title. If I search for episode title "Hide and Seek" I will find loads of matches to other titles as well as to episodes of Casualty. Being able to ask (effectively) "show me all the epsiodes of Casualty which are called Hide and Seek" would be a nice enhancement.
While we are talking about searching, I've noticed a bug. Normally, the search field in the top bar displays two boxes: one is a drop-down with values such as "All", "Titles, "TV Episodes"; the other is the field where you type what you are looking for. In some situations (and I've not managed to work out what provokes it) the drop-down is missing so you can't restrict your search to episode titles or person's names, and must (effectively) do an "all" search. Only when that has returned lots of irrelevant matches is the drop-down displayed, allowing a specific search. Sorry to be vague, but it happens so rarely that it's difficult to know how it happened, or to be able to provoke it to show a screen-shot here.
(edited)
5