By my reckoning, then you should not have
show_international_data because it's not an association table between the two, and because you do not want the language column to be filled out for each association between a
Basically if you have 10.000 shows and 20 languages, you'll need 20 x 10.000 versions of the 'language' field filled - lots of redundant data and chance for mistakes.
Also associations tables like that are usually used for n:m relationships and not 1:m and because one shows international data cannot belong to another, it shouldn't be mapped as n:m.
show_international_data should be connected directly to
show with show_id being the FK in it.
Then you can make a
(language_id, language) and have that language_id being the second FK in
show_international_data, which combined makes up it's PK.
So something like this:
show -> show_international_data <- language.
In this manner you can reuse your language table on everything which needs to be localized with a translation/details (international_data) type structure without.
I don't know what recommendations is going to contain, but that might also need to be localized?
show_title will most likely also need to be localized, because titles differ between countries/languages as some countries dub or completely reworks titles of shows. So that title properly needs to be put into international data and thereby removing that table.
Also you can put an original_title on the
show base table.
If you do need to have alternative titles on top of this, then a secondary title table will start to make sense, and then you should - most likely - localize it by having a language_id FK enabling multiple alternative titles per language.