#musicbrainz

mb_release_type/status, I think

ah! thanks :)

brianfreud: I wouldn't mind having presets, but I doubt most users would save much since they're not nearly as efficient as people in here

personally I think I could save a truckload more time from inline editing, but god knows that's never happening :p

(unless I grease it myself)

I think that's happening this summer

luks: do we have your word on it? ;)

yes

Wizzcat: I'd put in an option for it, but then we start to have options again.

sorr, but I admit, I am getting frustrated.

*sorry

don't throw it out, it should be on a branch of it's own, so just incubate

To be honest, why bother? It'd become a branch like the flags branch - code that just rots, as there's seemingly no support for even trying it on a playground.

Which reminds me, I need to move all the image resizer code out from the flags branch.

code in git doesn't rot

just rebase it

maybe it will never get accepted then throw it away...

I personally don't throw stuff away though

Ok, I'll toss it in a text file somewhere.

I'm just getting frustrated.

maybe you should take a break then

i step away when I get frustrated :)

I'm not frustrated with the project. I'm frustrated that there seems to be no openness to trying anything new.

brianfreud: I am a big friend of new stuff, but sorry, presets is more hassle than it's worth.

Don't mean to discourage you though

well, if anyone has ideas for things they think might actually not be met with dislike, put in a ticket. Right now, there's next to no js enhancement reqs: http://bugs.musicbrainz.org/query?status=new&am...

(but a ton of server ones)

unfortunately, it didn't seem most agreed

well there's the whole flags for disputed territories thing, but beyond that

it didn't?

that was the sense I got, whether it was done my way (or better) your way

if it does actually have support, I'd happily change that branch to do it your way luks

close navap, close

:P

navap: are you colour-blind? the site is rainbow! :P

Well, if you're wearing a funky pair of 3d goggles, where one eye is purple, and the other eye is orange - then yeah! It's a rainbow :p

there's yellow and blue and pink and beige and brown and green and red!

I actually liked the flags, but I remember the Debian Taiwan controversy all too good....

oh?

and the case with a nazi flag is also an issue, but otherwise...

the nzai flag was removed early on

*nazi

personally, I would still want to see it, on applicable releases, for trivia reasons, but I can very easily understand why not to show it.

just don't make it an option ;)

hide disputed flags, done :)

aCiD2: I know you were merging the ES branch - let me know when that's done, so I can close all the relevant tickets?

I have merged it, but I was waiting on that missing js, guess that's all done?

if so, I'll merge, push a branch out to test, and you can make sure everything looks good

sound ok?

yes, it's merged, as is a tiny 1 line fix to remove the name attr issue you caught

and I was missing bgiframe or whatever

*pushed, I mean

yup, both should be on github.

great

brianfreud: could you raise the flag problem once again on the ML so we can actually decide on that one? We already call Taiwan a country (just like Debian) so I guess we'll have to live with that...

yeah

aCiD2: so tomorrow it's all on test? nice :)

or tonight :)

I'll be in bed soon

I'm just putting the final touches to all the edit/add release templates and then will merge

ah, ok

and apparently mainland china complained when taiwan was thinking about changing their flag o_O

no yuo!

I have /only/ just worked out that was a typo of you

slow day is slow

aCiD2: Is there any way Add URL AR pages could give a hint as to which type of URL-foo page it is?

as in what foo is?

yes

the old code worked just by matching on URL AR text in the <option> to pick the right AR

that works for, say, ASIN, or Discogs, but "has cover art at" would break in i18n

Hrm, relate to url shows the artist header

so can't you just check for entity.entity_type?

better to hard code the value #'s, rather than match on text in the type descriptions

or have I misunderstood you

I can't check entity.anything in the js - that's on the perl end

oh, right

where do you want it?

hidden input?

doesn't the form have the ids in it?

however you want

<input type="hidden" name="source-type" value="artist" /> sound ok?

nikki: no, right now, it's the same identical form (save for the select's options/value) I think

aCiD2: sure, though you don't even have to bloat the code by that many bytes if you don't want

I can read in an html comment, if that's smaller for you

i'd rather be clear and verbose than hacky

sure, however you want :)

you need it now?

soonish, but doesn't have to be right this minute

would be nicer if ASIN (or whatever the AR is) was always the same value, no matter the foo type, but I know that's not the case

pushed

yea, that's not possibly saddly

thanks :)

hmm, think that'd be something worth doing, long term, in the schema-change branch?

I don't think it has any real implications for server side code

as is

well, the implication would be the different codebase having new values for AR values - it would have to happen at a time we didn't have both old and new code working on the same dataset

cool, this'll work :)

Anyone know where URL AR values are stored? The new three haven't made it in to the tt code yet

hm?

the link text and stuff?

the definition itself

lt_album_url, lt_track_url, etc

I thought that was all in the database

yeah

YouTube, IoBDb, and IBdb aren't in the list atm, on tt

then the database is out of date

unless it's my dump missing them, and not something hard-coded?

it's not hardcoded, there are edits for them

ah

so your dump is from before those edits were made

didn't realize they were edited in

aCiD2: Is not showing the AR descriptions, or the AR target, on purpose?

just cause I didn't do it

ah

so far

want a task?

hrm

no, I'll try and do it tomorrow

k