@backupluis said:

Hi, I have a problem that happens from time to time, and now I have the data because I just track it. Sometimes from my php code Movie data is returned in English and if I open the same link on the browser, data is returned in Spanish (as requested), the link have the language set to es (lowercase as returned in Configuration/GetLanguages), for example today happens with "The Queen", this is my url:

https://api.themoviedb.org/3/movie/1165?api_key=myapikey&language=es

In php I use file_get_contents, if I open that URL from php, english movie data is returned, if I open on the browser, spanish movie data is returned. But if I use ES (in uppercase) Spanish movie data is returned.

Resuming:

• The same URL returns different data from php or from firefox.
• The api doc says for Get movie/id/ language must be passed as ISO 639-1, min 2 chars
• GetLanguages returns "iso_639_1": "es"
• If I use iso_3166_1 "ES" works well

Any idea?

When I read the language parameter instructions I see that it is a little contradictory.
https://developers.themoviedb.org/3/movies/get-movie-details

language
string

Pass a ISO 639-1 value to display translated data for the fields that support it.
minLength: 2
pattern: ([a-z]{2})-([A-Z]{2})
default: en-US

The instruction asks for ISO 639-1 only but the example is ISO 639-1 - ISO 3166-1.
I always use the example. In case:
https://api.themoviedb.org/3/movie/1165?api_key=THE_KEY&language=es-ES
See if this solves your problem.

EDIT
I'm not sure, but I believe that this problem came into being when some languages started to have a country-specific configuration.
Before there was only pt. Then pt-PT and pt-BR came into existence.
The same with Spanish. Only es and then es-ES and es-MX.

Maybe I don't explain well (English is not my primary language).

• There is an inconsistency in the api between calls from a Browser and from a source code (php) for the same URL. (THIS IS A BACKEND PROBLEM). No workaround, the same URL should return the same result (except noted) from different clients.
• Some days the data returned it's ok some others not FOR THE SAME MOVIE from the source code (php) using the same URL. (THIS IS ANOTHER BACKEND PROBLEM).

Yesterday I got English result for "es" and today I have "Spanish" results for es (the same testSpanish.php script, no proxy, no cache).

If I use your proposed way "es-ES" and there is NO info for es-ES, it will fail back to English, the same for Mexico or Argentina, reading the api info, I understand that es will cover any country with Spanish. I just test for es-AR for Argentina and give me results in English, testing with es-MX give me in Spanish as the same for es-ES. So, there is no warranty that es-ES will give me Spanish results if some one enter info for es-MX and not for es-ES, or we need a way to know witch country is MORE important than other to fetch localized data (This is ironic).

Maybe you can check with somebody on the backend side about this problem, this is not the first time I have this problem, but before I forgot to note the movie and track the problem.

Regards Luis

English is also not my native language.
To make matters worse, I'm not a programmer.
So there is probably confusing information ahead.

Other users have reported similar problems.
Browser response different from APP response.
In these cases my recommendation was to use ISO 639-1 - ISO 3166-1.
But your case is different.
The answer changes from day to day, with a Request sent by the same system, same way.
What I can ask is that you test if, sending the Requisition with es-ES, this problem still continues to occur.
Anyway, I am not going to be able to solve this problem. I believe that only Travis Bell can clarify the issue.

As for Fallback, the default language is en-US.
In the case of languages ​​with several countries, I believe that only one country-language will be used.
In this case only es-ES. Es-MX will never be used as Fallback for es-ES or es-AR or any other variation.
But, that question is the subject of a To-Do. I ask you to read this ticket:
https://trello.com/c/UV1IGYfN/3-add-support-to-fallback-translation-queries
And enter the links available there. And see if anything can help or clarify.

And let's hope that Travis Bell joins this conversation.

I'm brooding over this issue in my head. And trying to remember the changes.
I will use the Portuguese language as an example.
In the past, only pt.
When the division by country was created it looked like this:

• pt-PT = inherited everything that existed in only pt.
• pt-BR = was created and inherited nothing.

Thus, pt-PT would be the natural Fallback.
But, that's just what I suspect, pt-PT will be Fallback only when
using a language-COUNTRY definition that doesn't exist in the system.
Example:
pt-XX Fallback pt-PT
pt-YY Fallback pt-PT
pt-AO Fallback pt-PT (Angola)
pt-MZ Fallback pt-PT (Mozambique)
pt-TL Fallback pt-PT (East Timor)

But, if there is then ...
pt-BR Fallback en-US

Remember, it is just a memory effort. Certainly Travis Bell will correct the nonsense I wrote.

Thanks Ticao2 for your responses.

Today I have Spanish results for "es" again, which is correct (same movie, same code), but I know that fails from time to time, or have failed before, now I'm ready to catch another language confusion and I will post here when I found another one. MAYBE there are some cache between me and the servers, maybe the servers have cached an old result, then after my firsts request the result was updated, I don't known, just thoughts, but there are no cache nor proxy in my ISP/local network.

Well, about the different responses for browsers and code, its because browsers send additional headers that can be interpreted by the backend, something that is not good from a programmer point of view, anyway I'm here to learn not to judge.

If pt-PT or es-ES are the "masters" for suchs languages, the API should let us know that, but when you call the getlanguages only pt or es (between others) are returned, something is missing here, maybe they can add a "master" country to the same getlanguage as a json property for each entry and update the docs for language parameter for, for example movie/getdetails?language=, maybe with something like this: ISO 639-1 [- ISO 3166-1], language[-country].

To solve the problem that I found, in my case, I will put a checkbox to force not to cache the result, so the user (Only me) can request the data again to the server if the data was not in the right language. Something that will not be elegant, not only for the checkbox or for the additional requests to the site, because I have to go manually to the tmdb site to check if the movie has an entry in "Spanish" in my case, then realize that the response was bad and make it again until I have the right result, I remember that it happens to me about 4 time with less than 200 movies, but happens.

Hope that Travis, as you note, check this issue or track logs to know what happened, add some "master" country for language api (or we use the Human knowledge) to put the "master" country in the request, in this case the getlanguages have no sense because we have to hardcode any language-country in our apps.

Will post any future wrong response here and Thank you again for your help.