#musicbrainz-devel

hm, I guess I should sign up for MHD london if I'm ostensibly going, shouldn't I

Hello, I am currently setting up a local copy of the musicbrainz server software and loading a dump, so I can process my music collection more quickly

I am up to the initdb stage, but with the most recently available dump, I get a duplicate key error in createindexes

Is this a known issue at all? Can I do something about this so I can successfully import the dump?

it's known

comment out the relevant index

it'll stop being a problem with the next dump, but the current one it's still a problem :(

if you've already gotten as far as the CreateIndexes stage, what you can do in order to not need to rerun the import step is:

a.) comment out the broken index(es) (I think it may just be label_idx_null_comment at this point though)

b.) comment out the stuff that's already been done in InitDb.pl

oh, awesome!

Sorry I went away thinking no one was on

specifically, for b.): lines 236-276

doing now

no worries, I was just at the store :)

but yeah, those indexes aren't super necessary, they prevent some situations that we don't want to happen, but on a mirror server they won't anyway, since you aren't editing things there :)

ok sure

thanks for the help, I'm retrying now

nikki: pong

luks: I was wondering if you knew whether gettext plurals should be used when the string doesn't actually contain numbers. I could have sworn I read somewhere that they shouldn't, but then couldn't find anything to support that

(the thing in question being "type" or "types" on the cover art tab, depending on the number of types displayed for the cover art)

hello!

nikki: no idea, but I see nothing technically wrong with it

I can't think of a language that would actually depend on the number in there

we did try using plural forms there and ran into problems with translations being wrongly merged >_<

since the singular also exists without a plural in other places

maybe it just needs a context?

no idea. no matter how I look at it, it's stupid to encounter "type" on its own and "type" with the plural "types" and then think the best way to resolve it is to to throw away the plural :P

gettext considers msgid "blah" + msgid_plural "blahs" to be duplicate with just plain msgid "blah"

yeah, that's why I'd add context to it

well, plural + context is usually wrong (generally it's encouraged to just put it into the string, with the plural -- since typically you're interpolating something)

I could add it to all the singular ones, but that's also annoying :P

how are the strings displayed?

er, not sure what you mean

is it really just singular/plural without any number anywhere?

type: front

types: back, spine

yeah

ah, then I'd translate them separately

it's <string:> <list of types>

in slovak we have 3 plural form, but I would use the third one in this case

yeah, I just am wary of any time I do "if whatever.size = 1, l(whatever), else l(whatever-plural)"

it would be wrong

but that's the right thing to do here

er, I meant "I wouldn't use"

yeah

"1 typ, 2 typy, 5 typov"

but "typov: a, b, c, d, e, f" is totally wrong in slovak

in short, the pluralization rules are different in this case so don't worry about the ln() stuff?

(just making sure I'm understanding what you're saying)

yes, because you don't really know the total count

(at the language level)

yeah

despite the fact the *code* can pass in an exact count, the language still needs to be written as though it's non-specific

makes sense

the hard thing to do is how to deal with 0 :)

heh

which I suppose explains why I don't find "types: foo" that odd, while "1 types" is just wrong

well, germanic plurals is 1 vs. everything else (0 included)

but not french, afaik

I'd probably always use plural there

just to avoid the (none) case

which is I guess how we'd have to do it sans-ln()

warp: so, are you planning to ship your schema change stuff to the branch, or has that bug now gotten postponed 6 months?

ianmcorvidae: MBS-4627? I was waiting for an OK from ocharles

this stuff ostensibly ships monday

I don't know about merging everything else, but at least the actual changes to the schema need to be in the branch IMO

afaics the branch is ready for merging entirely

ocharles: ping :)

warp: pong

ocharles: apparently http://codereview.musicbrainz.org/r/2304/ is not in the schema change branch yet. can I merge that in?

i'll review it now

ocharles, warp: I see ocharles' comments are all code stuff -- can we get the schema change scripts themselves into the branch so that part can get tested?

(like we have with several other tickets)

yea, the schema is fine

what with the five days until we supposedly release this :)

I, however, am going to bed so I don't miss the meeting at 19:00 by sleeping through it -- tell me if I should do that merge when I wake up

thoughts on https://gist.github.com/6eaf51702313426e9d46 please, too

warp can do that merge

block opening braces for subs I feel like I've more often seen on the next line

rest looks reasonable to me

but it's not like I look at it as often as you guys :P

ocharles: when exactly should whitespace be used before ()? it's not that I don't agree (totally throws me every time I see a space I wasn't expecting), but given that you write "if ( ..." later on, it's not *always* the case :)

s/pareth/parenth/, s/parenthesis/parentheses/g

heh, I was just thinking that

I think I might have too much time on my hands, 'cause I've wondered the same thing (both about spacing and ordering of imports) with my own stuff :P

nikki: I was meant to qualify that with 'except for flow control' where we do use a leading space

ocharles: the leading space around parens is a habit I should unlearn.

i'm afraid so

ocharles: but I disagree with the braces, I much prefer matching braces in the same column.

hm?

oh

so on a separate line

yes

it just leads to less code on the screen, and more I have to hold in my head

it leads to clearly visible start/end points for blocks :)

so does indentation

ocharles: anyway, no objections to the other bits.

i'll need to flesh it out a bit more and open it for general discussion

ocharles: are you going to write a syntax linter go check these? :P

s/go/to/

i wish i could

GNU Indent is specific to C, I think.

Perl::Critic is the canonical solution for perl I guess?

that's more for actual code linting

Perl::Critic::Policy::CodeLayout has checks for a couple of things you've listed in the linked gist.

well, one thing :)

we have t/author/no-tabs.t for that too

reosarevok: do you think it would be a good idea for me to submit the BBC artwork for the releases we have reviewed?

Can't hurt, I think

(make sure they have no existing front image, though)

sure

(in the archive, from Amazon is OK)

yeah

Should have bigish images for them

we are about to rebuild our tools