[zag]

How about this?

https://musicbrainz.org/doc/Style/Unknow...ose_artist

https://musicbrainz.org/artist/eec63d3c-...147d4d2b61


EDIT: Mb guys recomend using [unknown] artist
https://musicbrainz.org/artist/125ec42a-...57484327fe

EDIT2: Sorry didn't read the first post! Generally speaking, artist names are not translatable.

[DaveBlake]

The question of allowing for language settings in the name held in the artist table for the "missing tag" artist.

It makes total sense to me for the database to adjust this record to the current language settings. This means that if the skin or any API consumer decides not to apply special processing for this invented artist, and there is no reason that they must, then the user sees something appropriate by default.

Unlike VA there will only ever be one invented artist of this kind. But I do not suggest we attempt to use that name to identify that artist for processing, that needs the core to give the artistid.

[Tolriq]

It makes total sense to me for the database to adjust this record to the current language settings.

Well you just forget that Kodi support profiles with shared media info but different GUI language.

Anyway as I said the GetMissingArtistID mroe or less fit remote needs even if hacky they can at least translate.

Display problems in Kodi is something else out of my request, and potential future problem if profiles are extended in Kodi too.

I think it's my duty to inform about that since maybe you do not known everything in Kodi that's all. And this was the main point from day 1.
(https://github.com/xbmc/xbmc/pull/9081#i...-182299394 when just enumerating possible solutions)

[DaveBlake]

OK I had not considered the effect of profiles.... I will come back to that.

I'm personally completely happy for this invented artist always to be stored and passed to the UI and API in English, hard coded as "[Missing]". Is that what you want?

I don't see any current mechanism for skins to translate library data at UI level. So until someone implements that, I propose that having the database offer something language setting sensitive is a reasonable approach. UI level translation can then replace it when that is available.

We are talking about 1 artist record in possibly thousands, it is possibly always going to be more efficient to modify that record when the language changes than test every record displayed and apply a translation at the UI or in CFileItem

So user profiles - a record update when the language changes should be possible. I am not familiar with the profiles implementation so will need advice. I know that swapping profiles on my remote meant starting over, so surely a record change would fit. Meanwhile it still seems better to me not to force English on everyone, and hope a skin or remote eventually fixes it.

To me the real flaw with my approach lies with having the music library on a server with many users and different language settings. I'm sure they exist, but are they sufficient to be a show stopper?

[Tolriq]

As I said this is not show stopper at all. You really want to see me saying things that I don't.

I just inform about the problem with current approach, and did warn about the impact that's all, if there's no way to do it correctly, then a workaround is of course welcome as long as this is not breaking things or current conventions of course.

And since we had long discussion about making Kodi code better, I find normal to report this and alert about future impacts or unseen ones.

From remote point of view fixed ID sounded better, because it's easy to intercept and translate at display time. The GetMissing... also does the trick at the expanse of one more call. (And IMO fixed id sounds easier for GUI / addons translations too but I have no real clue about that)

Having the API returning the data in English is better also in the same principle as API not dependent of Kodi settings, but since I know nothing about Kodi GUI maybe this is not possible to distinguish the 2 cases and translate for GUI.
(Think about dates returned by JSON they are all standard and not formatted according to Kodi language, time are on 24h, Global.Weekday are in English, ....)

About profiles : http://kodi.wiki/view/Profiles, profiles can have shared media info and sources, and not always start from scratch with a new DB. This is more common than central DB I think.

[DaveBlake]

It wasn't saying you said it was a show stopper, I was asking what you thought given my realisation about libraries on servers in simultaneous use. I do see design as a community enterprise, not a solo quest or battle!

Re profiles my first attempts with them was to try and split my pop and classical music, I found switching via remote inconvenient as I had to use TV to see to log on as connection to remote was lost, and so I abanndoned it. Maybe there is a better way now with profiles, but that is what I meant by starting from scratch, I meant starting remote sync etc.

But we digress yet again! At lest it is on the forum not Git and pissing off everyone else.

Keeping the API independant of Kodi settings makes sense, and the time format analogy helpful. I would like to hear from a few of the other API consumers before I am totally convinced they all want only English. I suspect some may want the option to have what the Kodi UI gets, but see if we can get them to speak for themselves.

Meanwhile back to the issue of dynamic translation at UI or the layer below (but not in DB). Best thing I can do is implement something and see how significant optionally "formatting" the artist name to translate "[Missing]" in to the live language setting is to timimg.

[Tolriq]

Maybe there is a better way now with profiles

Json now allow switching profiles, but there's still Webserver down when no profile logged. So this feature is more or less useless for all users that power on / off their kodi without auto login of a profile

I really hope a solution for that is find one day. (Well more a decision problem than anything else from previous discussions)

I suspect some may want the option to have what the Kodi UI gets

IMO this needs a larger approach to be handled and correctly managed There's lot's of things that needs this same approach to really have a full api.

And this is complicated to manage because of http part that is not manageable as session to set session setting. (This is more or less the same problem as authentication and permission levels we discussed earlier with Montellese)

There's also things like Keymaps, advanced settings for example should be accessible from remote so they can adapt their function to mimic Kodi. Currently for example you can sort without articles but you can't get that tokens list.

But all that IMO out of the scope of this simple PR