External player choice 'None' translated in Settings

[9ekaitz]

---

External player choice 'None' translatable in Settings

Important note
We may remove your pull request if you do not use this provided PR template correctly.

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

• Bugfix
• Feature Implementation

Related issue
closes #1670

Description
Enables the translation of the word 'None' in the external player selector in the Settings menu. In order to do that the name of the first player is changed from 'None' to a translatable string and the whole array of names is translated. (Only the 'none' one has a translation, the other ones remain the same)

Testing (for code that is not small enough to be easily understandable)
Just tested if the word is substituted by the one on the locales file

Desktop (please complete the following information):

• OS: GNU/Linux
• OS Version: Pop!_OS 21.04
• FreeTube version: v0.16.0 Beta

Additional context
Is the first time I contribute to a project and also the first time using Vue, and haven't done a lot of things in JS, so if there is anything wrong with Vue or the format of the code tell me and I will try fix it

[PikachuEXE]

@PrestonN ?
The import of i18n is removed already

[ChunkyProgrammer]

maybe a different key should be added called "translated" that is a bool value and the translating part of the code will only use the "$t" function if translated is true to avoid warnings from this PR

[PikachuEXE]

Now I notice that the other names are not translated

[PikachuEXE]

Another way I can think of would be

this.$te(value) ? this.$t(value) : value

$te checks whether the translation key exists

[ChunkyProgrammer]

Another way I can think of would be

this.$te(value) ? this.$t(value) : value

$te checks whether the translation key exists

that's probably the better way to do it. was not aware of the te function

[PikachuEXE]

Let's use $te then

[9ekaitz]

Let's use $te then

Should I name the null player "None" or keep the changes and name it with the translation key "Settings.External Player Settings.None"?

[PikachuEXE]

I think the "name": "Settings.External Player Settings.None" can be kept
And expect it to keep either the name, or the translation key
If there is no translation entry for the value, we assume that's the name (without translations)
And to do that we update
return this.$store.getters.getExternalPlayerNames to

return this.$store.getters.getExternalPlayerNames.map((value) => this.$te(value) ? this.$t(value) : value)

(Please test before committing, coz I haven't :P)

[9ekaitz]

I think the "name": "Settings.External Player Settings.None" can be kept And expect it to keep either the name, or the translation key If there is no translation entry for the value, we assume that's the name (without translations) And to do that we update return this.$store.getters.getExternalPlayerNames to

return this.$store.getters.getExternalPlayerNames.map((value) => this.$te(value) ? this.$t(value) : value)

(Please test before committing, coz I haven't :P)

It works fine with the other players but the null one appears as Settings.External Player Settings.None in the languages in which it is not translated. Not sure if that's a problem

[9ekaitz]

It works fine with the other players but the null one appears as Settings.External Player Settings.None in the languages in which it is not translated. Not sure if that's a problem

I think it is because the $te detects that it is not translated and instead of fallbacking to English it puts the name that is in the json (Settings.External Player Settings.None)

[PikachuEXE]

I made some changes on my own branch
https://github.com/PikachuEXE/FreeTube/tree/feature/translated-player-name

Some screenshots:
When using zh-tw (with test translation Nein)

When using jp (without translation)

When using en (with translation)

Let me know what you think

Edit: The commit is PikachuEXE@410ff60 in case you want to look at diff

[PikachuEXE]

Tested locally
Took me sometime to figure which one is es

[ChunkyProgrammer]

@PrestonN looks like you might need to approve this one for it to get merged