[bookbrainz-site] MonkeyDo opened pull request #549 (master…snyk-upgrade-7c07eebc0481fcb385cc7232d7696f2d): [Snyk] Upgrade @babel/runtime from 7.10.1 to 7.12.5 https://github.com/bookbrainz/bookbrainz-site/p...
if you use "inc=random" you should get an error (for now at least)
Mr_Monkey
reosarevok: You just need the right tool that will take an image and export all the icons you can imagine in one go.
Couldn't find the one I used for BB, but this one looks neat and even has reporting :) :https://realfavicongenerator.net/favicon_checker?protocol=http&site=www.musicbrainz.org
reosarevok
We do have inc=media
Documented
Mr_Monkey
You'll need to make sure the image you give it is 1) high quality 2) the right —square— format and 3) with the background color you want (I guess white)
reosarevok
Funnily, inc=medium seems to give the same results? :D
Mr_Monkey
reosarevok: Tell you what, since I'm already checking it out, do you want me to send you a zip file containing all the finished icons?
yvanzo
Mr_Monkey: some tools have a small rendering issue with LB logo
So I guess it's not documented because it's deprecated
MagnusSvensson[m has quit
yvanzo
_lucifer: there are small issues such as making search results to comply with lookup/browse results, medium issues as adding support for collections, large issues such as porting to python 3.
reosarevok
Anyway. Re: the counts, we should probably try to be consistent, so either have them on both search and lookup/browse for JSON, or on neither. Removing is more dangerous than adding, but at the same time I'm not sure how useful this data is... :/
BrainzGit has quit
yvanzo
_lucifer: there are other possible improvements for continuous integration (e.g. by testing sir against mbsssss), and documentation (e.g. adding more details about search fields).
reosarevok: So adding a duplicate JSON element named "media-count"?
reosarevok
Might be best. The same is probably true of all other count attributes/elements, FWIW
BrainzGit joined the channel
bitmap: ^ when you're back, I'd like an opinion on that too
yvanzo: if you have some smaller stuff that might not require setting up the whole infrastructure locally to test, I could also give a hand
With search stuff I mean
Documentation might be a thing, if you have a clear idea of what's missing
I do have a couple free hours today and no clear ticket to do next
yvanzo
reosarevok: I found that https://musicbrainz.org/doc/Indexed_Search_Syntax is incomplete as in: 1) the expected values for search fields is not always documented, 2) some search fields are just missing.
reosarevok
Do you have a couple examples?
I can look into that. Do we have a good file with all possible search fields on github? :)
yvanzo
for example, the "lang" search field for Work should be ISO-639-3
there is a script to generate the list of search fields in "sir" repo
Also, is there a specific ticket for updating these docs, or should I make one? :)
yvanzo
it looks much better, thanks, there is no ticket afaik
I did some research about how to document search fields directly in mbsssss but it seems uneasy to do/maintain.
reosarevok
Ok, I'll add a ticket (so I can track the work better) and keep doing other entities
Well, doing it directly in mbssssssssssssss I guess would imply having a JSON file where you map a key (probably "entity/field") to a description string.
And then have the python script take the description from the file
yvanzo
Ideally, I'd like to put that directly in a "summary" attribute for each search field defined in */conf/schema.xml but I did not test if that would break Solr.
reosarevok
Well, I'll update the summaries for now and we can always move them to the schema later
yvanzo
+1
reosarevok
Also, is there a ticket to search more stuff by MBIDs?
It would be good to have area search that doesn't depend on English names that might change, at the very least
yvanzo
+1
there is no ticket about that so far
_lucifer
ruaok: i read about that but didn't quite understand what's going on. (elasticsearch)
yvanzo
searching by MBID is available for some fields but not for area (but in area search index)
ruaok
_lucifer: is it clear to you now?
yvanzo
reosarevok: so adding search fields "aid", "beginaid", "endaid", right?
reosarevok
Yeah
_lucifer
ruaok: not yet but still reading up the link you shared above.
yvanzo
in general, there is no problem with adding search fields, but to recording search index (which is not related to area, so it's ok)
reosarevok
Eventually probably the same for gender and type for example, but I guess we would need to document those gids properly later :p
Why is recording a problem? Just because it's huge and would require a full reindex?
yvanzo
(the problem with adding data to recording search index is: it's too large already)
reosarevok
Recording seems to have nothing of the sort, so that's ok
