#metabrainz

LordSputnik, I was gonna ask about that. Shouldn't we put them in direct-database to avoid all sorts of merge fun (again)?

Or should we branch direct-database for the react conversions?

Leftmost: well, they have nothing to do with direct-database

I'd say branch direct-database then.

But I want to test them in master

Testing in direct-database requires setting up a whole new database :P

Alright.

I could make a new branch, cherry pick all the commits up to the react pages to that new branch, cherry pick the react page commits to master, cherry pick all the commits after the react pages to the new branch, then delete the old direct-database?

I'll try that now

Heh, okay.

To summarize my comments last night, I think http://yuml.me/edit/446257be is our best way forward.

Leftmost: removing the BBIDs from relationship?

Yeah.

Leftmost: we could just make it so that entity data can only ever be used by one BBID, and one merging you'd need to create new entity data and a new relationships set - that way, we avoid the issue of changing BBIDs, and can still record BBIDs on the relationship (which I think is also needed)

Hmm. Why would we need to record BBIDs on the rel? It doesn't really change how far we have to drill down to display a relationship in the end.

Well, because the source and target BBIDs are a property of the relationship anyway

Well, I'd argue that the source and target entities are a property of the rel, whereas BBID is a (mutable) property of the entity.

BBID isn't mutable for an entity though

If it has a different BBID it's a different entity

I guess I'm looking at it like "entity B is merged into entity A; entity B's identity hasn't changed, but the BBID referring to it has".

The issue I see with creating new relationships is that it means the revision now has to touch every entity related to the changed entity.

If entity B is related to entity C, is it really a revision to entity C to merge B into A?

Eww no

OK, so no BBIDs

Now the question is, can we merge RelationshipSet_Relationship and Relationship

If we keep them separate, if we duplicate a RelationshipSet, we need to create a new RelationshipSet_Relationship for each relationship in the set

If we merge them, if we duplicate a RelationshipSet, we need to create a new Relationship for each relationship in the set

In both cases, the amount of storage needed is exactly the same :P

Ah, but if we merge them it does become harder to keep object synchronised, forget that idea :P

I think keeping them separate is better, personally, though I don't know why right now. :-P

OK, let's go with this diagram then

Leftmost: http://yuml.me/edit/86aaba0d has fixed cardinality

LordSputnik pushed 1 commits to bookbrainz-site: https://github.com/bookbrainz/bookbrainz-site/c...

LordSputnik, looks good to me at a glance.

LordSputnik pushed 1 commits to bookbrainz-site: https://github.com/bookbrainz/bookbrainz-site/c...

OK, and react pages are now in master too

Yay! Thank you. :)

I was thinking about i18n last night. Template strings _almost_ get us everything we need for gettext. So close, but not there. :\

Leftmost: what do you mean? I'm unfamiliar with the dark arts of i18n ;)

I18n even worse one may think at first. :)

But that's still better than to force the rest of the world to speak and write french ;)

For proper i18n you need to be able to rearrange the contents of a string, so concatenation doesn't work. You need to be able to translate the string as a whole. Tagged templates allows that. However, in order to do this you often need to be able to rearrange _parameters_. You can technically do that with tags, but there's no way to access which parameters are which in the original, so you don't know how to rearrange, and you'd also

have to do the parsing work for what's a parameter in the translated string.

You can return functions from tags, and you could presumably do it with those, but you'd end up with something gross like __`${'soandso'} published ${'suchandsuch'}`({ soandso: 'FooBooks', suchandsuch: 'Foo Guide to Bartending' }).

Leftmost: have you seen FormatJS?

Hmm, no.

bitmap: if you have any time later: http://tickets.musicbrainz.org/browse/STYLE-576

Okay, their plural handling fails.

Plural handling and parameter rearrangement are the top reasons I like gettext, because I have yet to see another i18n framework that gets it even as right as they do.

LordSputnik, are you working on updating the SQL? I'll do it if not.

Leftmost: i agree gettext does a better job with plurals than most other stuff around. Apart few cases it covers i18n issues quite well.

It's definitely not perfect, but everything else I've looked at fails in a lot of cases where gettext succeeds.

LordSputnik, stanislas is asking for some insights into the calibre task. Thought you might have a better idea of the calibre side.

stanislas, is there anything in particular you're having trouble with or just hoping for a general picture?

just hoping for a general picture as for now

i am going to follow this guide http://manual.calibre-ebook.com/creating_plugin...

That's a good place to start. The idea would be to consume the BookBrainz web service from the plugin code in order to get book metadata.

stanislas: that's exactly what I would've pointed you to :)

great

and where could i read about getting metadata from BookBrainz ?

LordSputnik, mucking with the SQL a bit and then I'm going to tackle adding revisions and relationships and aliases and all that fooferah.

stanislas: for your task, you'll want to use the search endpoint of the API

That one is quite simple :) You can see an example (in JS) at the bottom of https://github.com/bookbrainz/bookbrainz-site/b...

(the endpoint is simple to use, that is, not the task)

yeah, but googling bookbrainz api wasn't succsesful

thanks

So you'll probably want to query the webservice several times. First to the /search endpoint, to get results, then once for each of the results, with the /entity/:bbid endpoint

stanislas: yeah, our documentation is fairly rubbish I'm afraid, it's on the list of things to-do, but that's a very long list!

i've little knowledge of js, so i will try to figure something out

do i have to fully learn it ?

Leftmost: the only project I've seen that claims to handle plurals better is https://github.com/SlexAxton/messageformat.js

stanislas: oh no, you won't need JS for the task, that code was just an example, sorry!

(it was written by the author of Jed, which is what mbserver uses for gettext on the client)

Line 114 of that JS file shows the format of the data you need to pass to the API (you can do that with python's requests library)

So you'd make a dict {q: "Search string here", mode: "search"} and then use that as the data :)

LordSputnik: that sounds easy, thanks

stanislas: here's an example search https://bookbrainz.org/ws/search?q="a"&...;

that should give you an idea of the format of results too :)

The zero/one/two/few/many/other paradigm doesn't work well for Irish, unfortunately. The Irish rules I use for GNOME depend on a mod 10 check.

There are a lot of things that messageformat.js seems to do right (distinguishing ordinals, for example), but forcing that paradigm is just bad.

LordSputnik. In this example you provided, are these results for some search ?

stanislas: yes, so there, the query string is "a", and results are listed under the key "hits" in a list

Each item in the list is a dict, and has a "score", which indicates relevance

leftmostcat pushed 2 commits to bookbrainz-sql: https://github.com/bookbrainz/bookbrainz-sql/co...

LordSputnik: ok, seems clear to me

stanislas: good luck :)

Please let us know if you have any more questions!

LordSputnik: thanks, i will need it

:)

We're here to help. Sorry I couldn't be of more use on getting you started. :)

Leftmost: so what is the interface to gettext?

format.js looks quite nice because it comes with React integration

And what's wrong with the pluralisation there?

It depends on that same zero/one/two/few/many/other paradigm.

Is the handling of parameters any better in format.js than gettext?

In C, you'd often do something like (as an example) sprintf(_("This is a string: %s"), inserted_str), where _() is the gettext wrapper. For plurals, sprintf(N_("There is %d message", "There are %d messages", n), n), where N_ is the plural gettext wrapper.

Gettext parameter handling is generally fine. It's JavaScript's lack of anything sprintf-like that causes problems.

Well, JavaScript does have template strings now

Right, but you can't manipulate them directly, only declare them as a literal.

Also, I don't even know where to start evaluating this, but : https://slexaxton.github.io/Jed/

you can always steal MB's interpolation syntax

You can use tags to mess with the broken-up strings and parameter values, but you can't touch the template itself or get a sense of parameter keys.

I'll take a look at MB's. It's being used client-side in react, right?

yeah

LordSputnik, do we pretty much have the schema hammered out at this point?

we have some convoluted function to interpolate react elements inside the text

(Structurally, at least. Not in terms of actual SQL.)

e.g. https://github.com/metabrainz/musicbrainz-serve...

(you have to pass __react: true for it to work, but it could be detected in some cases)

i certainly will, after creating this plugin i will have some insights on how to use it :)

LordSputnik, any objection to changing the dimensions fields to strings? Libraries tend to use a string format, especially for pages.

Hmm. Editions are gendered now? :-P

leftmostcat pushed 5 commits to bookbrainz-sql: https://github.com/bookbrainz/bookbrainz-sql/co...

Still need to do identifiers, aliases, and relationships.

reosarevok: Seems like you've been on top of the account creations.

!m reosarevok

You're doing good work, reosarevok!

I'll be going to bed early tonight, which OTOH probably means I'll be up early in the morning.

G'night y'all.

Sleep well :)

thanks bitmap :)

np

alastairp: I guess Sertan will see from the ticket, but added now

Leftmost: Ah, I looked closer into the plperl issue, and it *is* there after all, but it needs recompiling.

It links to libperl.so.5.10, which is no longer there because there is an updated perl now.

chirlu`, okay. I'll figure out how to get it compiled

.

If I change a string in Picard, how do I ensure all the language files update it as well?

Picard is set up in such a way that if a string changes, the translators will be able to automatically pull in those changes and make the appropriate adjustments to their translation.

that's only half true, you need to follow https://github.com/musicbrainz/picard/blob/mast... to update the source file for the translations

Ahh, huh.

Ok, then is http://tickets.musicbrainz.org/browse/PICARD-692 a simple text change? I am not aware that Picard is able to read the registry for alternative operating systems to read the default music player, and additionally pull in icons as well...

it uses some Qt api to automatically open the file in whatever player the user has configured

and yes, all that's required for that ticket is to change the text and update the translation source file :)

I am intrigued about how the Transifex works. Once the pot file is uploaded, the Transifex server performs a pull request daily to update any changes throughout all languages?