#bookbrainz

monkey, Shubh: how does BB implement languages? Does it take the MB table or?

(wondering if you actually have the same "most common / other / hidden" concept as we do)

Yes from mb

I've found the MB way with a dozen or so top languages on top of the list, then the rest underneath, and then the ones that are not (yet) needed hidden not to have 9k entries in the list works fairly well :)

(but I dunno if BB would need a different common / other / hidden split or we could just use the same and unlock languages from MB once they're needed for BB)

we intend to do the same ie. using frequency of a language to sort it in dropdown selection

although we do currently sort/rank languages on frequency but doesn't hide any, which was the reason we were (still) facing slow dropdowns

tbh if you have access to the MB DB list, I'd probably hide all the hidden MB ones

(do make a quick DB call to see if you're *using* any of them already, if so, I can unhide them on the MB side too)

Important distinction: we have a *copy* of a couple of tables from the MB db, currently no direct access to MB db

Oh

So if new languages are added to MB and whatnot, you don't actually get updated

Hmm

On one hand that's not bad because BB might have slightly different top languages and hidden languages than MB

On the other, we probably would want to keep the tables themselves at least in sync...

(the languages if not the frequencies)

Hmm mb would have more data on common languages

The plan is to have a direct DB connection at some point and use the MB tables

how would we link them with bb tables?

Make a connection to the MB DB and run queries on that db

So possibly some changes in the ORM

I guess you could also technically have a second "language_frequency_bookbrainz" table you can join with musicbrainz.language

But I dunno how that works with ORMs tbh

like what about foreign key relations?

I'll be honest, it's not something I've done in the past, so I don't know

hey monkey

Hi!

I was thinking that for implementing a simple admin panel page, it should have a user search and then clicking on the users to open a modal which will then allow the admin to perform an action(blocking, making priviliged Editor, unblocking etc)

something like this https://pasteboard.co/19YupgsJ02cG.png

sounds reasonable so far

also, on the project description, it is written that we need new table for attaching roles, but as BenOckmore mentioned we can probably leverage the editor_type table

A button next to the name in the table would probably be sufficient, where a modal might be a bit overkill, but those are just details

Yes, agree editor_type can be used for this purpose

the reason I suggest a modal is because there can be different action_types. It would also allow us to add more fields to an action, such as a 'Note/Reason for blocking a user' which can then be used in the Admin Log

That makes sense

oh, I thought the "admin" stuff was related to the relationship editing interface :(

reosarevok, monkey: at some point, we had replication set up, and the language and gender tables were being kept in sync

That's the reason those tables exist in the separate musicbrainz schema in the database

EndeavouringCat it is, admins can make certain users as privileged editors. These privileged editors and admins can edit and add relationships and identifiers too.

:O

omg

ShivamAwasthi: so you are going to work on this for gsoc???

🙏 aaaweesommeee

Shubh, we can probably skip the Authors column in the WorkTable in Authors page

the WorkTable component will automatically skip it if we dont pass the authorsData in the props

Hmm we should probably do writer/translator in place of author

no I meant that since we are on an authors page, and it is listing this author's works, we probably dont need to display a column which lists his name again and again

their*

Well, I would argue that sometimes a work is written by more than one author, in which case we would have some information missing if we didn't show the author(s) column

On a side note, we are also likely to reuse the table later on to show (in a separate tab on the author page) Works that author translated. At which point we'll want to show the author column.

We sometimes just pass a showAuthorsColumn kind of variable to the template for those cases

Yeah, i'm guessing we'll want something like that for flexibility

One option would be to check whether any of the authors lists has more than just this one, and only show the author in that case

But we don't yet have a use case for this specific one I think

IIRC that's what MB does for RGs

Yeah, that's a good point

Although I'm not always keen on automatically changing the layout on the user.

In this case, i guess it would make sense though

Oh, seems we always show them all nowadays (except for track artists on releases)

(and won't be too surprising for users)

I agree with changing the layout, I'm not always a fan

But probably worth checking whether some cases look a bit silly or something :)

To be honest, I just want an advanced table library that allows users to sort by and show/hide the columns they want

before this, we were listing relationships of the author only, so we were already kind of missing out on the information that the work is written by multiple authors

I think in most cases the Works displayed on an author's page will have a single author

We can, maybe, display one more tab where the works with multiple authors are listed? (something like Collaborations)

We could, but for now that seems maybe overkill.

hmm. agreed

How are translations done?

If they'll be in the same table, and translators are under authors, you probably want to show them

author X wrote work Y, + author Z translated work Y

2 relationships

Sure, I meant whether they'd show in the authors column :)

When listing works

(a bit like https://musicbrainz.org/artist/2cd475bb-1abd-40...)

Ah, I see :) For now translators will not be displayed.

The plan is to have a separate "translated" tab showing all the works an author translated. That table will show a column with the authors

(and not the translator)

the original author of the work

(aside) monkey did the disambiguation field in the entity-editor always had a green tick(even before entering the disambiguation)?

Ok, if this is basically an "authored" tab rather than a "works" tab, then I can see that working :)

Yeah, exactly. "works written by this author" and another tab "works translated by this author", etc.

ShivamAwasthi: Um. Probably? I can't recall exactly

But I guess we could add a condition to not show validation state if the field is empty.

I think it used to show up like all the other fields(without being green initially). I cant recall too.

i'm not sure about having separate tab for translator, since author-work relationships have other types too

What do you mean by other types?

Ah, I think I understand

illustrator, colourer..

Relationships other than translations and authored works, can be listed down separate from the WorkTable?

Well, the idea is not to have a tab for each relationship types, but rather to showcase the more expected ones.

One other possibility is to have an "Other" sort of tab that shows other relationships

but still one table should do the work like mb, maybe allowing user to choose what to show or show all, something like that

Well, MB has a separate tab that shows all other relationships: https://musicbrainz.org/artist/2cd475bb-1abd-40...

I think it should be like this: The WorkTable should have 3 tabs(1 for works written by author, 1 for works translated by other, 1 for other work-author relationships), all the other relationships should be listed after the worktable component

i meant something like this https://musicbrainz.org/artist/2cd475bb-1abd-40...

Definitely possible to try a single tab for all author-work relationships, and find a way to make it work. But IMO it would probably be simpler and clearer to have separate tabs so as not to overcrowd the page as first loaded

but how many tabs are we talking about?

All i can think of for now is 1 for "wrote work", 1 for "translated work", 1 for "others", so 3 in total

We might eventually want to think about showing relationships like "A provided story for W" in the same tab as "A wrote W", and maybe "A translated W" on the same tab as "A worked on W".

I could be convinced either way.

are we categorizing them on similarity or frequency?

To be honest I haven't thought this far, I'm just throwing some ideas

I do see you point though, it would be easiest to show all author-work rels in a single tab, and have a tab for each entity type the author can have a rel for.

monkey: how bb keep track of user achievement progress?, by counting all prev history revisions?

how can a user see their progress?

There's currently no way for users to see progress on their achievements (see BB-505)

BB-505: Show achievement progress https://tickets.metabrainz.org/browse/BB-505

As for ho they work, there's this table: https://github.com/metabrainz/bookbrainz-site/b...

And a matching ORM model

And then this bit of code: https://github.com/metabrainz/bookbrainz-site/b...

Hmm so we can do this for other achievements as well like having counter for achievements for every user in some table/tables

For the entity-based ones I think we just sum up the number of $entityType_revision by that editor

Yeah, this mess here: https://github.com/metabrainz/bookbrainz-site/b...

More specifically https://github.com/metabrainz/bookbrainz-site/b...

glyp

fish

in unified form, i'm planning to have new revisions for each entity created by user and then another new revision for adding relationships on them . does this sound reasonable?