#metabrainz

yeah. not great.

[metabrainz.org] 14yvanzo opened pull request #424 (03master…weblate-policy): Update privacy policy for switching to Weblate https://github.com/metabrainz/metabrainz.org/pu...

mayhem: yummy legal stuff to look into ^ :)

jpy

joy even

yvanzo: I'm not sure if the details of user emails vs user names should be mentioned in the privacy policy.

[musicbrainz-server] 14reosarevok merged pull request #3015 (03master…MBS-13214): MBS-13214 / MBS-13238: Improve Open Library handling https://github.com/metabrainz/musicbrainz-serve...

Where should this be mentioned instead?

"Participating in our translation projects may require you to specify an email address. For more details, see <link>."

how about that?

and then the details of username wrt to privacy should be listed on translations.meb

But this specific point is not explained in those linked pages.

could it be?

No because these pages are generic and this point depends on our settings.

See the PR description.

Wait, if the default doesn't have any privacy issues, can we just say something like

For more background about this specific issue: https://community.metabrainz.org/t/why-does-web...

Participating in translations is subject to <a href="https://translations.metabrainz.org/l... legal terms</a>. If you so chose, you can use your own email address for translations, which will in that case be visible in our git repositories.

Or something to that effect, saying there's a possibility that will happen if you pick it? I guess otherwise there's no privacy issues at all? (by default)

I like your solution reosarevok

The goal here is to reassure people that may freak out about making their email public, not really that you can make your email public.

It’s not really an anonymized email either because the MB username is part of it.

Participating in translations is subject to <a href="https://translations.metabrainz.org/l... legal terms</a>. As per those, an email address will be visible in our git repositories; this will be a custom no-reply address by default and we will only publish your actual email address if you actively chose to.

?

sure

I understand the point is to explain what kind of privacy thing will be made visible

I don't think we have to worry about usernames being made visible, because that's public information so it doesn't really affect a privacy policy I guess?

(I don't mind yvanzo's original either, but I understand that mayhem wants to rather focus on private stuff that gets made available)

exactly

public usernames are PII

first links from a quick search: https://termly.io/resources/articles/personal-i... https://www.clickinsight.ca/blog/usernames-priv...

Ok, fair

" If you make any changes to a MetaBrainz project database, such as adding any data, the details of those changes will be visible to other logged-in users and the change will be associated with your username."

So we do say elsewhere in the doc that stuff is associated with your username, in which case we should also say it here

So I think we could just use the original wording tbh

There might be a bit of redundancy in my phrasing too.

But I might think so just because it's legal stuff.

Also I’m not sure if it is needed to add that if you select a different email address at some point, the previously selected email address will still be visible for the previous commits in our Git repositories.

It is not obvious from the current phrasing.

yvanzo: what does it use as a git username? your mb username? or is it no username, just email? I forget how that works sometimes, I know it has name + email sometimes at least?

MeB Weblate username is by default the same as MB username.

It is used for the default no-reply email address associated to your MeB Weblate account.

Yeah

Both username and email address are used in committed translation files and in git commit messages.

So whatever email you choose, we'll show your username, right?

right

So we could specify that "Any translations you make will be submitted to git and publicly associated with your username; if you so choose, you can also publicly associate them with your email address." or something to that effect

(legal stuff sucks)

(it does)

That seems more clear indeed.

the weblate email isn't like, the mb email right? it's [mbuserame]@weblatemb.foo or whatever

make that clear, i guess

that's the only thing I, as an user /possible translator care about

Yes, unless you choose to use the mb email isntead :)

*instead even

yea sure

mayhem: Updated the PR with reosarevok’s rephrasing!

ApeKattQuest: or any other actual e-mail adresss, if you choose so. but that special address looks something like [mbusername]@users.noreply.translations.metabrai...

ApeKattQuest: Here is an example: yvanzo <yvanzo@users.noreply.translations.metabrainz.or...;

Also, yvanzo, bitmap: we were supposed to meet now, right? or is it on the hour? :)

checking in

Yes but I think he is probably catching up on sleep.

Hi bitmap, I didn’t to wake you up :D

I could go back to sleep if you prefer (lol)

:D

Did the ping really wake you up? ^^

nah I was here since about 15 minutes before

Ok, it's more “legal stuff” that’s appealing you then.

appaling more like it amiright??

:D

yeah, that :)

Shall we start with the Weblate stuff then?

Sure

For now it is using the `translations` branch.

yvanzo: how is the plan here? will there be a blog post or some other announcement for weblate?

outsidecontext: unlocking all ready projects, testing with volunteers this week, publishing a blog post when ready for newcomers.

ok

bitmap, reosarevok: I added both of you to the administration team of https://translations.metabrainz.org/projects/mu... so you can manage repository maintenance.

thanks

I see the weblate commits in the translations branch. are those pushed to the branch whenever a change is made to a .po file, or are they synced on a schedule, or?

The changes are stacked in Weblate instances’ git clone of MBS repository before being squashed and committed.

But you can force it to push changes using the page for “Repository maintenance” before doing updates.

Also if you rebased the branch `translations` on `master` with updated POT files, you can update Weblate accordingly from this same page.

It will immediately commit PO files according to the new source messages.

ah, I see. looking at that page now

Can you send a PR to update releasing.md for the new translation flow?

(That’s due to the add-on using msgmerge.)

reosarevok: The idea is to rebase `translations` on `master` and then to merge `translations` into `beta` but I thought that we should try to follow this for a full release to see if it works as expected before formalizing it.

Ok

By the way, is the idea to release prod on monday, or have one more week of beta with weblate stuff in it? :)

I can try to update beta today for example.

Ok, sounds like a plan

I’m fine with delaying it by a week given we have many changes in `master` and so we can try having multiple `beta` updates.

Yeah, sounds good to me

I'm planning to review the rest of derat's PRs if you'd like to put those on beta

If they are good that would be neat

bitmap, reosarevok: We could use Weblate API (or the clinet `wlc`) to fetch statistics about translations.

But we can still update beta again a bit later, anyway

Those could be used by scripts selecting translations for `test`, `beta`, `prod`.

yvanzo: you mean for the blog posts, or for an actual translations page in the MB stats section?

Oh

Those could also be used for display in the dropdown menu.

The MB stats section is good idea too.

Probably not a thing we need to work on for release though, fine to add tickets for those things?

bitmap: do you still have the script or whatever you used to invert icons? (for https://github.com/metabrainz/musicbrainz-serve...)

outsidecontext: why are the components `app` and `appstream` under a different license at https://translations.metabrainz.org/projects/pi... ? (Reminder: the license of the translations doesn’t have to be the license of the code.)

I think I did those manually in inkscape

Ok, then aerozol might as well just do it himself :D

yeah, it's been a while but I don't remember having any script to do it

yvanzo: not sure how you mean? they both have the same license (gpl-2.0)

bitmap: also, can you maybe check https://github.com/metabrainz/musicbrainz-serve... too?

outsidecontext: different from the rest I guess :)

outsidecontext: most components are under CC0-1.0.

entire picard content except for some of the images has always been gpl-2.0. as no specific separate license ever had been specified for translations I don't think I can change the license to CC0

https://tickets.metabrainz.org/browse/MBS-11947 oh that's Great! I love this fix

MBS-11947: Add focus indicator to all links

:DDD

[musicbrainz-server] 14reosarevok merged pull request #2927 (03master…MBS-12948): MBS-12948 / MBS-13051: Wrap more long stuff in release pages https://github.com/metabrainz/musicbrainz-serve...

reosarevok: approved

I saw :D

nvm then :)

outsidecontext: fair, I guess that we should do the same for MBS translation files which just have “This file is distributed under the same license as the PACKAGE package.”

yvanzo: yes, I think so. for any newly started project or any project that just startes to get translartions I'd recommend choosing a separate license for translations. but for existing code that never specified anything my understanding is that we must stay with project license

bitmap: so https://github.com/metabrainz/musicbrainz-serve... only works for release/add but not for every other form? I guess it's fine in that that's the most commonly seeded one, but is there no way to do the same for other forms later on?

outsidecontext: I see that picard-website has no license, that’s how you could pick CC0, right?

yvanzo: I actually just picked it. Also because translations where pretty new and just recently done by zas and myself. But actually that's something I only noticed when doing the weblate setup

picard-website really *should* have a license set. so we should pick something here and ask the contributors

reosarevok: well, the difference is that /release/add is seeded via a POST request. other entity forms are just seeded via query parameters

for the translations it was easy, because it is only zas and me (https://github.com/metabrainz/picard-website/co...)

unless zas now comes around and wants the license changed :)

bitmap: hmm, pretty sure Picard POSTs standalone recording seeding?

Some MB components are actually translating the database so that’s CC0, only the server code isn’t so I changed the Server component only.

bitmap, reosarevok: yes it does

(ffs, after legal stuff, license stuff)

yvanzo: good move

ok, I'll have to test with that

bitmap: maybe that's connected to the reason why Picard's posted artist credit breaks, if it's not meant to be done like that (that ticket I shared recently)

does it POST without an edit note so that the user can review it first, or?

Well, the POST just seeds, AFAICT, from my basic testing

and it does not seed edit note. Only artist, recording name and duration

and I think artist name is actually broken

but I haven't looked into this yet

Yeah, it is, but it might be a MBS issue, not sure

ah right, so the lack of an edit note doesn't matter, because the request being cross-origin is what prevents MB from submitting the edit

(but if an edit note was seeded then I think it would submit the edit immediately after the confirmation page)

Hmm

Ok, so maaaybe picard should be using query params ehre?

*here