Cast corrections to Harriet declined

  • 1
  • Problem
  • Updated 2 months ago
  • Solved
It's a little frustrating that it is so easy to correct casts for television episodes and so hard to correct them for movies. I submitted 3 cast corrections for Harriet to match the onscreen credits and 1 to make an uncredited member follow the format of the credited casts. The submission was 200422-193844-431000.

First, Antonio J Bell is credited as "Antonio J. Bell" with the period as you can see below. This one baffles me because I am easily able to add this attribute for him in television episodes.


The next one is a complete obmission. William L. Thomas is credited as "Senator Seward" in position 39 (which there is currently no actor with that order number). Also, in the picture below LondonRose Sellars is credited as "London Rose Sellars" with a space between "London" and "Rose".



Finally, there is an uncredited cast member who's credit looks like this: 

DeVaughn, Arykah Naomi   Angerine 2yo/3yo  (uncredited)

As you can see above, this movie lists ages just in parenthesis so it should look like:

DeVaughn, Arykah Naomi  Angerine (2/3)  (uncredited)
Photo of Adrian

Adrian, Champion

  • 1645 Posts
  • 1981 Reply Likes
  • frustrated

Posted 3 months ago

  • 1
Photo of Phil G

Phil G

  • 189 Posts
  • 415 Reply Likes
...so it should look like:
DeVaughn, Arykah Naomi Angerine (2/3) (uncredited)
I'm surprised you haven't paid more attention to the guidelines for punctuation in character names. Parentheses should be avoided, but more importantly, the slash forces IMDb to treat this as two distinct characters, one called "Angerine (2" and the other called "3)".

I haven't got an example to hand, but I've seen cases where IMDb chooses to display multiple roles like this in a different order to the way they were entered, so aside from being technically wrong, there's also no guarantee that it will display correctly.
Photo of Adrian

Adrian, Champion

  • 1645 Posts
  • 1981 Reply Likes
The parentheses and slash were already in the credit. Nothing in that changed. I just removed the yo because this cast does not use it. It also uses the parenthesis before age. It will display correctly as you can see if you click on the page and see how it is now.

Also, IMDb's #1 guideline is to display as displayed on screen. Since this is uncredited and doesn't appear on screen, I feel it should be displayed like similar credits show on screen.
Photo of Phil G

Phil G

  • 189 Posts
  • 415 Reply Likes
The parentheses and slash were already in the credit. Nothing in that changed.
But it should be changed to meet the guidelines. You know as well as I do that just because it was accepted once, doesn't make it right.
It will display correctly as you can see if you click on the page and see how it is now.
By luck, not design. As I said, I've seen other cases where it doesn't work as you expect.
Also, IMDb's #1 guideline is to display as displayed on screen.
As I've reminded you before, there are numerous exceptions to that guideline.
Photo of Adrian

Adrian, Champion

  • 1645 Posts
  • 1981 Reply Likes
I'm not going to continue this conversation. Credits should not be changed from onscreen to suit arbitrary guidelines. IMDb staff have been pretty clear about this.
Photo of Phil G

Phil G

  • 189 Posts
  • 415 Reply Likes
IMDb staff wrote the guidelines that you're choosing to ignore. But I'll say no more.
Photo of Michelle

Michelle, Official Rep

  • 13256 Posts
  • 10620 Reply Likes
Hi Adrian -

I have verified the credit changes you requested and approved them, the changes should be live on the site shortly.

Cheers!
(Edited)
Photo of Phil G

Phil G

  • 189 Posts
  • 415 Reply Likes
Michelle, I'd appreciate it if you would address my concerns here about the misuse of punctuation in character names, please.

If this was just about parentheses, I wouldn't bother making a fuss. But the slash is much more important: getting that wrong means actively corrupting the database. Perhaps I should have explained this more clearly last week.


From the guidelines:
Slashes should be used only to separate two different characters played by the same actor.
This is not just a vague convention that can be followed or ignored as contributors feel like. The slash has a very clear and significant meaning to IMDb, and the software processes credits differently based on that. When a slash appears in a character name, the software splits the credit into distinct characters, and processes and stores each character separately.

When a slash is included for any other reason, it creates two (or more) distinct characters where there should only be one: not the intended result, and this data corruption causes various further problems.

The issue manifests in many ways across the site, some more subtle than others, but is perhaps most clearly demonstrated in the datasets. For example, in title.cast.tsv.gz, the line for the credit discussed above (pre-update) looked like this:
tt4648786    72    nm10265218    actress    \N    ["Angerine 2yo","3yo"]    \N    ["uncredited"]
Notice that the credit is treated and stored as two distinct characters: anyone using the datasets to query how many characters this actress played immediately gets the wrong answer. And the implications of this data corruption go much further than just the datasets. Try adding a quote involving this character and because of this bad data, you'll have to jump through extra hoops to get the character name included as intended. That's just for starters; I won't try to list all the problems that can be caused by this.

Adrian is quite happy with the way this credit currently displays on the site, but I maintain that this is by luck, not by design. If IMDb decides to change the display logic for multiple roles, then this credit could easily be messed up. For example, in future, characters could be listed in alphabetical order; or each character on a separate line rather than side-by-side. How would this credit look then? Including a slash in the character name, tells the software that these are distinct characters that can be handled separately. Therefore, the software has no obligation to always display them side by side, in the same order, with a slash between them. It's free to display one or both, together or separately, in any order, with anything or nothing between them, or even in different colours, etc. When the underlying data is wrong, correct display cannot be guaranteed.

Photo of Adrian

Adrian, Champion

  • 1645 Posts
  • 1981 Reply Likes
Good to see you back Michelle.