reosarevok: thanks for taking a look at MBS-13561! if my reading of the code is correct, i think there's probably no way to make available in /tag without making the query more expensive, which might not be worth it
i think we're currently (in find_entities in Data::EntityTag?) just joining artist to artist_tag and getting _columns from Data::Artist. does that sound correct?
fletchto99_ joined the channel
fletchto99 has quit
fletchto99_ is now known as fletchto99
answering self: yeah, that seems correct. i see the aliases when i add a hacky $model->parent->load_related_info([$entity], 'en') call there
yvanzo
reosarevok: I updated the ticket and the editing FAQ wiki page. Can you please proofread it?
It might be worth mentioning this edge case in the Style/Titles guidelines as well.
reosarevok
yvanzo: will check :)
in return: do you know if MBS-13567 is actually intentional? It seems odd to me but maybe it's a choice
derat: why is that a hacky call? That's the kind of call we should be adding :)
(probably, anyway)
yvanzo: "Actually, titles are supposed to be “minimal summaries” - see Title (publishing) - hence overlong titles are likely to be better split into separate pieces of information that would fit other fields of the database such as work relationships." that's a wikipedia definition, not a MB guideline - a title is supposed to be whatever the artist intends :)
(I still agree it makes sense to limit that a bit since it's needed for technical reasons, but it doesn't mean long titles are not valid titles!)
"This applies to all titles, names, sort names, including artist credits and aliases." artist credit names, right? So each credit in an AC must be at most those chars, not the whole AC?
(I hope we don't have many ACs that long, just asking for clarity)
yvanzo
reosarevok: If it isn’t mentioned in MB guidelines, maybe it should be.
monkey[m]
lucifer (IRC): Regarding the VA PR, I guess so if it needs to be done on the front-end instead
yvanzo
I used this reference as I thought that it would be more consensual.
reosarevok
Not the guidelines, but the docs yes :)
I'll amend the doc
lucifer
monkey[m]: i think that's how aerozol wanted it to be, as a filter for the user to enable and disable showing va releases.
reosarevok
(that there's a hard limit and more needs to be added to the annotation)
monkey[m]
Makes sense to me
yvanzo
(you were referring to the guideline)
reosarevok
Well, we're not going to add a guideline saying titles should be short, because I strongly disagree with that idea, long titles are a valid artistic choice :)
We can document that we have a maximum limit for technical reasons, that's it
zerodogg has quit
Doing it now :)
yvanzo
reosarevok: “artist credit names, right?” the whole AC, hence each credit and join phrase too.
derat
reosarevok: sorry, i meant that it's hacky because i'm doing a separate call per entity and hardcoding the language. left a comment on the ticket
reosarevok
yvanzo: the whole AC? So if we have "A ft B & C", the combination of all artist credits and join phrases is blocked from surpassing 1024 chars?
What do you think about something like this in the edge cases section of style/titles?:
"Also, extremely long titles (more than 1024 characters or 2704 bytes of content) are not supported for technical reasons. If you have one of these, shorten it in the best possible way (for example, by adding ... after the last full word that fits) and include the entire title in the annotation for the entity."
yvanzo
We follow the artistic decision to “break display in databases”.
Yes “the edge cases section of style/titles” is what I suggested above.
The 1024 characters limit is no longer grounded by any technical reason.
Well, excepted that we want to make third-party development around MB data easier.
reosarevok
Well, that's why I didn't like it :) But it's still mostly technical, in that it can cause issues
A lot of long titles are not a troll attempt, they're just weird artist shit :) There was that one artist, yes
Anyway, I'll keep it like that, since I would like to think of it as a technical issue, rather as someone else overriding the style leader's own style opinion, if only to feel a bit better 😅
Transcluded that. Checking the FAQ change now
Ok, unsurprisingly I disagree with the claim about reasonable lengths, so I'll leave both as technical limits
Either that, or request as the style leader that anything above what is needed for technical reasons is removed, that is.
I find it even more silly than the trolls themselves.
reosarevok
Sorry that you feel that way - is the wording acceptable to you though?
I'm doing my best to compromise with a change I dislike, please work with me.
atj
artists are weird
zas
yvanzo: was sir instance deployed to feed new solr cloud already?
yvanzo
zas: not yet
zas
this is something we need very soon to be able to optimize solr cloud, because changes pushed by sir cause solr to heavily modify its caches, and that's where most of computing resources are disappearing. We have few hints about how to improve the situation, but only actual testing & performance measurement will tell us which options are the best. How can we help for it to happen? What needs to be done?
reosarevok
Ok, I'll transclude it like that for now - seems better than not documenting it at all
Can always be amended further
yvanzo
reosarevok: the release draft is also ready for review
reosarevok
Thanks, on it!
yvanzo: should we mention something about downloading a newer dump if they are having issues importing the failing one or do you think it's obvious enough?
mr44er[m] joined the channel
mr44er[m]
sorry to interrupt, short question I was asking myself last time with weird name: https://musicbrainz.org/artist/4008fdf3-2c3d-46... -> is there a limit or word combo with characters in a technical way, that could disturb the db/system or is the just the length the limit as long everything is UTF8?
MBS-13562: Limit the length of titles/names to 1024 characters at most
reosarevok
yvanzo: the post seems fine, anyway, although "a nasty trend of jamming music databases" seems a bit confusing, maybe "combined with some unfunny attempts at seeing what long names can break"? :D
I dunno :)
yvanzo
it's not just a few attempts, there is a whole genre for that
reosarevok
Is there? Then maybe we should link to it :D
mr44er[m]: basically, short silly names are fine - they'll be crappy for search, but that's probably at least partially the intent of the artist too. Adding a search hint alias without the styling seems like it would be useful though in some of these cases
Anyway, in that case I guess this is fine, although for most readers it'll probably be confusing what trend you're talking about :)
Everything else is good, anyway, I guess the ticket links should be enough for the people that hit those issues
Last two lines were for yvanzo, speaking of confusing!
mr44er[m]
yeah, thx. 🙂
ah and btw...I always add a 'public' before the contact-emails
(so whenever there's actually per-day artists, those should be moved to the specific days, or even the specific stages, and your code should probably look at those when looking at the main event)
Which reminds me, I have to officially put out STYLE-747
