Hi @banjocat,

As you may have seen, we recently launched support for translated person names. Before adding this support, all person names were assumed to be "English" (no matter what language you requested), so in the case of the Japanese and Korean examples, you would get the the romanized version back. It's all we had.

The problem you're describing is no different than how movie and TV show requests work; if there is an available translation we return it, otherwise it simply falls back to the "original name" or "original title".

I think what you're actually asking about is really the desire to send a fallback language as part of your request. We have an open ticket for that here.

I just want to stress that the real "issue" here, is no different than how movies and TV shows have always worked. The work to bring translated person names to TMDB was long overdue, and now all three media types (movies, tv shows and people) behave the same way.

I appreciate the efforts to enhance support for person names across different languages. However, there seems to be a misunderstanding regarding the distinction between transliteration and translation.

Names undergo transliteration, not translation, when converted from one script to another. For example, the Japanese name "木村拓哉" is transliterated into English as "Kimura Takuya," representing the sounds using the Latin alphabet.

Consequently, it's crucial to return a person's name based on the script of the language the user is utilizing, rather than solely the language itself. If a user is browsing in French, they would expect to encounter the Romanized version "Kimura Takuya." Presenting the untranslated name "木村拓哉" would be misleading since a Romanized (English) version exists and would be more meaningful to a French speaker.

Thank you for considering this perspective.

Correct, in the case of people we're talking about transliteration. The way people are edited is different than how it works with movies and TV shows for this reason. On the website, we've also changed what is known on the API as original_name to "stage name" which I think is more appropriate. But obviously we can't make such a change on the API without breaking every single client using our data.

But that doesn't change the core problem I'm talking about. We don't have any way to fallback to any language when the one you've requested isn't available. This is a API wide limitation.

Thank you for clarifying. While transliteration is often available, the issue stems from its current limited availability, primarily in English, rather than being universally accessible across all languages that use the Latin script. Implementing a fallback language mechanism would indeed be a significant step in addressing this concern.

This change demonstrates a severe lack of empathy for non-English users. Instead of providing names in familiar Latin characters, users now often encounter scripts they may not be able to read. This effectively turns transliterated names into an English-only feature, unless someone manually copies and pastes the names from the English 'translation' into all the languages that use the Latin alphabet, which is not a feasible solution.

This change adds support for translations specifically for non-English users. How exactly is that a step backwards?

These 'translation' are often limited to English, despite the transliterated names being consistent across languages that share the Latin alphabet. This effectively creates an English-centric approach, neglecting the needs of users in other Latin-script languages who could otherwise benefit from the same transliterations.

The core issue is that the current system prioritizes falling back to the original script of a name, which is often unreadable for users who don't know that script. A more user-friendly approach would be to fallback to a Latin transliterated name (like the English version) whenever a translation in the user's preferred language isn't available.