#metabrainz

and yeah, having an explicit list of languages might be a better idea

I doubt it was intentional as such

Our language table is:

(frequency governs how we show them - by default we don't show them at all, because there are several thousands, and then we set it to higher frequency to show it and to even higher, guessing it was 2, to show them on top as "frequent languages")

It can be pretty empty, since 1 and even 2 don't even exist for many langs

Mr_Monkey: i wanted `👍 Like` on white background, and when a user hovers over a box should be highlighted with grey box, something like that https://gist.github.com/vansika/7feebaba8d2b786...

I hope Facebook haven't patented that :p

:p

reosarevok: what's that list for? only for lookups from code -> name, or for listing too? Do you list all of them?

or only ones above a certain frequency?

All of them are only listed on https://musicbrainz.org/admin/attributes/Language

(which I assume you don't have access to)

what we could do in CB is have the list, and only show ones for which we have a review in that language, or a site translation, and have a way for users to request an additional language

That's also where we can change the frequency (without having to directly edit the DB)

got it

OK, I'll open a ticket to discuss this topic more

thanks

"Hidden is used by default for ancient languages and languages only in ISO 639-3 (until requested by a user)."

So, we used to show everything that is in iso -2 at least

We do have Norwegian (frequently used), Norwegian Bokmål, Norwegian Nynorsk (other = standard), Norwegian Sign Language, Traveller Norwegian (hidden)

Of course, I guess you *could* very well have a review in Norwegian Sign Language, so for you sign languages might not necessarily need to be hidden

(tracklists in sign language are unlikely but a book review sounds perfectly legit)

Do let me know whenever if you have more doubts!

see, I knew you were the right person to talk to about langauges ;)

_lucifer: for now your fix is fine, but this is something else that we should fix in detail

I'll merge these 2 PRs

agreed :)

ohohhohoh norwegian sign languages

_lucifer: you'll see that the exception is hit when a code is a 'macrolanguage'. If you look in the list (e.g. on the write a review page, in the dropdown), the macrolanguages are written in english, while the others are written in the native language or script

this will be the reason that we were using babel.Locale, this maintains the name of the language in that language, whereas pycountry does the name in English... this is all quite confusing and I don't know much more than what I've learned this morning

[critiquebrainz] alastair merged pull request #314 (master…master): Miscellaneous Bug Fixes https://github.com/metabrainz/critiquebrainz/pu...

[critiquebrainz] alastair merged pull request #304 (master…handle-deleted-mb-entities): CB-356: Implemented handling of deleted entities https://github.com/metabrainz/critiquebrainz/pu...

CB-356: Handle reviews with deleted entities in musicbrainz-db https://tickets.metabrainz.org/browse/CB-356

alastairp: makes sense. let's let it be this way for now then

[critiquebrainz] release v-2020-10-26.0 has been published by alastair: https://github.com/metabrainz/critiquebrainz/re...

CatQuest: your review loads now: https://critiquebrainz.org/review/2aef4238-b292...

thanks for finding and reporting the issue

:D thnkas for fixing it!

[listenbrainz-server] alastair opened pull request #1155 (master…werkzeug-profile): Remove unused devserver and werkzeug profiler code from server startup https://github.com/metabrainz/listenbrainz-serv...

alastairp: can you unhide the mising entity review so that we can see if the deleted entities fix is working

[troi-recommendation-playground] alastair opened pull request #20 (main…test-args): Pass all test subcommand arguments and options to pytest https://github.com/metabrainz/troi-recommendati...

!m alastairp

You're doing good work, alastairp!

_lucifer: I've unhidden it

oh hi ruaok

thank you for that insight -- that was the problem! well caught!

but yes. I think we should keep the name as "list" -- much shorter.

cool, will add that. it's just an arg to cli.command()

ahahaha

look at that example command name

heh.

does it work correctly the args list is empty?

(see line 117 in the pre-section of the PR)

seems like it

odd. never worked for me.

ah, you mean where you specify the current directory? I think pytest will automatically scan for all tests starting from the current dir anyway

oh, I think I added some __init__.py's, let me check

yep, still fine 🤷

ok, if I come across it again, I'l take a closer look.

some amazing colours tonight https://usercontent.irccloud-cdn.com/file/iMU4p...

yes, we've got this eeerie orange glow going on right now

...

wait it's that thoing now right

ack, why cant we get rid of dts

alastairp: wanna chat about next steps for troi?

let's do it

so, I'd be curious to see what else you think needs tests.

I'm not too keen on writing detailed tests for the webserver portion of it. most everything critical now has a test, short of the annoy stuff.

I think you're right, we don't need much more than what's there

ok, if you find something else amiss, open a ticket.

these tests don't help if the dataset hoster output changes, is that something that we should think about?

yes, I think so.

that might be as simple as making a call to the API to ensure that the inputs/outputs have not changed.

going back to iliekcomputers's plan of integrating all of the repos... this would be easier if the code for both was together, but I'm not sure I like that

yes, otherwise that, a "live" integration test

I totally agree.

pytest marks are cool for that: https://docs.pytest.org/en/stable/mark.html

we can always merge it later, unmerging is harder. so I am more for keeping it as is.

you annotate tests, and then can tell pytest "just run these ones", so we could have some integration tests marked as such, and perhaps run them less often, and not by default

LB-750

LB-750: Create simple integration tests for troi to ensure that dataset hoster inputs/outputs don't change https://tickets.metabrainz.org/browse/LB-750

nice

well, given that its supposed to be a stable API and the requests will be fast I have no problems running them all the time, but I'll have a look.

can I ask you to be more specific in your test descriptions? The problem with "as discussed in IRC" is that we forget. a link to chatlogs would be enough if you don't want to write in more detail

yeah, I wish there was an easy/reliable way to get a link to the IRC chat.

but finding the link and then getting the link to be useful is... nearly pointless

right

agreed

I see debugging tickets, more docs and argparse.

I think I'd leave the debugging tickets to you, since I don't quite feel the need for them. but I can take argparse which totally is needed and adding more docs to reflect recent changes.

I hope that's the case. I was looking at some tickets last week which I'm sure I expected to be easy to do, but they ended up sticking around for months or years and we lose all context

it's OK, not going to be a showstopper

but, point taken.

the debugging one - LB-742?

LB-742: Debug an element by passing a single item through it https://tickets.metabrainz.org/browse/LB-742

oh, slightly OT. at somepoint we should get one takeout and have a design session for playlists support for our hackday next month.

I'll see if I can work out what I want here

742, 741

reosarevok: that would work if we really need to disable a field (which form is it?)

740 is also pretty straightforward. if you didn't get to that when I've finished the others, then I'll do that one.

once we have these open tickets sorted, we should work on annoy and good example patch that shows off the use of the annoy.

cool. should we use 'start progress' buttons to track what we're working on, then? so that we can make sure that we're not duplicating tasks?

yep, I'm just picking that up again now

actually, I have a question for you:

I just assigned tickets to us accordingly to that affect.

I need both the given mbid and the redirected mbid in Recording. thoughts? just add another field?

(Meeting in 10 minutes!)

hi freso!

alastairp: how about sticking that into the recording.musicbrainz dict? recording.musicbrainz.original_recording_mbid ?

once we start using the MB, AB, LB dicts we should start documenting the keys that we're using.

(^^^ CatQuest, bitmap, shivam-kapila, _lucifer, jmp_music__, pristine___, possibly others? who don’t change DST together with the EU.)

🙋

pingreo too because h's often busy

But time hasn’t changed for him.

Alias edit when search hint is selected

ruaok: that's a good place, thanks

ah you're there reo

do you have a day planned when you are going to work on troi this week, alastairp ?

wednesday

if so, then I'll clear my schedule to work on troi the same day so we can do like we did last week. that was a nice feeling to just push a pile of stuff through.

takeout + playlist planning sounds good too

ok, wed for troi. playlist maybe next week?

if we're allowed out by then, sure

hehe, i nearly said that.

I think the weekend lockdowns will come first before complete lockdowns.

oh, next week tues/weds I'm unavailable for the full day

next week I am all clear except thu.

ok, maybe we could do monday then - by midday tues I'll know if I'm needed for the meeting on weds too

alastairp: this is how it shows up the deleted entity https://www.critiquebrainz.org/release-group/e6...

lets pencil monday in and if we need to change it... sure. not like we're going to have busy social calendars for the rest of the year.

_lucifer: ohhhhh

this is why we have all of these `| default` tags throughout the templates

here I was saying "I can't see any reason why we would have to have a default if an entity is missing"... this is the reason why

yeah, i think so as well

we should try and add some documentation that explains this

or maybe we should copy titles/names into the Review table so that we can display it if necessary

I'll open a ticket

<BANG>

It’s Intersex Awareness Monday!

No mailed in reviews this week, so we go straight to the list…