yvanzo: I saw a bug on beta that works locally and noticed beta is running 4f74045621 which is two weeks old (the bug is fixed in the last mb beta branch commit)
Is it intentional that we didn't finish releasing beta do you know?
Or should I just do a beta release?
I'm assuming it's a mistake but since I wasn't that much around recently I don't want to do a dumb
yvanzo[m]
Hi reosarevok: It seems to just be an oversight.
reosarevok[m]
Ok, I'll update translations and put it out
yvanzo[m]
reosarevok: About translations, please have a look at #3300
reosarevok[m]
Ah, ok, I can check that before
Actually you guys just did a server update, right, so we are supposed to have a proper beta anyway :)
yvanzo[m]
No worries, it’s independent.
Yes
#3300 just needs to land the branch beta for serving its purpose, it doesn’t even need to be deployed.
yvanzo: would it make sense for the name to have the *description* as the comment as well?
I feel sometimes it's hard to figure out what the name means without the context...
Or are comments meant to be short?
I was confused about why the languages comments were changing but that seems to be harmless so otherwise this looks great, just wondering if it can be a bit better still :)
reosarevok[m] goes walk the dog for a bit, can do the beta release once he's back - including this PR, with or without the descriptions for names
yvanzo[m]
reosarevok: It would make sense if the name couldn’t be used for more than one relationship type. I would leave that for another time, after we’ve added context keys to relationship type names.
reosarevok[m]
Hmm, ok, I forgot we actually don't split those
yvanzo[m]
Having several names in extracted comments is fine, but several descriptions would be definitely too long and probably confusing.
(I mean more confusing than it already is since it isn’t split anyway.)
Yes the change in language’s extracted comments is harmless, just removing the trailing space. As written, changes in extracted comments in general are not discarding the existing translations.
reosarevok[m]
Seems good!
Feel free to merge as-is then
yvanzo[m]
When adding context keys, we will need a way to prevent all the translations to be marked as fuzzy.
reosarevok[m]
Ideally they should still be marked as unreviewed though
yvanzo[m]
Only the source strings being split really need to be marked as fuzzy.
reosarevok[m]
Since we should review them to make sure they were correct? Dunno, maybe I'm overthinking this
Just not "do not show anymore on the site" fuzzy, but "needs approval again" for languages using it
yvanzo[m]
For source strings that were unique already, it doesn’t seem needed to make this review mandatory.
(We’re speaking of tens of thousands of strings.)
reosarevok[m]
Yes. Is there a way to tell which ones were not and only do it for those?
Those we could actually even make fuzzy tbh if it's possible
yvanzo[m]
Yes, msguniq can help with telling which ones are unique or not.
The unknown part to me is how to prevent Weblate from marking everything as fuzzy.
mayhem[m] buys more paper and a new print cartridge, so to print this stupid letter
mayhem[m] * buys more paper and a new print cartridge, just to print this stupid letter
outsidecontext[m joined the channel
outsidecontext[m
yvanzo: what exactly changes on the source strings and how many are affected?
I see. When it only affects a few source strings and I knew it would not affect translations (e.g. fixed a typo or something) I sometimes removed the fuzzy from po files with some search and replace.
But not sure about your case. If you are splitting those because of enabling different translations it probably does affect translations and should be reviewed.
yvanzo[m]
(See the many locations for this source string in the sidebar.)
reosarevok[m]
Yes, they should. The question is for the ones where we would add context "artist-artist relationship" or whatever, but there's actually no other cases
Those don't actually need review
outsidecontext[m
and every of them would become a separate context?
yvanzo[m]
outsidecontext: My initial idea was to add context keys to all the source strings, even when not needed (because some source strings are used at only one place already.)
(Context keys are set through a script.)
But maybe we can just remove the context key (before submitting to Weblate) when there is only one source string location.
outsidecontext[m
one way would be to have the script also update the context in all the po files
at least for the unique strings add the context also to the po files, so they are actually unchanged. and only afterwards update them regularly (to get the separate entries for those with multiple context)
would require getting all unique strings + their context and having a script that can apply this to existing po file.
reosarevok[m]
Hmm
yvanzo[m]
Yes, that would be ideal.
reosarevok[m]
That sounds smart
yvanzo[m]
I would have to commit not only *.pot files but also *.po files and submit those at the same time to Weblate.
outsidecontext[m
yes
yvanzo[m]
Thanks, I will try that with only one string at first :)
outsidecontext[m
yes, the script might be tricky, especially for longer strings that are split across multiple lines. not sure if and which gettext tools can help with that
yvanzo[m]
msguniq has a convenient -u option to print only unique messages.
(and discard duplicates, or -d option to print only duplicate messages.)
We have to do use the option --no-wrap and wrap with -w for the very last command only.
rimskii[m]
<lucifer[m]> "rimskii: ah okay, yes you need..." <- `./build.sh` should do the trick, right? I ran it, but seems its not enough
Should I ran "docker run --rm -it --network musicbrainz-docker_default metabrainz/mbid-mapping python3 manage.py build_apple_metadata_cache --use-mb-conn"? Just scared that it rewrite the whole db
lucifer[m]
rimskii: both commands are correct.
rimskii[m]
ok, thanks
ill try to run them
PrathamGupta[m]
Hi, is there any documentation available for listenbrainz?
rimskii[m] uploaded an image: (703KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/matrix.org/OTITZlHDZsnpnsbiRsdvRjWT/Screenshot%202024-06-27%20at%2017.42.11.png >
rimskii[m]
lucifer: seems like its not connecting to db
not working for spotify_metadata_index neither :(
is this correct route for db? SQLALCHEMY_TIMESCALE_URI = "dbname=listenbrainz_ts user=listenbrainz_ts host=listenbrainz_lb_db_1 port=5432 password=listenbrainz_ts"
mayhem[m]
rimskii: are working on wolf?
* rimskii: are you working on
there is no container listenbrainz_lb_db_1 running on wolf right now, so that connect string isn't going to work.
rimskii[m]
Yes
Oh(
What can I do then
mayhem[m]
not sure what DB lucifer uses on wolf. lucifer ?
relaxo[m] joined the channel
relaxo[m]
Is it known that brainz player (web) is entering an infinite playback loop if a track present twice? Both entries are shown as playing and after playing the second it jumps to the track after the first.
mayhem[m]
ansh: & monkey ^^^
lucifer[m]
<rimskii[m]> "lucifer: seems like its not..." <- @rimskii: try setting the timescale uri to same as MB database uri and run without --use-mb-conn
minimal joined the channel
Jigen
yvanzo[m]: hi! so I'm testing out Oauth on Jira tickets and it's an odd thing because the Oauth seems to think my username from musicbrainz is still "CatCat?
There was a separate account that I renamed in Jira, but apparently there's two and I'm not sure what to do about it and how that matches with oauth :)
maybe within a certain time but not right away, I feel
SothoTalKer joined the channel
reosarevok[m]
Yes, it is unless you specifically block a username from being reused
Bit late for that now though 🤷♂️
Jigen
hm
rimskii[m]
<lucifer[m]> "@rimskii: try setting the..." <- thanks a lot, it worked !
created a new table for apple metadata index
Jigen
it's problematic because if this user tries to oauth in jira what happens? 🤔
reosarevok[m]
No idea how oauth works wrt usernames, yvanzo will know :)
Jigen
we don't want to block tthis user from creating an oauth ticket user tho :O
yvanzo[m]
MB SSO in Jira is based on email address. It copies the username the first time but doesn’t keep it in sync otherwise.
Jigen
uh
any way to fix this?
should i create a ticket
yvanzo[m]
What username do you want for which account?
Jigen
ApekattQuest, MonkeyPython is my username on mb, and the oauth account is catcat, i was hoping the oauth account could *be* "ApekattQuest, MonkeyPython" but i don't know ifthat's possible :O
to clarify, i jsut wnat *one* account
if that's not possible, just rename "catcat" into "MonkeyPython" on jira I guess
