New: add `language` QSP to the /movie API endpoint
Database Migration
NO
Description
When implementing some automation tools, it is important to have consistent movie naming independently of the language that the radarr users have configured. For this purpose, I added a new QSP language to the /movie endpoint to return the results in whatever language you prefer.
Examples
-
/api/v3/moviewith Metadata Language set toFrench:{ "title": "Harry Potter à l'école des sorciers", "originalTitle": "Harry Potter and the Philosopher's Stone", ... -
/api/v3/movie?language=spanish{ "title": "Harry Potter y la piedra filosofal", "originalTitle": "Harry Potter and the Philosopher's Stone", ... -
/api/v3/movie?language=non-existingThrows exception
Todos
- N/A Tests
- N/A Translation Keys (./src/NzbDrone.Core/Localization/Core/en.json)
- N/A Wiki Updates
Didn't we agreed on Discord on using the language from a query argument?
Please let me know if you want a better invalid language exception, like so:
{
var movieStats = _movieStatisticsService.MovieStatistics();
var translationLanguage = language != null
- ? Language.All.Single(l => l.Name.Equals(language, StringComparison.InvariantCultureIgnoreCase))
+ ? TryOrThrowError(
+ () => Language.All.Single(l => l.Name.Equals(language, StringComparison.InvariantCultureIgnoreCase)),
+ $"Invalid language '{language}'")
: (Language)_configService.MovieInfoLanguage;
var availDelay = _configService.AvailabilityDelay;
var movieTask = Task.Run(() => _moviesService.GetAllMovies());
+ private static T TryOrThrowError<T>(Func<T> func, string error)
+ {
+ try
+ {
+ return func();
+ }
+ catch
+ {
+ throw new Exception(error);
+ }
+ }
I would rather go with something like Language.All.Where(l => l.Id > 0).FirstOrDefault(...).
I think we should find another solution for the lookup to not use the language names...
https://github.com/Radarr/Radarr/blob/3db78079f37ecf0d528d46d1ee7d25ce127a2065/src/NzbDrone.Core/Languages/Language.cs#L8-L11
Hey, I updated the code to exclude non-real languages with Id > 0.
I don't see any issue with using language names as both names and ids are hardcoded and reachable via the api. Language name avoids that extra API lookup to get the ID, whatever you prefer, really
Hey, yeah, we should rather go with the language Id instead being an integer.
Hey, yeah, we should rather go with the language Id instead being an integer.
done!