#musicbrainz-devel

yes, but in this case, both aliases have locale="en","Artist name" and no primary, so Picard picks one at random

Michael thought it was fixed by its patch (PICARD-200), but i just wrote few tests, and it just depends on order in xml

on MB side, there is not much point to have an alias==artist's name

Wrong.

why?

artist names don't have languages

so having an alias is more correct

It can carry a locale, and a different sort name.

well, a locale and a locale-specific sort name

(e.g. even if a name is written in latin characters in a japanese alias, the sort name will be in kana)

yes, i understand that, but in the Moby's case what is the purpose ,

s/,/?/

To tell you that the main artist’s name is English-locale.

it indicates that the name "Moby" is the one used in english-speaking locales

kepstin-laptop: MBS-7830

kepstin-laptop: it’s not just you.

hmm, that's pretty much exactly what I wanted to do, tho :)

I’m not completely sure about that 'native' thing.

it's pretty much required, imo

shouldn’t it just display whatever is appropriate for your currently-selected locale?

despite otherwise using the site in an english locale

Some people want to see the native name.

yeah -- and dealing with currently-selected locale is not a particularly easy task either, since it's tied to translations (and especially, which translations we actually *have*)

expressing these preferences is quite nontrivial

now, making all the primary-for-locale aliases more prominent would probably be a good idea

…and some people *do* want to see their local-name variant. There’s no reason that one option is more valid than the other, you’ll displease people either way.

native is, however, what we currently do

English is also what we currently do. :-p

defaulting to not changing too much all at once is a pretty standard strategy :)

hawke: It could be a preference.

no, it isn't

the other thing is - in the case where we don't have an alias matching your locale, how do we pick which one to show?

if you put an artist name in english rather than the native language (when they vary), then it should be changed

hawke: artist names are not all translated/transliterated into english in the current db.

i was wondering, if i set my locale to 'fr', load a release from a japanese artist, which has an alias set for 'en', i will still get the 'ja' version, where i clearly prefer the 'en' one

ianmcorvidae: I meant that the website is currently only displayed in English.

hawke: that is an entirely different discussion that has nothing to do with aliases :P

If there is no matching alias, it should probably default to the native name again.

ianmcorvidae: Just that ‘what we do’ doesn’t mean it’s the best way to do things.

anyway, this is the point of it being hard to express preferences

yeah.

hawke: sure, but changing smaller things rather than bigger things is, from a decision level, a better way to do it than trying to predict what the best way is on limited and usually wrong information

(which is all we have)

I feel like adding a 'native' flag just makes editing things unnecessarily complicated. But maybe it is actually necessarily-complicated.

so as far as the choice to move things to be all aliases, a way that changes less is a better way, in the absence of better information

it's not any different than having a separate name field vs. alias field

you mark native for what you would, previously, have put in the name field, and otherwise don't

But currently most people don’t deal with aliases or primary or anything at all.

except that you have one editing interface and you gain all the information associated with locales, alias types (potentially), etc.

They just worry about the name, if that.

It could even _look_ like there are still “names” vs. “aliases”, UI-wise.

if you create an artist, you will enter a name, select the language of the name (possibly optionally), and the initial name will probably get marked as native.

sure, and most people will continue to enter one name, rather than several, and mark it as "hey, probably use this one"

and if you care futher, you can add more names

in Picard, one can select only one preferred locale for translations of artist's names, at least user should be able to select few locales or set of locales

but they'll do so with the option to add more, if they want and are able, and to mark the locale, etc., which they can't currently do

in fact, the native checkbox doesn't even need to appear until you add a second, since until you have at least two it's totally extraneous :P

you quickly realize that for picking locales properly, you need a ui perhaps as complicated as https://www.kepstin.ca/dump/locale-selector.png

(which is the firefox locale selector)

kepstin-laptop: except browsers are also shit at this :P

First thing I do when installing a browser is to remove everything from that list.

I really like the way wikidata handles local aliases…

well, that's mostly the ui being hidden, and partly web sites sucking at implementing the matching algorithms

because a single ordered list doesn't accurately express preferences either, since it's a decision tree based on availability, completeness, and non-machine-translatability

(But I might do otherwise if websites would mark the quality of their language versions truthfully.)

before you even get into specifics of domain-specific language preferences

display my native language primarily and then show translations in the languages I have chosen. Bang, done.

I hope to get the native language of the website this way, which I expect to be of the best quality, and it works most of the time.

If I had German in that list, I’d get the horrible “translation” of the FSF website, for instance.

many sites also consider machine translation sufficient (which is terrible, and not at all correct)

if you're fluent in multiple languages, native $second_language is much better than machine-translated $first_language

I am afraid the FSF translation was made by a human. :-(

yeah

But a human who isn’t very good at understanding English.

crappy human translation can be substituted for machine translation in this case too, but machine translation as a placeholder for "crappy translation" is easy to understand so I tend to use that :)

The German is fine language-wise, it just doesn’t say what the English text says.

heh, yup

so what does Picard pick up as translation for an artist's name ? it should consider only aliases with Primary and "Artist name" type matching selected locale (or if not found, selected language) ? because it seems to me current code doesn't do that exactly, there is a hacky translate_from_sortname() too

the hacky translate from sortname thing is basically a "transliterate all artist names to latin characters"

which only works because our guidelines say artist sortnames should only use latin characters

I think the only thing picard needs to care about is the 'primary' marker

if an alias is primary for a locale, then it is the only primary alias for the locale, and it is the preferred name for that locale.

even if it is a Legal name or Search hint ?

search hints shouldn't be able to be marked primary

I think the UI rejects marking those as primary

because it is the issue in PICARD-633 (Legal name was picked, but it isn't a primary)

legal name should be fine, I'd imagine

but only if it's marked as primary

if something else is primary it shouldn't, of course, but if the legal name is marked primary it's fine

since it's essentially a subcategory of plain entity name

so matching Primary + locale/language should be ok

the current code is at https://github.com/musicbrainz/picard/blob/mast...

should simplify the code a bit

After experimenting with various DB queries, I come to think the best optimization would be to give totoro more RAM, because even the slowest queries are executed in less than one second if the required data is in the cache.

moar buffer pooooooool

https://musicbrainz.org/artist/83d91898-7763-47... -> sort names don't appear in table

btw, kepstin, sort names foir ja/ko aren't using latin

when sortnames match the name they aren't shown

zas: alias sort names aren't. *artist* sort names

and alias sortnames can be non-latin

are

yeah

(aside from when we don't know how a japanese name is supposed to be pronounced)

(which happens more often than you'd expect :/

Well, how an English name is supposed to be pronounced is often non-obvious as well …

heh

time to add IPA aliases? :P

(or a new column for aliases)

Doesn’t adding an IPA alias still require knowing how to pronounce it?

presumably we should work on picard being usable at all with a screenreader before we worry too much about perfect pronunciation though ;)

hawke: well, sure, but once you do you can add it and save the next person the trouble!

(and no, this isn't a serious suggestion, I'm just amused at the idea of us starting to store IPA for aliases)

Agreed.

WP sometimes does it.

I.e. give the pronunciation of a name.

Yeah, but they do quite a bit of stuff with IPA don’t they?

yeah, I mean -- very long term, pronunciation information would be a neat thing to store. But 'very long term' often means 'such a vanishingly small chance of ever reaching priority that we might as well ignore it'

It would probably be better to indirect it through something like wikidata

I mean, we can do that already, probably

if they store it, anyway

what a total fail of a letter system

That’s kanji for you.

I wonder how many more hundreds of years they will stick with it

it's not a letter system, that's the problem ;)

yeah.

;)

my understanding is that the main reason they're sticking with it is that some people are attached to their names.

And more specifically, to the way their names are written?

yeah, that.

Or are there some that can’t be written in kana?

there's an entire cultural thing about picking names for children where kanji are chosen based on certain auspicious signs or whatnot

Well, “read” could be /red/ or /riːd/, and the only way to know which is to have extra knowledge from the context.

hawke: all japanese names can be written in kana; you'll often find that e.g. a business card of someone with an uncommon name with have the pronunciation in kana as ruby characters

Hm, I see that “more memory” is no new idea: https://chatlogs.musicbrainz.org/musicbrainz-de...

is there an attempt to optimize database query patterns?

I’m looking at the queries related to edit search at the moment.

There are some things that can be improved, and some indexes that can be added, but if the DB has to scan the edit table, it takes ages.