plot-english and plot-french together for the same movie

[jluc2808]

is not in scope right now; could be an enhancement for later (not too far , please).

comments from @modmax : This needs an extra table where you can store localized plot and outline for a specified language. The plot in the videodata will then be that with the highest prio (according to priorities check, comment from jluc2808 and priority language). Other plots will then be stored in the localized table. Just to get around with the issue if you use 2 scanner which are scanning for the same language (i.e. imdb and tmdb as default or vice versa).

[jluc2808]

modmax: yes surely you need an extra table, but we have to consider a lot of field with foreign language or multiple value

• name of the movie
• outline
• genre
• rating (from several site rotenTomato,.....)
  .....

could that mecanism be used for every situations

[modmax]

This is not realizable now, cause the language depends on the scraper and what locale (normally the system language of your YAMJ installation host).

For allocine it's clear: language = fr
Also fpr ODb, where german text is returned

But IMDB and MovieDB and perhaps also TheTVDB are different.
If you pass in the locale "de_DE" this doesn't mean that you get the title or plot in the desired language. The response to the API calls doesn't return the language infor for each field.
And even if you request de for a movie, then you can get the title in english whichis used as fallback, when the information is not present in the desired language.

[jluc2808]

i understand the explanation about site return, which aren't everytime exactly the language asked , but the request is fully known with a language selected , so for me the return setting could be stored with the asked language by default , for each field, and the return language if known .

the original issue point that there is only one field to store plot (or any other value scrapped from a site) , this couldn't allow to select any argument to select a plot (or anyother field scrapped) , this is a big limitation from yamj v2 , which could be overwritten in yamjv3 , by adding scrapped field depending of the site/language and let skin ask for the one needed