“20:49:04 Zash> Actually, you can probably add tags in a custom namespace if you want”, clients will parse the namespaces into their internal structures, then serialise them back without including your extensions, sorry.
Link Mauve
If you want do extend your bookmarks, you’ll have to use another private PEP node.
pdurbinhas joined
marc_has left
andyhas left
pdurbinhas left
jonas’
unless bookmarks 2 or something specifies that stuff needs to be kept :)
intosihas left
intosihas joined
Link Mauve
jonas’, as far as current implementations are concerned, Bookmarks 2 doesn’t exist.
pdurbinhas joined
pdurbinhas left
Ge0rG
jonas’: keeping unknown elements in a structure that you have to parse is a nasty cross layer challenge.
waqashas left
Yagizahas left
zachhas left
Sevehas left
Vaulorhas left
Sevehas joined
Vaulorhas joined
Douglas Terabytehas left
lovetoxhas joined
Yagizahas joined
Yagizahas left
pdurbinhas joined
lovetox
yeah and i would rather not rely on other clients not overwritting my custom elements
lovetox
Using a private pep node for that, you dont need to change a xep, you dont need to rely on other clients, you can implement it right now, and it will just work
lovetoxhas left
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
pdurbinhas left
Steve Killehas left
andyhas joined
adityaborikarhas left
Nekithas left
lovetoxhas joined
lumihas joined
COM8has joined
COM8has left
Mikaelahas left
Mikaelahas joined
COM8has joined
waqashas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
Yagizahas joined
COM8has joined
Yagizahas left
Zash
Where do I send patches for the website?
Zash
editor@xmpp.org or somesuch?
COM8has left
Link Mauve
Zash, that should be fine, or you could use GitHub and send a pull request.
Link Mauve
Editor will be the one merging it in the end.
COM8has joined
Zash
I don't feel like interacting with github today, and I strongly believe that it should not be required.
Link Mauve
Especially now that it’s impossible for people living in countries the USA considers as enemies.
Zash
Well the XSF is incorporated in the US so that point might be moot :/
Link Mauve
The XSF isn’t enforcing that ban on any of its infrastructures, AFAIK.
Link Mauve
GitHub is, since a few days ago.
Zash
Maybe this merely reminded me to exercise the non-github patch submission path :)
Link Mauve
:)
COM8has left
Yagizahas joined
COM8has joined
Yagizahas left
COM8has left
COM8has joined
Neustradamushas joined
COM8has left
zachhas joined
COM8has joined
APachhas left
APachhas joined
Nekithas joined
COM8has left
murabitohas left
murabitohas joined
Neustradamushas left
Neustradamushas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
winfriedhas left
Neustradamushas left
COM8has joined
COM8has left
Ge0rG
Zash: how do you obtain a copy of the repository without interacting with github?
COM8has joined
COM8has left
COM8has joined
COM8has left
Neustradamushas joined
lnjhas left
Zash
Ge0rG: Magic already existing local clone.
Zash
https://xmpp.org/about/technology-overview.html#pubsub has a broken link to what I assume was a local render of https://tools.ietf.org/html/draft-saintandre-atompub-notify-07
Zash
What's the relation of that and XEP-0277 (or is it 227? I always mix those up)
COM8has joined
Neustradamushas left
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
eevvoor
hope we can use salut a toi one day to send patches via xmpp :)
Ge0rG
Store your code in PubSub, not in GitHub!
Link Mauve
I just got into an argument with someone arguing that XMPP shouldn’t be able to send/store files, even though that was just HTTP. :(
i should not have to add this to presences if i join a muc or?
COM8has joined
COM8has left
Zash
In theory
Zash
Which server?
lovetox
prosody
lovetox
Zash what does this mean if i set xml:lang=de, and prosody answers me with xml:lang=en
lovetox
is the lang set on each direction of the stream separate?
Zash
I don't know. Prosody doesn't do anything with xml:lang
Link Mauve
lovetox, yes, each direction is separate.
lovetox
it does, because it sets it to en :D
lovetox
Zash i hope it adds whatever xml:lang i set to whatever stanza it routes to other servers
Zash
Nope
Zash
It does *nothing* with xml:lang
lovetox
...
Link Mauve
But yes, the server SHOULD (IIRC) add the stream’s @xml:lang on each outgoing stanza if you haven’t set one already.
Zash
Except if it's set on a presence stanza that creates a MUC it uses that as default language in the MUC config
lovetox
Is there a particular reason prosody ignores stream xml:lang attr?
Link Mauve
Ah no, it’s not a SHOULD it’s a MAY.
Link Mauve
“If the initiating entity included the 'xml:lang' attribute in its initial stream header, the receiving entity SHOULD remember that value as the default xml:lang for all stanzas sent by the initiating entity over the current stream. As described under Section 8.1.5, the initiating entity MAY include the 'xml:lang' attribute in any XML stanzas it sends over the stream.”
COM8has joined
Link Mauve
lovetox, it’s allowed in 6120.
COM8has left
Link Mauve
Section 4.7.4.
COM8has joined
COM8has left
COM8has joined
COM8has left
lovetox
no its a SHOULD for the server
Link Mauve
Ah right, I misread.
COM8has joined
Zash
Link Mauve, Wait inheritance is not mandated by XML itself?
winfriedhas joined
COM8has left
Link Mauve
Zash, stanzas are sent to other entities than your server, so that wouldn’t be enough.
lovetox
Zash, im aware that prosody does not provide translations
COM8has joined
lovetox
but other servers do, and it would be nice if prosody adds whatever stream xml:lang i set, to outgoing stanzs
Neustradamushas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
Zash
Nobody has written code that does that
COM8has joined
Ge0rG
I'm surprised that this is not a MUST in the standard.
Link Mauve
Same.
Ge0rG
I've just added xml:lang to yaxim yesterday.
flow
What would make a MUST better here?
Link Mauve
flow, clients wouldn’t have to copy it manually on each stanza.
flow
I assume we are talking about the first SHOULD in the quote link posted
Link Mauve
I wasn’t aware of this particular issue.
flow
Link Mauve, well a SHOULD is already pretty strong. I usually read it as "you have to do it, unless all invovled parties aggreed on something else"
flow
That way, you could write a simpler service implementation, use it in a, more or less closed, envrionment, where that requirement is not needed by every involved party and still claim standard compliance
Ge0rG
> If an outbound stanza generated by a client does not possess an 'xml:lang' attribute, the client's server SHOULD add an 'xml:lang' attribute whose value is that specified for the client's output stream as defined under Section 4.7.4.
COM8has left
Ge0rG
This is §8.1.5
Link Mauve
flow, I actually read MUSTs that way, as long as both entities agree they can do otherwise.
Ge0rG
Inheritance of xml:lang is a huge can of worms.
flow
I know that endless discussion have already take place about that topic at various venues :)
flow
Link Mauve, so what makes a SHOULD different from a MAY and from a MUST in your book?
Ge0rG
I'm sure there were.
Ge0rG
flow: prosody developers will implement MUST on request.
Link Mauve
Ge0rG, SHOULD too.
Ge0rG
Link Mauve: not in my experience.
Link Mauve
flow, hmm, SHOULD is more like, it’s possible to not implement it that way if you can’t, for a good enough reason.
Link Mauve
And MAY, do whatever you want.
flow
ack on MAY
flow
but I guess if we ask enough people we sure get two contradictory statements on that too ;)
Link Mauve
Yeah. ^^'
flow
It feels like your SHOULD interpretation is not so far away from mine
flow
so in my book, MUST is something that you can not just not follow, as otherwise some very important aspect will fall apart
flow
like "MUST be initialized with a CSPRNG"
lovetox
Ge0rG, can you give an example why this is a can of worms?
flow
of course you are free to ignore that in your implementation, but then you can't claim standard compliance and you have to live with the consequences
Link Mauve
Earlier today I was reading the XML specification, and found not respected MUSTs in minidom which are totally fine not to respect in our XMPP environment.
flow
lovetox, some XML parsers, IIRC the one on Android, will not inhert xml:lang to deeper XML levels
Link Mauve
Incidentally, I just opened https://gitlab.com/xmpp-rs/minidom-rs/issues/17
Ge0rG
lovetox: that, and your prosody issue.
flow
that means you may have to work around that if you want get the effective xml:lang
flow
note that this is usually also true for namespace prefix bindings
Ge0rG
Also displaying of the right human readable text from a message with a set of different language texts
lovetox
i have the feeling you talk about some use cases that never happen
lovetox
also i dont see why i would need my parser to do some inherit stuff with xml lang
Ge0rG
They never happen because nobody is making use of xml:lang because they never happen.
lovetox
this is about telling my server my preferred lang, i dont parse it anywhere, i only send it
flow
lovetox, well let's say there is a server which optimizes xml:lang by stripped redundant ones
flow
I think there are some more cases, but yes it obviously hasn't hurt xmpp that much in the past 20 years
Ge0rG
lovetox: the body inherits the lang from the message, which inherits it from the stream. If your xml library doesn't do that Inheritance, you need to manually traverse the hierarchy
flow
on the other hand, smack just got support for an xml environment which keeps track of xml:lang
flow
which is hopefully caused by xmpp becoming more and more used so that those rare cases where xml:lang inheritance becomes important also become important ;)
lovetox
no you really dont Ge0rG, at least not for the basic use case of getting translated messages from your server
lovetox
what you are talking about is user to user stuff
lovetox
yeah i wouldnt even start with xml lang there
Ge0rG
lovetox: I'm talking about the code needed to display the correct string to the user
Ge0rG
lovetox: let's say it's not message body but the text field from a message error
Ge0rG
Same situation
flow
Ge0rG, aren't you talking about the "here is the same error message in 20 different language strings, please select the best one" case?
lovetox
whats the problem? you dont work with inheritence there
lovetox
you just set the xml:lang on the <text>
lovetox
the server sets it in this case
lovetox
if its not there, its the lang the server told you in stream init
Ge0rG
flow: I'm talking about the smack report where no text at all is returned when the languages don't match
flow
Ge0rG, i guess that is very indirect yes to my question
Ge0rG
lovetox: you just described Inheritance
Ge0rG
flow: maybe not 20, but 2, or even just one, but in the wrong language
lovetox
why would a server return 2?
lovetox
this is already some theoretical stuff
flow
lovetox, because the stanza may not originated from the server
flow
it maybe came from a remote entity which has no knowledge about your stream's xml:lang
Link Mauve
lovetox, for instance, so you can have a nice localised message for user display, and the English version so they can report to the admin and easily look it up in the code.
lovetox
yeah still dont see the problem, one has xml:lang=en the other one "de"
Link Mauve
If I were to implement localised error messages in a server, I’d do it that way.
flow
Link Mauve, +1
lovetox
<error> can have "fi"
lovetox
it does not matter
Link Mauve
lovetox, the other one may not have it on the <text/> element, but on the stanza.
lovetox
because the directly set xml:lang on the text will always overrule parent or not?
Link Mauve
It still MUST be understood as German.
Link Mauve
lovetox, yes it will.
Link Mauve
But the @xml:lang might be present on any parent of the <text/> element, and you must inherit it in any child which doesn’t have one defined.
flow
so basically if you have: stream xml:lang=en, stanza xml:lang=de, error xml:lang not set, your parser should see the error's xml:lang as 'de' and not 'en'
flow
or, even better, your parser sould provide you mechanism to determine the effective xml:lang of the element
And not '' either (which means no language set, as per XML 1.0). ✏
flow
Link Mauve, yep, today I sadly learned that the empty string is valid for xml:lang
Link Mauve
TIL too!
flow
another fun fact: xml 1.0 mentions BCP 47 for xml:lang, xml 1.1 mentions rfc 3066
flow
now go out and find out the fun :)
lovetox
does the rfc not define one them self
lovetox
rfc says BCP 47
flow
ahh you spoiled the fun for the others, yes rfc 3066 is bcp 47
Link Mauve
:p
Ge0rG
it's not as bad as stringprep vs precis, eh?
flow
I just find it strange that this changed between xml 1.0 and 1.1, and i am curious to get the rationale behind that (if there is any)
Link Mauve
flow, isn’t BCP47 a live standard, as in it will point to whichever RFC is currently considered the one?
lovetox
either way, servers in general should get translation going, i see it working in ejabberd, its a nice thing
flow
Link Mauve, are they? but yes, that could be a reason
Ge0rG
lovetox: there should also be a translations project for the common error conditions.
flow
translate your favorite error message!
Ge0rG
This is especially important for stream errors, where the text element is an extension for the technical details, not the actual explanation
wurstsalat
> lovetox: there should also be a translations project for the common error conditions.
+1
lovetox
yes also common forms
Ge0rG
Those too
Link Mauve
Yes please, Someone™ do that.
Ge0rG
The JSF should do it.
Ge0rG
Do we have a complete list of all places where the same translations are needed for all implementations?
Ge0rG
Forms, error conditions,...?
Link Mauve
Ge0rG, take a translated server’s .pot file?
lovetox
forms and error conditions, i didnt come across any other places where a server adds userfacing text
Link Mauve
lovetox, user configuration maybe?
Ge0rG
Link Mauve: there is no 1:1 mapping between conditions and server side error messages
lovetox
whats user configuration?
Link Mauve
lovetox, some servers may expose e.g. a web interface to their admins.
Link Mauve
Ge0rG, I know.
Zash
Create a repo, stick some .po files or whatever in it, pre-seed it with text from the RFC?
Ge0rG
Zash: on github!
lovetox
:D
Mikaelahas left
lovetox
i think one would need some translation website, like pootle or something
Zash
Not strictly, but such a thing can be used
Ge0rG
Transiflex?
Ge0rG
Launchpad?
eevvoorhas left
lovetox
transifex is pretty expensive
Zash
Are you supposed to do xml:lang inheritance yourself or can libexpat do it?
Ge0rG
Zash: yes.
Zash
.
lovetox
Why would you care as server?
lovetox
just set the attr on the top element
lovetox
and be done
Zash
lovetox: The question is "Can the XML parser library do the thing you just asked us to do?"
lovetox
setting an attribute on a stanza?
Zash
Inheriting xml:lang from the stream to child elements
lovetox
im pretty sure it can do it
Zash
I'm not sure you grasp just how deep this can of worms is
Zash
If something copies one of the child tags of the stanza, they should probably also carry the xml:lang
Zash
Ie it should work similar to xmlns, which the xml parser supposedly handles for us
lovetox
I think you overthink that
lovetox
all you have to do is, add the attr to the message, iq, presence, and leave the rest to client parsers who get the stanza
lovetox
of course only if its not already there
lovetox
and this can never be wrong, as we set it on the stream already, so it is inherited in message, iq, presence anyway
lovetox
you just make it explicit
lovetox
you dont change anything here
lovetox
and thats only because these stanzas will reach entitys which dont have the c2s stream context
lovetox
and nobody asks you should make it explicit all the way down to the last child
lovetox
only the childs of stream
Link Mauve
lovetox, think about some user sending the server an xml:lang="fr" message, the server then copies only the body into some other message, maybe to send it to the admin, or to archive, or anything.
Link Mauve
The original body didn’t contain any @xml:lang, but the copy should contain it as xml:lang="fr".
lovetox
storing and restoring messages and all of its content correctly is a general issue that does not stop at that attr
Link Mauve
xmlns, xml:lang, something else?
lovetox
yes if the server does not preserve attr on the message
lovetox
there needs to be changes to make this right
Link Mauve
lovetox, it’s not only on the message, it should be “propagated” to all children of the stanza in that case.
lovetox
but i would never go the way and add the attr on all childs only because i dont want to store it on the message
Tobiashas left
lovetox
No Link Mauve server should replicate the message exactly
lovetox
if i send a message with lang=de, i expect it to be routed that way
lovetox
and not with lang=de on all childs set
lovetox
i mean yes it would be still correct
Zash
lang=de is implied
lovetox
but weird to rewrite a stanza that way
lovetox
and you do it with jabber:client already?
lovetox
why dont you copy it into every body?
Zash
magic
Zash
It's implied
Link Mauve
lovetox, it’s not about rewriting, it’s about representing in memory or serialised.
Link Mauve
And having an easy way to access it.
lovetox
yeah Link Mauve but thats totally different problem, sorry i cant believe that xml:lang attr suddently is the big challenge of serializing
lovetox
i see that a server dev, maybe has to change or adapt his serialization process
Link Mauve
lovetox, as for “replicating”, in my example the server would only want to copy the body, not the rest of the message. No matter the way it decides to represent it, it must introduce a xml:lang="fr" on the body once copied alone in another stanza.
lovetox
and in that way, my pervious statement "just add the attr" is wrong
lovetox
but i dont think this is a problem hard to solve
Zash
Actually you have to change jabber:client to jabber:server when sending it over s2s, so that's already messy
waqashas left
lovetox
also this is all beside the point, users can already add xml:lang to messages, and we expect it to be routed to the destination
lovetox
are you telling me this does not work currently?
Link Mauve
lovetox, it does, but I’m talking about internal server processing (or any entity really).
lovetox
but im not proposing to change anything here
Link Mauve
If the entity wants to extract one element out of a stanza, the parent’s (parent’s (parent’s …)) @xml:lang should apply.
Zash
MUC subjects maybe?
lovetox
what im asking is, that the server sets the attr, not the client, so this change can not lead to problems
Link Mauve
Zash, yes, that’s a good example.
Zash
Tho Prosody only saves the text there
Link Mauve
It should also support setting multiple subjects, each in a different language. :)
Zash
My head hurts
Steve Killehas joined
Link Mauve
In xmpp-parsers I made each text element a hash map of language to value.
andyhas left
lovetoxhas left
wurstsalathas left
Ge0rG
Is xml:lang preserved by MAM?
Link Mauve
Should be.
Ge0rG
Link Mauve: and then you implemented a getOptimalLanguageValue() based on a doubly weighted list from the Accept-Language header?
Ge0rGwalks himself out
Link Mauve
Ge0rG, only based on a single vector, from preferred to least preferred, defaulting to no lang, or if there is none to the first one.
Link Mauve
Without any normalisation (so for instance it won’t pick fr-FR if the user prefers fr).