#metabrainz

I’m now ready to send the MBS-8716/MBS-8717 pull request, but I’m unsure what to rebase it on.

great, you can rebase and submit against schema-change-2016-q2

I’m wondering because the schema-change-2016-q2 branch is in a somewhat strange state regarding MBS-8719.

oh, yeah

I was in the middle of rebasing against your latest changes, let me just revert all of it for now

Are we going to reset it pre-merge?

yeah, I'll just force push

OK.

to commit bc83167976986a42faefaf52c3b49dbe2fd0042f

ok, done

QuoraUK: From my perspective, I wouldn't like going to the SF-style images-with-text (there will always be devices where they're hard to read). Some special title string (which depending on type, could precede or follow the editor's name (with i18n implications) does sound interesting.

"Zastai, Master Debater" for having commented on many edits, "Publisher-Friend Zastai" for having created many publishers, that sort of thing.

And perhaps some stylized image indicating overall level, but my feeling is that it should be relatively small (maybe something akin to military symbols, stars, bars etc, possibly bookified).

Just my USD0.02 of course.

Zastai: Yeah, thats a fair point. I hadn't considered mobile devices when I thought of it, and I am actually struggling to figure out a way to not make it look gaudy

I hadn't considered localisation either, that is an excellent point, thank you :)

I do see how adding colors, italics, font weight could make some titles "more desirable" than others

but colors already become an issue, since they should still integrate nicely with the site theme (which can change somewhat over time)

that was my issue with the image one, avoiding clashes with the theme would be difficult

especially thinking ahead where different ones are added

so I'd suggest sticking to adding bold/italic/underlined and some of the various fun unicode glyphs to make titles "special". adding extra "sparkles" like colours/backgrounds would be for higher-level titles anyway, which (most) people won't achieve in the first weeks the feature would be live

yeah, thats super helpful feedback, thanks Zastai :)

if using unicode stuff, mobile devices and what characters they do/don't support would come into play again

(it's not uncommon for firefox to show me placeholders for emoji written by ios/android users, for example; I guess that goes both ways)

yeah, ill make a note to consider other devices and locales. Its not something I usually think of in university coursework tasks :p

and im suprised isn't something they drill into us. I've maybe heard it mentioned once, its a bit of a shame really.

it can get very tricky, and it's definitely something developers should have some basic awareness of

i mean, some languages have fairly complicated rules for plurals (e.g. one word form for singular, one for odd amounts other than one, and one for even amounts) - you don't need to know all those rules, but you should at least be aware that it's not always just a case of adding an "s" when there's more than one :D

QuoraUK: Difference between academia and "real world" software engineering. :)

yeah, I saw a video of how features go through facebook and it was crazy to me

having to rework an entire codebase because you need to support a language that's not very English is not fun.

Freso: absolutely

I've got Localisation, devices and accessibility attached to my monitor to remember now :p

Zastai: I can imagine

Yippee, build fixed!

Project musicbrainz-server_schema-change-2016-q2 build #129: FIXED in 18 min: https://ci.metabrainz.org/job/musicbrainz-serve...

Our software product we have spent an entire year was completely red and green the whole time, at the end our client mentioned he was colourblind

a pretty terrible oversight on our part

Leftmost: QuoraUK: let's go after, so Leftmost gets to sleep in :P

okie dokie

Mmm, sleep.

Sleep is overrated. Coffee is god.

Then we'll do a quick review and launch straight into GSoC talk for an hour and a half :P

I still keep thinking about a good way to do gettext in JS and I can't think of one.

Leftmost: a team of monkeys responding to translation requests in real time. Then we can just use superagent

Ha.

Ideally, it would be handled by the normal browser language choice support. As a Belgian, everyone using geolocation to do language choice is a pet peeve.

Zastai, agreed, with an allowance for user override. The thing is, actually doing the i18n once you know which language to use is non-trivial

.

It's bad enough that sites try to use my local language instead of the English I told my browser to get, but they almost always think they need to speak French to me

And I'm not a Walloon dammit, I speak Flemish.

Oh, I think I have a bug that was probably introduced with the form changes: it seems like the first time I log in after starting up, the form just submits instead of doing the onSubmit().

Vlaams? :)

Inderdaad :)

Does the language thing only apply to html by the way? Or would script hrefs also be turned into foo.en.js?

The JS would likely have to fetch the strings from the server on request somehow, to avoid having to have some sort of GMO interpreter on the client side.

You could "disassemble" an mo (it's an simple format) as a js with some hardcoded function that maps the message to the correct translation. The client would then do all the work. Translators would use msgfmt etc as normal, and the result would be "exploded" for serving.

Zastai, it's simple, but our JS is already kind of slow and I don't personally like the trend of pushing more and more on browsers.

anyway, it's not an easy thing to get right. I once tried to integrate gettext functionality into emacs for use in lisp packages (not altogether dissimilar from the js situation) and that was messy at best,

And I agree, relying too much on client-side scripting is not great.

Project musicbrainz-server_schema-change-2016-q2 build #130: FAILURE in 4 min 14 sec: https://ci.metabrainz.org/job/musicbrainz-serve...

The problem as I see it is that JS doesn't have a good string formatting built-in. Template strings are an improvement, but as far as I can tell there's no way to defer interpretation.

(In case Zastai reads the logs.)

Facebook pretty much brings my laptop to a halt. I really, really, really don't like the increased used of client-side computation.

Yeah, and sites like Facebook make it do way too much.

There's a happy medium to be struck.

Leftmost: well, you can wrap a template string in a function

const mycallabletemplate = (stuff) => `a string ${stuff}`;

LordSputnik, yeah, but that's pretty unwieldy for wrapping every single UI-visible string. :-P