reosarevok it should still be the expected order in byte order. So if it is {url|hebrew} in the source it should stay {url|hebrew} in byte order
2024-01-04 00428, 2024
reosarevok
So is the brace error on that string correct or wrong?
2024-01-04 00453, 2024
outsidecontext
let me check
2024-01-04 00401, 2024
abhis has quit
2024-01-04 00424, 2024
outsidecontext
yes, that was correct. I fixed it. It's sometimes hard to see in text, especially if the text ends up bidirectional
2024-01-04 00406, 2024
outsidecontext
to be sure I copied the label ("מערכתההצעות"), removed the entire brace thing and just started to type with {url| , paste the label here, close with }
2024-01-04 00440, 2024
outsidecontext
the confusing part is that if you type { (opening brace) in RTL mode it will point the other direction then we are used to :D
2024-01-04 00441, 2024
yvanzo
I guess that we should use the switch LTR to see variable syntax in the usual way.
2024-01-04 00408, 2024
outsidecontext
yes, indeed. that can often be helpful
2024-01-04 00412, 2024
reosarevok
Oh
2024-01-04 00417, 2024
reosarevok
There's a switch
2024-01-04 00421, 2024
reosarevok
Good to know :D
2024-01-04 00423, 2024
reosarevok goes find it
2024-01-04 00449, 2024
yvanzo
just under the translation text field, on the left
2024-01-04 00401, 2024
yvanzo
well, the right
2024-01-04 00419, 2024
reosarevok
Ok, that's helpful
2024-01-04 00436, 2024
reosarevok
It's still confusing as hell to *fix* but at least I know if it's fixed...
2024-01-04 00443, 2024
outsidecontext
in complex cases where you also have things mixed with actually displayed latin text it can become rather complex. in bidirectional text the flow often switches automatically, but the automatic mode can be wrong if punctuation is included that can be both. With Picard I found that sometimes I could only check in the final code (the Hebrew translator was really struggling with this)
2024-01-04 00430, 2024
outsidecontext
and if it's wrong direction you have to explicitly add RTL or LTR markers
2024-01-04 00417, 2024
kellnerd
reosarevok: So these singular strings without {num} placeholders do not cause problems? I've "fixed" a few of them recently, but I might revert back from "1" to the equivalent of "a/an" which reads more natural in that case :)
2024-01-04 00422, 2024
reosarevok
😭
2024-01-04 00440, 2024
reosarevok
kellnerd: I dunno :D Do they break if you load that page in German? If not, probably not
2024-01-04 00444, 2024
outsidecontext
kellnerd: I already wondered about this
2024-01-04 00459, 2024
reosarevok
Try to test it live and let's see from there
2024-01-04 00447, 2024
atj
zas: based on backlog it seems barman is the cause of excessive WALs
yvanzo: this seems to be correct judging by the result of setting https://beta.musicbrainz.org/relationship/9162ded… to Dutch but it hits a check - I could just dismiss but this might show a bug in our check design?
kellnerd: I’ve fixed singular forms to use {n} in French at least.
2024-01-04 00441, 2024
yvanzo
(or {num})
2024-01-04 00459, 2024
kellnerd
Ok, so it seems I have to fix the last two remaining strings as well, although it would look better if they could stay as is
2024-01-04 00455, 2024
kellnerd
Done
2024-01-04 00401, 2024
yvanzo
Not using it shouldn’t cause any problem in most cases as the MBS code usually has a separate source string for 0 but there is no guarantee about it.
2024-01-04 00424, 2024
yvanzo
reosarevok: the second occurrence of `medium:` seems to be extraneous.
2024-01-04 00437, 2024
reosarevok
yvanzo: hmm, why does it still work? :D
2024-01-04 00450, 2024
yvanzo
The relationship type pages don’t perform a full interpolation.
2024-01-04 00459, 2024
kellnerd
yvanzo: At least the cover art statistics page does not seem to pick up the old German translation (not even for plural) where the {num} placeholder is missing for the singular (see link above).
Do we even allow interpolating {entity1} on short phrase display?
2024-01-04 00438, 2024
reosarevok
Probably not?
2024-01-04 00424, 2024
reosarevok
"Spanish, Many (1000000, 2000000)" that seems random to me...
2024-01-04 00427, 2024
reosarevok
Anyway, yvanzo: so, is Found {n} result for "{q}" -> Se encontró un resultado para "{q}" correct or should it be changed to use {n} ? Is that what you told kellnerd is a MBS bug?
2024-01-04 00418, 2024
reosarevok
(Estonian for example also does "see all versions of this release, {count} available" -> "see release group" for singular, which might or might not be broken)
"Seuraa {bl|blogiamme} tai {tw|twitter-tiliämme}! Puhuaksesi muiden käyttäjien kanssa, kokeile {fo|keskustelufoorumia} tai {irc|IRC:tä}." this triggers a clash, wonder if it is the colon in IRC:tä
2024-01-04 00459, 2024
reosarevok
outsidecontext: is there a way to see exactly what part is triggering a check?
2024-01-04 00404, 2024
djl has quit
2024-01-04 00458, 2024
djl joined the channel
2024-01-04 00426, 2024
yvanzo
reosarevok: the bug is about “the cover art statistics page does not seem to pick up the […] translation”
2024-01-04 00450, 2024
outsidecontext
reosarevok: depends on the check, but in this case no as the check does not implement this
2024-01-04 00434, 2024
outsidecontext
yvanzo: kellnerd: I still haven't understood this fully. Can or can't we use a translated "one" instead of "{num}" in singular strings? and if not why not and could this be changed?
2024-01-04 00451, 2024
kellnerd
It seems unrelated to that. None of the translations which I've tried (French, Italian, Dutch) seems to be picked ub by MBS.
2024-01-04 00402, 2024
kellnerd
*up by
2024-01-04 00452, 2024
kellnerd
So it seems that we can use "one/a/an" instead of "{num}" just fine for strings in singular.
2024-01-04 00413, 2024
yvanzo
You seem to be mixing issues here.
2024-01-04 00428, 2024
kellnerd
Quite the contrary, I had been mixing them up, but later realized that there are two
2024-01-04 00431, 2024
yvanzo
The bug about some translations not being picked up is unrelated to this.
2024-01-04 00405, 2024
yvanzo
OK but it doesn’t mean it is just fine not to reuse `{n}` or `{num}`in translations :)
2024-01-04 00438, 2024
kellnerd
Yeah, I am not 100% sure about that, but according to reosarevok's "see all versions of this release, {count} available" example it seems to work in certain places at least.
2024-01-04 00416, 2024
yvanzo
I agree, in certain places.
2024-01-04 00437, 2024
yvanzo
> Not using it shouldn’t cause any problem in most cases as the MBS code usually has a separate source string for 0 but there is no guarantee about it.
2024-01-04 00436, 2024
kellnerd
Hmm, but "0" would be plural in most languages, so changing the singular translation to drop the placeholder should not be a problem for these languages, right?
2024-01-04 00413, 2024
outsidecontext
in most translation systems it is ok to omit the placeholder, so translators might expect this to work.
2024-01-04 00435, 2024
yvanzo
_"0" would be plural in most languages_ -- which languages? Isn't it rather the opposite?
2024-01-04 00426, 2024
kellnerd
I mean that most languages use "Plural-Forms: nplurals=2; plural=(n != 1);"
2024-01-04 00401, 2024
kellnerd
My idea was that it would make sense to revert back to the long-standing singular translations which I had changed to include "{num}" recently (the example above is one of them) since they most likely did not cause any issues in the past.
2024-01-04 00401, 2024
kellnerd
I would rather file MBS tickets for places where this does not work as expected instead of shoehorning "1" into strings where it looks weird :)
2024-01-04 00456, 2024
yvanzo
I see, in German Singular n=1, so you can obviously omit it.
2024-01-04 00457, 2024
yvanzo
Same in Dutch and Spanish.
2024-01-04 00421, 2024
yvanzo
It seems that n=(0,1) in French, Portuguese and Turkish for example.
kellnerd: was it changed to 1 because of some specific issue? I'd also be in favor of changing this back unless it actually is causing technical problems
2024-01-04 00401, 2024
yvanzo
outsidecontext: those are examples, it isn’t an exhaustive list, but I can find more easily languages with n=1 indeed
2024-01-04 00443, 2024
yvanzo
There is no technical issue either with omitting the number placeholder.
2024-01-04 00431, 2024
akshaaatt
jasje could you please leave a review on pranav's PR asap?
2024-01-04 00419, 2024
pranavkonidena_ joined the channel
2024-01-04 00417, 2024
kellnerd
outsidecontext: I've changed them only because of the Weblate warning when I was reviewing translation checks. There were no issues as far as I know, only the one with the statistics page but that has a different cause.
2024-01-04 00405, 2024
outsidecontext
I see. I guess then they could be changed back and the warnung disabled for the german translation
there is a subtle difference of 1 mann and en mann, the word for 1 is literally "en" but "ett" also means 1,. fex we say "klokka ett" 1'o clock)
2024-01-04 00458, 2024
MonkeyPython
"see all 1 release groups" sems really wonky
2024-01-04 00411, 2024
MonkeyPython
but it's common for wesites to have this
2024-01-04 00428, 2024
MonkeyPython
do we even need a num here?
2024-01-04 00454, 2024
MonkeyPython
just "see all release-groups" seems fine?
2024-01-04 00404, 2024
MonkeyPython
maybe have num in paranthesis
2024-01-04 00419, 2024
MonkeyPython
"see all (num) release-group(s)" heh
2024-01-04 00422, 2024
kellnerd
Yeah, but there are two strings which could be different... They are differently translated into French for example, but English and German use the plural form for the singular string.
2024-01-04 00401, 2024
kellnerd
I just want to know whther that's worth fixing or if they are simply unused (and it does not matter)
2024-01-04 00423, 2024
kellnerd
Because if it is to be fixed, the English source string has to be changed as well.
