Localization inconsistency fix for Local API

[MarmadileManteater]

---

Localization inconsistency fix for Local API

Pull Request Type
Please select what type of pull request this is:

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue
closes #2530

Description
This applies a workaround for the inconsistency in the responses from ytdl and ytpl. The result of this change is that the video title and description are localized to en-US by ytdl (as it was expected to be based on the following code snippet).

// line 353 of src\renderer\store\modules\ytdl.js
ytdl.getInfo(videoId, {
        lang: 'en-US',// this locale was not being honored before this change
        requestOptions: { agent }
      }).then((result) => {
        resolve(result)
      }).catch((err) => {
        reject(err)
      })

Screenshots (if appropriate)
Before this change:

After this change:

Desktop (please complete the following information):

• OS: Windows 10
• OS Version: Pro Version 21H2 Installed on ‎4/‎3/‎2022 OS build 19044.1889 Experience Windows Feature Experience Pack 120.2212.4180.0
• FreeTube version: 0.17.1

Additional context
The inconsistency described in #2530 still occurs when using the Invidious API; however, as far as I can tell, this is an issue with invidious. Even if we aren't sending a locale, it should give back titles and descriptions that reflect a consistent locale, but I don't believe there is a way to fix that inconsistency without digging into the invidious source, and at that point, it isn't an issue with FreeTube.

[MarmadileManteater]

I just approved the change to using .join for the description, but I walked away from my desk, and the more I thought about it, the more I realized it won't work because the array contains objects with a field named 'text', not strings.

[MarmadileManteater]

I feel like these were all very good changes. I see the merging is blocked because 1 review is requesting changes, but I believe that I reviewed all of the requested changes. I can make more changes if it is necessary. I am just checking in on where we left off on this.

[absidue]

Hi @MarmadileManteater

Sorry for the delay, at the time I had finished the code review but hadn't tested the code yet.

While testing I noticed that it spits out the fallback error if the video is missing a description (second video in the playlist in your issue), one easy way to fix that would be to check if there is a non translated description (empty string) before doing the whole try catch stuff. Ideally we only want the error being logged if it legitimately failed to extract the translated description (not being able to do it when there is no description is expected behaviour).

[MarmadileManteater]

Hi @absidue,

You are exactly correct.

Looking at the error, I believe it might just be easy enough to use optional chaining on the description property. Then, descriptionLines would be assigned the value of [], and this would make videoDescription a blank string.

// Adding a ? to line 310 of src\renderer\views\Watch\Watch.js
const descriptionLines = result.response.contents.twoColumnWatchNextResults.results.results.contents[1].videoSecondaryInfoRenderer.description?.runs
this.videoDescription = descriptionLines?.map(line => line.text).join('\n') ?? ''

[absidue]

Looks good to me now. Thanks!

[PikachuEXE]

Code looks fine but how do I test the behaviour locally?

[MarmadileManteater]

These are some examples of videos I have collected of where this code changes the behavior:

• uGQWZCVFJe4, QtLMR7K69Mc, 9mz_HwlAurw
• HtBqK6xsQ9k, NkBq2bYuvJI, KushW6zvazM, hxSg2Ioz3LM (these are all from searching for "deco*27 feat hatsune miku")
• CAnHY-9juA0 (the video locale is NL but it has an en-US localization available; i also created this one explicitly as an example)

It would also be worth testing some videos which have a default locale of en-US because nothing should change for those videos . . . wait

I just noticed a problem. There are extra new lines that shouldn't be there.

It looks like there is already a \n character inside of each line that needs it, so we just need to join by "" instead.

[ChunkyProgrammer]

Hopefully we won't have to hardcode en-us in the future and will be able to respect user's locale preferences