#musicbrainz-devel

nikki: like how?

autoeditors have the magic approve button?

there are some greasemonkey scripts here and there which let auto-editors tick a box on the edit search page to approve an edit

but there are clashes with the improved voting stuff we have now, and it only works in ff

my brain hurts.

I've been working and staring at a computer all day. and the visual processing area in my brain is pissy.

so very odd a sensation.

I'd be willing to give a handful of people the magic approve button.

like everyone in this channel, for instance.

ok, I have to rest my eyes.

bbiab.

Even if just autoeditors were able to batch approve, that would certainly speed things up.

I'm sure we can talk about it another time :)

navap: yeah, that's what I mean

eheh... matched 90% of these urls now...

alastairp: I've commited my change and pushed it to github. So now how would one of the devs get at my change?

they would add you gh as a remote

And then pull/merge me into a branch on their end?

but it's no different to someone having a repo on git.mb by that stage

all the rest is workflow

So all the *.gits on git.mb are like different users on github?

different repositories

but yeah

Someone needs to work a way to bring a role like system to HTML templates

nikki: prod

hah "en-scouse"

awesome

p track of bug for the MusicBrainz server now. Please do not enter bugs for Beta 1 into the old (trac) bug tracker!"

That's seeming to say "anything for the MusicBrainz server" and "only NGS Beta 1" at the same time

Side note, on jira and the bugs list; since jira sends me everything directly anyhow, I wish it didn't get included in the bugs list stuff... All the jira stuff, including time estimating, etc, is making it very hard to find the few trac-ticket related things in the bug lists, as well as the jira-in-bugs-list being 100% redundant to the every-single-jira-ticket-sent-directly-to-me

Anyone know how to get a list of locales (I need language and territory) in Perl?

I can't figure it out after an hour of browsing modules -_-'

I18N::LangTags::List doesn't actually list them, Locales is useless because it just gives all territories, regardless of the language

and Locale::Codes doesn't seem to have territory support

http://www.iana.org/assignments/language-subtag... too detailed for the task of aliases?

Hmph, still doesn't have the mapping between language and territory either

brianfreud: oh, if you cannot (re-)assign jira tickets, we should probably open that up.

aCiD2: hello! :)

morning warp :)

urr

afternoon*

:)

warp: Someone said on the mailing list that aliases might be in a certain languange, but only for a certain territory

I (obviously) can't think of an example, but i was trying to cater to that. I think for now, i'm going to just provide languages

aCiD2: ah, right

how did the UX stuff go, warp?

warp: yeah; I cannot touch the assignee - I think only you, luks, acid2, and ruoak can

aCiD2: can you open that up for brianfreud?

aCiD2: or just in general?

yea, I'll look into that now

regarding UX, we discussed that a bit.. but this hardcore data entry stuff is just hard.

Heh, amen to that

he basically said what I already knew, make the common things easy to do with both keyboard and mouse

and for anything else it's ok if that's a little more effort.

brianfreud: you should be able to reassign...

also, on the other point I made ^^, that blog post was rather unclear...

considering collaborations are less common than just single artists, it's ok if keyboard users have to either click something with the mouse or learn a complicated keyboard shortcut.

The only thing you can't do is scheduling, changing the reporter, deleting issues and changing the security level

if jira is only for NGS, that wasn't my takeaway from the post. But if jira is to be for all mb server, there's no way to assign something as a mason issue, such as adding an AR

er.. to open the artist credit editor.

warp: right, that does seem acceptable

aCiD2: switching topics, on your feedback on MBS-424.

aCiD2: I couldn't figure out a clean way to get stuff into <head>

aCiD2: I wasn't sure how to append to layout_head, and didn't want to overwrite it. and it's outside the [% UNLESS no_javascript %]

you just do [% BLOCK layout_head %] in the templates that need to change it

preferably it's only included when rating_stars() is called on a page, but there doesn't seem to be a way write a template that way.

but yea... the latter is more of an issue I think

This is why with scripts/text.js at least we get to cache all the translations

aCiD2: wouldn't just [% BLOCK layout_head %] overwrite any existing layout_head?

it would, but that's the point of it

aCiD2: what if some other piece of code also wants to include stuff in the <head>?

I mean in root/artist/index.tt you'd override layout_head

then you append to that bit of code

sadly, I haven't found a nice way to specialize what javascript is on which page yet

after trying numerous solutions

aCiD2: well, there can be a few layers of [% WRAPPER %]s

The plan was that the low level templates wouldn't tocuh layout_head - only the actual page templates

aCiD2: What didn't work with the way I did it? That was working well for page/etc js specialization

aCiD2: anyway, even then, the code I want to include in <head> is stuff which should be near the other rating macros, because it's already duplicated... and if it's not right next to eachother you'll forget to change one if you change the other.

brianfreud: and what was that way?

the page_js array?

I'm not too fussed about including unused javascript on a page, that just means we can later on minimize it all together in a one or a few big .js files and make sure the browser caches it.

yeah

warp: Oh god, please no!

warp: then could we move it to text.js?

If we want to bung it all together for now and come back to it later that's fine, but it'd be nice if we could at least to do that in something other than the html

aCiD2: "git ls-files | grep text.js" returns nothing, which file are you referring to?

cached js: good. "one big .js file(s)": a thousand times no! :D

root/script/text_strings.tt

aCiD2: ah, I didn't know that files. that does seem perfect for the strings I have, yes.

:)

help if I called it by the correct name

brianfreud: in general, tools like google page speed and yahoo's YSlow recommend combining .js files into one file.

no, they recommend combining js *per page* into one...

brianfreud: yes, sure

Unless I misunderstood what you meant?

I just don't want to see the same as on mason, where the entire site got dumped into one massive js file that got loaded on every page

brianfreud: but we don't have many different page types.

There's no reason RE js should be parsed into the browser on any page but a RE page

general purpose JS and RE seem fine to me

that's a good enough separation

aCiD2: yeah, that's what I was thinking too.

the others are all tiny, so no big deal, but the RE/GC is a big resource hog if you have mult MB tabs open

(no matter how efficient you make it :P)

brianfreud: no one is suggesting that

ok, just making sure :D

i know we generally said "lump it together" but we're not going to be that careless - it's just not worth the effort to get it perfect (same with CSS)

the mason-way, with all in one, is just so fugly :D

I can also imagine not loading the RE/GC code on page load at all

or, I mean, some components could perhaps be loaded on demand.

brian tried that with mixed success

yeah, now that I think about it.. most is probably needed when you actually edit stuff.

well full success, but luks hated it,

:)

brianfreud: if there are components which are likely to go unused by a considerable amount of users on a particular page, I will definitely consider that approach.

I didn't like it either, it was too slow to load

i think it's cause we went all-or-nothing

but yea, if we just load the track parser or something on demand, that seems more sensible

what mainly drives me nuts is that GM doesn't start to load until *all* page js parses and loads. When you're trying to do a lot of tiny things quickly, across a lot of tabs, waiting for that big js file to parse/load on mason often means GM takes me 5-15 seconds before anything GM is useable on any tab

yes, it doesn't have to be on-demand.

it can also be on-demand or 2 seconds after the page has finished loading, whichever occurs first.

aCiD2: I don't think it even needs to be that much; the only RE module-specific js that should really be largish is GC, and you almost never need GC right at page load

I'm just brainstorming though, I have never tried such approaches :)

anyway, I'm going to fix MBS-424, afk.

(well, not really away from keyboard... would be hard for me to hack js without a keyboard)

warp: from my experiences, if you lazy load the RE at all, I'd suggest either RE (page) + GC (lazy), or, if/when there's time to optimize page load for the RE, bare minimum to have basic form functionality (page) + RE (lazy 1st) + GC (lazy last)

anything more than that the overhead makes it not worth doing

aCiD2: hm, what do you think of making just the rating text strings themselves macros?

aCiD2: which I could call in text_strings.tt, I really don't want the same string to appear in two different files.

Why would it appear anywhere other than in text_strings.tt? Is this because you want all the rating stuff together?

aCiD2: because the same string is needed both from javascript and in the html

ah, ok

aCiD2: the javascript needs to swap out "Remove your rating" for "Rate: 5 stars", etc..

So how are you planning to define the strings?

How about: root/components/ratings.tt which is included from common-macros.tt so we have all the rating stuff together. Text_strings.tt can make use of the stuff too then

aCiD2: ah, I can just [% INCLUDE 'component/rating-macros.tt' %] in common-macros.tt?

yea

(there is already a components/ratings.tt which does something else)

Hrm, so there is

that could be stuffed into a MACRO as a BLOCK and called as [% display_ratings(ratings) %] ?

meh

stick it in common-macros for now

aCiD2: for the strings, I was thinking something ugly like [% MACRO rating_tooltip_set (star) BLOCK; l("foo"); END %] or something.