Participating in translations is subject to <a href="https://translations.metabrainz.org/leg… 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.
2023-08-17 22948, 2023
reosarevok
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)
2023-08-17 22958, 2023
mayhem
I like your solution reosarevok
2023-08-17 22913, 2023
yvanzo
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.
2023-08-17 22933, 2023
yvanzo
It’s not really an anonymized email either because the MB username is part of it.
2023-08-17 22922, 2023
reosarevok
Participating in translations is subject to <a href="https://translations.metabrainz.org/leg… 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.
2023-08-17 22924, 2023
reosarevok
?
2023-08-17 22939, 2023
mayhem
sure
2023-08-17 22951, 2023
reosarevok
I understand the point is to explain what kind of privacy thing will be made visible
2023-08-17 22908, 2023
reosarevok
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?
2023-08-17 22916, 2023
reosarevok
(I don't mind yvanzo's original either, but I understand that mayhem wants to rather focus on private stuff that gets made available)
" 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."
2023-08-17 22922, 2023
reosarevok
So we do say elsewhere in the doc that stuff is associated with your username, in which case we should also say it here
2023-08-17 22902, 2023
reosarevok
So I think we could just use the original wording tbh
2023-08-17 22951, 2023
yvanzo
There might be a bit of redundancy in my phrasing too.
2023-08-17 22931, 2023
yvanzo
But I might think so just because it's legal stuff.
2023-08-17 22914, 2023
yvanzo
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.
2023-08-17 22959, 2023
yvanzo
It is not obvious from the current phrasing.
2023-08-17 22901, 2023
reosarevok
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?
2023-08-17 22958, 2023
yvanzo
MeB Weblate username is by default the same as MB username.
2023-08-17 22920, 2023
yvanzo
It is used for the default no-reply email address associated to your MeB Weblate account.
2023-08-17 22940, 2023
reosarevok
Yeah
2023-08-17 22943, 2023
yvanzo
Both username and email address are used in committed translation files and in git commit messages.
2023-08-17 22951, 2023
reosarevok
So whatever email you choose, we'll show your username, right?
2023-08-17 22924, 2023
yvanzo
right
2023-08-17 22919, 2023
reosarevok
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
2023-08-17 22932, 2023
reosarevok
(legal stuff sucks)
2023-08-17 22940, 2023
yvanzo
(it does)
2023-08-17 22908, 2023
yvanzo
That seems more clear indeed.
2023-08-17 22957, 2023
ApeKattQuest
the weblate email isn't like, the mb email right? it's [mbuserame]@weblatemb.foo or whatever
2023-08-17 22923, 2023
ApeKattQuest
make that clear, i guess
2023-08-17 22942, 2023
ApeKattQuest
that's the only thing I, as an user /possible translator care about
2023-08-17 22943, 2023
reosarevok
Yes, unless you choose to use the mb email isntead :)
2023-08-17 22946, 2023
reosarevok
*instead even
2023-08-17 22949, 2023
ApeKattQuest
yea sure
2023-08-17 22947, 2023
yvanzo
mayhem: Updated the PR with reosarevok’s rephrasing!
2023-08-17 22941, 2023
outsidecontext
ApeKattQuest: or any other actual e-mail adresss, if you choose so. but that special address looks something like [mbusername]@users.noreply.translations.metabrainz.org
2023-08-17 22945, 2023
yvanzo
ApeKattQuest: Here is an example: yvanzo <yvanzo@users.noreply.translations.metabrainz.org>
2023-08-17 22921, 2023
reosarevok
Also, yvanzo, bitmap: we were supposed to meet now, right? or is it on the hour? :)
2023-08-17 22900, 2023
bitmap
checking in
2023-08-17 22901, 2023
yvanzo
Yes but I think he is probably catching up on sleep.
2023-08-17 22930, 2023
yvanzo
Hi bitmap, I didn’t to wake you up :D
2023-08-17 22903, 2023
bitmap
I could go back to sleep if you prefer (lol)
2023-08-17 22911, 2023
yvanzo
:D
2023-08-17 22900, 2023
yvanzo
Did the ping really wake you up? ^^
2023-08-17 22918, 2023
bitmap
nah I was here since about 15 minutes before
2023-08-17 22953, 2023
yvanzo
Ok, it's more “legal stuff” that’s appealing you then.
2023-08-17 22958, 2023
ApeKattQuest
appaling more like it amiright??
2023-08-17 22906, 2023
ApeKattQuest
:D
2023-08-17 22918, 2023
bitmap
yeah, that :)
2023-08-17 22919, 2023
yvanzo
Shall we start with the Weblate stuff then?
2023-08-17 22926, 2023
reosarevok
Sure
2023-08-17 22921, 2023
yvanzo
For now it is using the `translations` branch.
2023-08-17 22936, 2023
outsidecontext
yvanzo: how is the plan here? will there be a blog post or some other announcement for weblate?
2023-08-17 22906, 2023
bitmap
are there any MB-related tasks left that need help? documentation changes perhaps?
2023-08-17 22912, 2023
yvanzo
outsidecontext: unlocking all ready projects, testing with volunteers this week, publishing a blog post when ready for newcomers.
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?
2023-08-17 22906, 2023
yvanzo
The changes are stacked in Weblate instances’ git clone of MBS repository before being squashed and committed.
2023-08-17 22922, 2023
yvanzo
But you can force it to push changes using the page for “Repository maintenance” before doing updates.
2023-08-17 22958, 2023
yvanzo
Also if you rebased the branch `translations` on `master` with updated POT files, you can update Weblate accordingly from this same page.
2023-08-17 22936, 2023
yvanzo
It will immediately commit PO files according to the new source messages.
2023-08-17 22947, 2023
bitmap
ah, I see. looking at that page now
2023-08-17 22959, 2023
reosarevok
Can you send a PR to update releasing.md for the new translation flow?
2023-08-17 22914, 2023
yvanzo
(That’s due to the add-on using msgmerge.)
2023-08-17 22919, 2023
yvanzo
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.
2023-08-17 22953, 2023
reosarevok
Ok
2023-08-17 22926, 2023
reosarevok
By the way, is the idea to release prod on monday, or have one more week of beta with weblate stuff in it? :)
2023-08-17 22933, 2023
yvanzo
I can try to update beta today for example.
2023-08-17 22946, 2023
reosarevok
Ok, sounds like a plan
2023-08-17 22909, 2023
yvanzo
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.
2023-08-17 22918, 2023
reosarevok
Yeah, sounds good to me
2023-08-17 22947, 2023
bitmap
I'm planning to review the rest of derat's PRs if you'd like to put those on beta
2023-08-17 22926, 2023
reosarevok
If they are good that would be neat
2023-08-17 22931, 2023
yvanzo
bitmap, reosarevok: We could use Weblate API (or the clinet `wlc`) to fetch statistics about translations.
2023-08-17 22941, 2023
reosarevok
But we can still update beta again a bit later, anyway
2023-08-17 22907, 2023
yvanzo
Those could be used by scripts selecting translations for `test`, `beta`, `prod`.
2023-08-17 22909, 2023
reosarevok
yvanzo: you mean for the blog posts, or for an actual translations page in the MB stats section?
2023-08-17 22911, 2023
reosarevok
Oh
2023-08-17 22919, 2023
yvanzo
Those could also be used for display in the dropdown menu.
2023-08-17 22943, 2023
yvanzo
The MB stats section is good idea too.
2023-08-17 22956, 2023
reosarevok
Probably not a thing we need to work on for release though, fine to add tickets for those things?
outsidecontext: why are the components `app` and `appstream` under a different license at https://translations.metabrainz.org/projects/pica… ? (Reminder: the license of the translations doesn’t have to be the license of the code.)
2023-08-17 22934, 2023
bitmap
I think I did those manually in inkscape
2023-08-17 22908, 2023
reosarevok
Ok, then aerozol might as well just do it himself :D
2023-08-17 22930, 2023
bitmap
yeah, it's been a while but I don't remember having any script to do it
2023-08-17 22949, 2023
outsidecontext
yvanzo: not sure how you mean? they both have the same license (gpl-2.0)
outsidecontext: different from the rest I guess :)
2023-08-17 22917, 2023
yvanzo
outsidecontext: most components are under CC0-1.0.
2023-08-17 22914, 2023
outsidecontext
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
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.”
2023-08-17 22932, 2023
outsidecontext
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
2023-08-17 22944, 2023
reosarevok
bitmap: so https://github.com/metabrainz/musicbrainz-server/… 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?
2023-08-17 22946, 2023
yvanzo
outsidecontext: I see that picard-website has no license, that’s how you could pick CC0, right?
2023-08-17 22911, 2023
outsidecontext
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
2023-08-17 22951, 2023
outsidecontext
picard-website really *should* have a license set. so we should pick something here and ask the contributors
2023-08-17 22918, 2023
bitmap
reosarevok: well, the difference is that /release/add is seeded via a POST request. other entity forms are just seeded via query parameters
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.
2023-08-17 22947, 2023
outsidecontext
bitmap, reosarevok: yes it does
2023-08-17 22955, 2023
yvanzo
(ffs, after legal stuff, license stuff)
2023-08-17 22900, 2023
outsidecontext
yvanzo: good move
2023-08-17 22913, 2023
bitmap
ok, I'll have to test with that
2023-08-17 22937, 2023
reosarevok
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)
2023-08-17 22946, 2023
bitmap
does it POST without an edit note so that the user can review it first, or?
2023-08-17 22924, 2023
reosarevok
Well, the POST just seeds, AFAICT, from my basic testing
2023-08-17 22936, 2023
outsidecontext
and it does not seed edit note. Only artist, recording name and duration
2023-08-17 22948, 2023
outsidecontext
and I think artist name is actually broken
2023-08-17 22904, 2023
outsidecontext
but I haven't looked into this yet
2023-08-17 22936, 2023
reosarevok
Yeah, it is, but it might be a MBS issue, not sure
2023-08-17 22930, 2023
bitmap
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
2023-08-17 22955, 2023
bitmap
(but if an edit note was seeded then I think it would submit the edit immediately after the confirmation page)
2023-08-17 22906, 2023
reosarevok
Hmm
2023-08-17 22918, 2023
reosarevok
Ok, so maaaybe picard should be using query params ehre?
