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)
2024-06-27 17913, 2024
reosarevok[m]
Is it intentional that we didn't finish releasing beta do you know?
2024-06-27 17922, 2024
reosarevok[m]
Or should I just do a beta release?
2024-06-27 17909, 2024
reosarevok[m]
I'm assuming it's a mistake but since I wasn't that much around recently I don't want to do a dumb
2024-06-27 17938, 2024
yvanzo[m]
Hi reosarevok: It seems to just be an oversight.
2024-06-27 17951, 2024
reosarevok[m]
Ok, I'll update translations and put it out
2024-06-27 17931, 2024
yvanzo[m]
reosarevok: About translations, please have a look at #3300
2024-06-27 17901, 2024
reosarevok[m]
Ah, ok, I can check that before
2024-06-27 17920, 2024
reosarevok[m]
Actually you guys just did a server update, right, so we are supposed to have a proper beta anyway :)
2024-06-27 17921, 2024
yvanzo[m]
No worries, it’s independent.
2024-06-27 17936, 2024
yvanzo[m]
Yes
2024-06-27 17922, 2024
yvanzo[m]
#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?
2024-06-27 17900, 2024
reosarevok[m]
I feel sometimes it's hard to figure out what the name means without the context...
2024-06-27 17910, 2024
reosarevok[m]
Or are comments meant to be short?
2024-06-27 17955, 2024
reosarevok[m]
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 :)
2024-06-27 17915, 2024
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
2024-06-27 17914, 2024
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.
2024-06-27 17904, 2024
reosarevok[m]
Hmm, ok, I forgot we actually don't split those
2024-06-27 17935, 2024
yvanzo[m]
Having several names in extracted comments is fine, but several descriptions would be definitely too long and probably confusing.
2024-06-27 17917, 2024
yvanzo[m]
(I mean more confusing than it already is since it isn’t split anyway.)
2024-06-27 17952, 2024
yvanzo[m]
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.
2024-06-27 17953, 2024
reosarevok[m]
Seems good!
2024-06-27 17902, 2024
reosarevok[m]
Feel free to merge as-is then
2024-06-27 17934, 2024
yvanzo[m]
When adding context keys, we will need a way to prevent all the translations to be marked as fuzzy.
2024-06-27 17902, 2024
reosarevok[m]
Ideally they should still be marked as unreviewed though
2024-06-27 17916, 2024
yvanzo[m]
Only the source strings being split really need to be marked as fuzzy.
2024-06-27 17917, 2024
reosarevok[m]
Since we should review them to make sure they were correct? Dunno, maybe I'm overthinking this
2024-06-27 17941, 2024
reosarevok[m]
Just not "do not show anymore on the site" fuzzy, but "needs approval again" for languages using it
2024-06-27 17931, 2024
yvanzo[m]
For source strings that were unique already, it doesn’t seem needed to make this review mandatory.
2024-06-27 17921, 2024
yvanzo[m]
(We’re speaking of tens of thousands of strings.)
2024-06-27 17939, 2024
reosarevok[m]
Yes. Is there a way to tell which ones were not and only do it for those?
2024-06-27 17950, 2024
reosarevok[m]
Those we could actually even make fuzzy tbh if it's possible
2024-06-27 17908, 2024
yvanzo[m]
Yes, msguniq can help with telling which ones are unique or not.
2024-06-27 17943, 2024
yvanzo[m]
The unknown part to me is how to prevent Weblate from marking everything as fuzzy.
2024-06-27 17903, 2024
mayhem[m] buys more paper and a new print cartridge, so to print this stupid letter
2024-06-27 17918, 2024
mayhem[m] * buys more paper and a new print cartridge, just to print this stupid letter
2024-06-27 17937, 2024
outsidecontext[m joined the channel
2024-06-27 17938, 2024
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.
2024-06-27 17959, 2024
yvanzo[m]
(See the many locations for this source string in the sidebar.)
2024-06-27 17900, 2024
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
2024-06-27 17910, 2024
reosarevok[m]
Those don't actually need review
2024-06-27 17914, 2024
outsidecontext[m
and every of them would become a separate context?
2024-06-27 17939, 2024
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.)
2024-06-27 17914, 2024
yvanzo[m]
(Context keys are set through a script.)
2024-06-27 17910, 2024
yvanzo[m]
But maybe we can just remove the context key (before submitting to Weblate) when there is only one source string location.
2024-06-27 17910, 2024
outsidecontext[m
one way would be to have the script also update the context in all the po files
2024-06-27 17929, 2024
outsidecontext[m
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)
2024-06-27 17913, 2024
outsidecontext[m
would require getting all unique strings + their context and having a script that can apply this to existing po file.
2024-06-27 17914, 2024
reosarevok[m]
Hmm
2024-06-27 17918, 2024
yvanzo[m]
Yes, that would be ideal.
2024-06-27 17924, 2024
reosarevok[m]
That sounds smart
2024-06-27 17947, 2024
yvanzo[m]
I would have to commit not only *.pot files but also *.po files and submit those at the same time to Weblate.
2024-06-27 17903, 2024
outsidecontext[m
yes
2024-06-27 17935, 2024
yvanzo[m]
Thanks, I will try that with only one string at first :)
2024-06-27 17925, 2024
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
2024-06-27 17940, 2024
yvanzo[m]
msguniq has a convenient -u option to print only unique messages.
2024-06-27 17927, 2024
yvanzo[m]
(and discard duplicates, or -d option to print only duplicate messages.)
2024-06-27 17942, 2024
yvanzo[m]
We have to do use the option --no-wrap and wrap with -w for the very last command only.
2024-06-27 17933, 2024
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
2024-06-27 17933, 2024
rimskii[m]
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
2024-06-27 17948, 2024
lucifer[m]
rimskii: both commands are correct.
2024-06-27 17918, 2024
rimskii[m]
ok, thanks
2024-06-27 17931, 2024
rimskii[m]
ill try to run them
2024-06-27 17914, 2024
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 >
2024-06-27 17930, 2024
rimskii[m]
lucifer: seems like its not connecting to db
2024-06-27 17950, 2024
rimskii[m]
not working for spotify_metadata_index neither :(
2024-06-27 17937, 2024
rimskii[m]
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"
2024-06-27 17912, 2024
mayhem[m]
rimskii: are working on wolf?
2024-06-27 17924, 2024
mayhem[m]
* rimskii: are you working on
2024-06-27 17911, 2024
mayhem[m]
there is no container listenbrainz_lb_db_1 running on wolf right now, so that connect string isn't going to work.
2024-06-27 17908, 2024
rimskii[m]
Yes
2024-06-27 17914, 2024
rimskii[m]
Oh(
2024-06-27 17917, 2024
rimskii[m]
What can I do then
2024-06-27 17953, 2024
mayhem[m]
not sure what DB lucifer uses on wolf. lucifer ?
2024-06-27 17930, 2024
relaxo[m] joined the channel
2024-06-27 17930, 2024
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.
2024-06-27 17949, 2024
mayhem[m]
ansh: & monkey ^^^
2024-06-27 17914, 2024
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
2024-06-27 17920, 2024
minimal joined the channel
2024-06-27 17940, 2024
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
2024-06-27 17959, 2024
SothoTalKer joined the channel
2024-06-27 17944, 2024
reosarevok[m]
Yes, it is unless you specifically block a username from being reused
2024-06-27 17900, 2024
reosarevok[m]
Bit late for that now though 🤷♂️
2024-06-27 17910, 2024
Jigen
hm
2024-06-27 17931, 2024
rimskii[m]
<lucifer[m]> "@rimskii: try setting the..." <- thanks a lot, it worked !
2024-06-27 17942, 2024
rimskii[m]
created a new table for apple metadata index
2024-06-27 17956, 2024
Jigen
it's problematic because if this user tries to oauth in jira what happens? 🤔
2024-06-27 17925, 2024
reosarevok[m]
No idea how oauth works wrt usernames, yvanzo will know :)
2024-06-27 17924, 2024
Jigen
we don't want to block tthis user from creating an oauth ticket user tho :O
2024-06-27 17905, 2024
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.
2024-06-27 17923, 2024
Jigen
uh
2024-06-27 17937, 2024
Jigen
any way to fix this?
2024-06-27 17901, 2024
Jigen
should i create a ticket
2024-06-27 17905, 2024
yvanzo[m]
What username do you want for which account?
2024-06-27 17903, 2024
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
2024-06-27 17923, 2024
Jigen
to clarify, i jsut wnat *one* account
2024-06-27 17916, 2024
Jigen
if that's not possible, just rename "catcat" into "MonkeyPython" on jira I guess
