XSF Discussion - 2019-07-27


  1. Neustradamus has joined

  2. Neustradamus has left

  3. winfried has left

  4. Neustradamus has joined

  5. winfried has joined

  6. arc has left

  7. arc has joined

  8. Neustradamus has left

  9. remko has joined

  10. Neustradamus has joined

  11. arc has left

  12. arc has joined

  13. Neustradamus has left

  14. Neustradamus has joined

  15. remko has left

  16. pdurbin has joined

  17. Neustradamus has left

  18. Neustradamus has joined

  19. moparisthebest has left

  20. moparisthebest has joined

  21. UsL has left

  22. UsL has joined

  23. pdurbin has left

  24. stpeter has joined

  25. peter has joined

  26. peter has left

  27. Lance has left

  28. stpeter has left

  29. wurstsalat has left

  30. APach has left

  31. APach has joined

  32. lumi has left

  33. neshtaxmpp has left

  34. neshtaxmpp has joined

  35. adityaborikar has left

  36. adityaborikar has joined

  37. pdurbin has joined

  38. Neustradamus has left

  39. remko has joined

  40. adityaborikar has left

  41. remko has left

  42. adityaborikar has joined

  43. winfried has left

  44. winfried has joined

  45. winfried has left

  46. winfried has joined

  47. Yagiza has joined

  48. moparisthebest has left

  49. moparisthebest has joined

  50. patrick has left

  51. Douglas Terabyte has left

  52. remko has joined

  53. Douglas Terabyte has joined

  54. karoshi has joined

  55. wurstsalat has joined

  56. remko has left

  57. Yagiza

    It seems I fixed everything.

  58. Yagiza

    Now OMEMO works all right in my client!

  59. pdurbin has left

  60. pdurbin has joined

  61. lskdjf has joined

  62. lskdjf has left

  63. Mikaela has joined

  64. lskdjf has joined

  65. remko has joined

  66. arc has left

  67. arc has joined

  68. lovetox has left

  69. lskdjf has left

  70. lskdjf has joined

  71. larma has left

  72. lnj has joined

  73. larma has joined

  74. Yagiza has left

  75. Nekit has joined

  76. dragonspirit810 has joined

  77. debacle has joined

  78. jcbrand has joined

  79. andy has joined

  80. adityaborikar has left

  81. andrey.g has left

  82. dragonspirit810 has left

  83. andrey.g has joined

  84. adityaborikar has joined

  85. lovetox has joined

  86. lovetox has left

  87. adityaborikar has left

  88. adityaborikar has joined

  89. remko has left

  90. remko has joined

  91. neshtaxmpp has left

  92. neshtaxmpp has joined

  93. Dele (Mobile) has joined

  94. remko has left

  95. Dele (Mobile) has left

  96. Dele (Mobile) has joined

  97. Dele (Mobile) has left

  98. Dele (Mobile) has joined

  99. Dele (Mobile) has left

  100. dele2 has joined

  101. dele2 has left

  102. Dele (Mobile) has joined

  103. Dele (Mobile) has left

  104. debacle has left

  105. Dele (Mobile) has joined

  106. pdurbin has left

  107. lumi has joined

  108. lovetox has joined

  109. Dele (Mobile) has left

  110. Dele (Mobile) has joined

  111. Dele (Mobile) has left

  112. Dele (Mobile) has joined

  113. Dele (Mobile) has left

  114. marc_ has joined

  115. igoose has left

  116. igoose has joined

  117. dele2 has joined

  118. lnj has left

  119. lnj has joined

  120. lovetox has left

  121. lumi has left

  122. Yagiza has joined

  123. remko has joined

  124. remko has left

  125. remko has joined

  126. pdurbin has joined

  127. dele2 has left

  128. adityaborikar has left

  129. adityaborikar has joined

  130. lumi has joined

  131. pdurbin has left

  132. Douglas Terabyte has left

  133. Douglas Terabyte has joined

  134. vanitasvitae has left

  135. vanitasvitae has joined

  136. lumi has left

  137. lumi has joined

  138. lumi has left

  139. waqas has joined

  140. eevvoor has joined

  141. Link Mauve

    “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.

  142. Link Mauve

    If you want do extend your bookmarks, you’ll have to use another private PEP node.

  143. pdurbin has joined

  144. marc_ has left

  145. andy has left

  146. pdurbin has left

  147. jonas’

    unless bookmarks 2 or something specifies that stuff needs to be kept :)

  148. intosi has left

  149. intosi has joined

  150. Link Mauve

    jonas’, as far as current implementations are concerned, Bookmarks 2 doesn’t exist.

  151. pdurbin has joined

  152. pdurbin has left

  153. Ge0rG

    jonas’: keeping unknown elements in a structure that you have to parse is a nasty cross layer challenge.

  154. waqas has left

  155. Yagiza has left

  156. zach has left

  157. Seve has left

  158. Vaulor has left

  159. Seve has joined

  160. Vaulor has joined

  161. Douglas Terabyte has left

  162. lovetox has joined

  163. Yagiza has joined

  164. Yagiza has left

  165. pdurbin has joined

  166. lovetox

    yeah and i would rather not rely on other clients not overwritting my custom elements

  167. 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

  168. lovetox has left

  169. Mikaela has left

  170. Mikaela has joined

  171. Mikaela has left

  172. Mikaela has joined

  173. pdurbin has left

  174. Steve Kille has left

  175. andy has joined

  176. adityaborikar has left

  177. Nekit has left

  178. lovetox has joined

  179. lumi has joined

  180. COM8 has joined

  181. COM8 has left

  182. Mikaela has left

  183. Mikaela has joined

  184. COM8 has joined

  185. waqas has joined

  186. COM8 has left

  187. COM8 has joined

  188. COM8 has left

  189. COM8 has joined

  190. COM8 has left

  191. COM8 has joined

  192. COM8 has left

  193. Yagiza has joined

  194. COM8 has joined

  195. Yagiza has left

  196. Zash

    Where do I send patches for the website?

  197. Zash

    editor@xmpp.org or somesuch?

  198. COM8 has left

  199. Link Mauve

    Zash, that should be fine, or you could use GitHub and send a pull request.

  200. Link Mauve

    Editor will be the one merging it in the end.

  201. COM8 has joined

  202. Zash

    I don't feel like interacting with github today, and I strongly believe that it should not be required.

  203. Link Mauve

    Especially now that it’s impossible for people living in countries the USA considers as enemies.

  204. Zash

    Well the XSF is incorporated in the US so that point might be moot :/

  205. Link Mauve

    The XSF isn’t enforcing that ban on any of its infrastructures, AFAIK.

  206. Link Mauve

    GitHub is, since a few days ago.

  207. Zash

    Maybe this merely reminded me to exercise the non-github patch submission path :)

  208. Link Mauve

    :)

  209. COM8 has left

  210. Yagiza has joined

  211. COM8 has joined

  212. Yagiza has left

  213. COM8 has left

  214. COM8 has joined

  215. Neustradamus has joined

  216. COM8 has left

  217. zach has joined

  218. COM8 has joined

  219. APach has left

  220. APach has joined

  221. Nekit has joined

  222. COM8 has left

  223. murabito has left

  224. murabito has joined

  225. Neustradamus has left

  226. Neustradamus has joined

  227. COM8 has joined

  228. COM8 has left

  229. COM8 has joined

  230. COM8 has left

  231. COM8 has joined

  232. COM8 has left

  233. winfried has left

  234. Neustradamus has left

  235. COM8 has joined

  236. COM8 has left

  237. Ge0rG

    Zash: how do you obtain a copy of the repository without interacting with github?

  238. COM8 has joined

  239. COM8 has left

  240. COM8 has joined

  241. COM8 has left

  242. Neustradamus has joined

  243. lnj has left

  244. Zash

    Ge0rG: Magic already existing local clone.

  245. 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

  246. Zash

    What's the relation of that and XEP-0277 (or is it 227? I always mix those up)

  247. COM8 has joined

  248. Neustradamus has left

  249. COM8 has left

  250. COM8 has joined

  251. COM8 has left

  252. COM8 has joined

  253. COM8 has left

  254. COM8 has joined

  255. COM8 has left

  256. eevvoor

    hope we can use salut a toi one day to send patches via xmpp :)

  257. Ge0rG

    Store your code in PubSub, not in GitHub!

  258. 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. :(

  259. Ge0rG

    XMPP shouldn't be using HTTP for sending files.

  260. COM8 has joined

  261. Link Mauve

    Agree.

  262. COM8 has left

  263. Link Mauve

    Agreed.

  264. COM8 has joined

  265. COM8 has left

  266. COM8 has joined

  267. COM8 has left

  268. COM8 has joined

  269. COM8 has left

  270. COM8 has joined

  271. COM8 has left

  272. COM8 has joined

  273. lovetox

    hm if set stream lang to german

  274. COM8 has left

  275. lovetox

    i should not have to add this to presences if i join a muc or?

  276. COM8 has joined

  277. COM8 has left

  278. Zash

    In theory

  279. Zash

    Which server?

  280. lovetox

    prosody

  281. lovetox

    Zash what does this mean if i set xml:lang=de, and prosody answers me with xml:lang=en

  282. lovetox

    is the lang set on each direction of the stream separate?

  283. Zash

    I don't know. Prosody doesn't do anything with xml:lang

  284. Link Mauve

    lovetox, yes, each direction is separate.

  285. lovetox

    it does, because it sets it to en :D

  286. lovetox

    Zash i hope it adds whatever xml:lang i set to whatever stanza it routes to other servers

  287. Zash

    Nope

  288. Zash

    It does *nothing* with xml:lang

  289. lovetox

    ...

  290. 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.

  291. Zash

    Except if it's set on a presence stanza that creates a MUC it uses that as default language in the MUC config

  292. lovetox

    Is there a particular reason prosody ignores stream xml:lang attr?

  293. Link Mauve

    Ah no, it’s not a SHOULD it’s a MAY.

  294. 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.”

  295. COM8 has joined

  296. Link Mauve

    lovetox, it’s allowed in 6120.

  297. COM8 has left

  298. Link Mauve

    Section 4.7.4.

  299. COM8 has joined

  300. COM8 has left

  301. COM8 has joined

  302. COM8 has left

  303. lovetox

    no its a SHOULD for the server

  304. Link Mauve

    Ah right, I misread.

  305. COM8 has joined

  306. Zash

    Link Mauve, Wait inheritance is not mandated by XML itself?

  307. winfried has joined

  308. COM8 has left

  309. Link Mauve

    Zash, stanzas are sent to other entities than your server, so that wouldn’t be enough.

  310. lovetox

    Zash, im aware that prosody does not provide translations

  311. COM8 has joined

  312. lovetox

    but other servers do, and it would be nice if prosody adds whatever stream xml:lang i set, to outgoing stanzs

  313. Neustradamus has joined

  314. COM8 has left

  315. COM8 has joined

  316. COM8 has left

  317. COM8 has joined

  318. COM8 has left

  319. Zash

    Nobody has written code that does that

  320. COM8 has joined

  321. Ge0rG

    I'm surprised that this is not a MUST in the standard.

  322. Link Mauve

    Same.

  323. Ge0rG

    I've just added xml:lang to yaxim yesterday.

  324. flow

    What would make a MUST better here?

  325. Link Mauve

    flow, clients wouldn’t have to copy it manually on each stanza.

  326. flow

    I assume we are talking about the first SHOULD in the quote link posted

  327. Link Mauve

    I wasn’t aware of this particular issue.

  328. 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"

  329. 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

  330. 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.

  331. COM8 has left

  332. Ge0rG

    This is §8.1.5

  333. Link Mauve

    flow, I actually read MUSTs that way, as long as both entities agree they can do otherwise.

  334. Ge0rG

    Inheritance of xml:lang is a huge can of worms.

  335. flow

    I know that endless discussion have already take place about that topic at various venues :)

  336. flow

    Link Mauve, so what makes a SHOULD different from a MAY and from a MUST in your book?

  337. Ge0rG

    I'm sure there were.

  338. Ge0rG

    flow: prosody developers will implement MUST on request.

  339. Link Mauve

    Ge0rG, SHOULD too.

  340. Ge0rG

    Link Mauve: not in my experience.

  341. 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.

  342. Link Mauve

    And MAY, do whatever you want.

  343. flow

    ack on MAY

  344. flow

    but I guess if we ask enough people we sure get two contradictory statements on that too ;)

  345. Link Mauve

    Yeah. ^^'

  346. flow

    It feels like your SHOULD interpretation is not so far away from mine

  347. flow

    so in my book, MUST is something that you can not just not follow, as otherwise some very important aspect will fall apart

  348. flow

    like "MUST be initialized with a CSPRNG"

  349. lovetox

    Ge0rG, can you give an example why this is a can of worms?

  350. 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

  351. 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.

  352. flow

    lovetox, some XML parsers, IIRC the one on Android, will not inhert xml:lang to deeper XML levels

  353. Link Mauve

    Incidentally, I just opened https://gitlab.com/xmpp-rs/minidom-rs/issues/17

  354. Ge0rG

    lovetox: that, and your prosody issue.

  355. flow

    that means you may have to work around that if you want get the effective xml:lang

  356. flow

    note that this is usually also true for namespace prefix bindings

  357. Ge0rG

    Also displaying of the right human readable text from a message with a set of different language texts

  358. lovetox

    i have the feeling you talk about some use cases that never happen

  359. lovetox

    also i dont see why i would need my parser to do some inherit stuff with xml lang

  360. Ge0rG

    They never happen because nobody is making use of xml:lang because they never happen.

  361. lovetox

    this is about telling my server my preferred lang, i dont parse it anywhere, i only send it

  362. flow

    lovetox, well let's say there is a server which optimizes xml:lang by stripped redundant ones

  363. flow

    I think there are some more cases, but yes it obviously hasn't hurt xmpp that much in the past 20 years

  364. 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

  365. flow

    on the other hand, smack just got support for an xml environment which keeps track of xml:lang

  366. 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 ;)

  367. lovetox

    no you really dont Ge0rG, at least not for the basic use case of getting translated messages from your server

  368. lovetox

    what you are talking about is user to user stuff

  369. lovetox

    yeah i wouldnt even start with xml lang there

  370. Ge0rG

    lovetox: I'm talking about the code needed to display the correct string to the user

  371. Ge0rG

    lovetox: let's say it's not message body but the text field from a message error

  372. Ge0rG

    Same situation

  373. 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?

  374. lovetox

    whats the problem? you dont work with inheritence there

  375. lovetox

    you just set the xml:lang on the <text>

  376. lovetox

    the server sets it in this case

  377. lovetox

    if its not there, its the lang the server told you in stream init

  378. Ge0rG

    flow: I'm talking about the smack report where no text at all is returned when the languages don't match

  379. flow

    Ge0rG, i guess that is very indirect yes to my question

  380. Ge0rG

    lovetox: you just described Inheritance

  381. Ge0rG

    flow: maybe not 20, but 2, or even just one, but in the wrong language

  382. lovetox

    why would a server return 2?

  383. lovetox

    this is already some theoretical stuff

  384. flow

    lovetox, because the stanza may not originated from the server

  385. flow

    it maybe came from a remote entity which has no knowledge about your stream's xml:lang

  386. 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.

  387. lovetox

    yeah still dont see the problem, one has xml:lang=en the other one "de"

  388. Link Mauve

    If I were to implement localised error messages in a server, I’d do it that way.

  389. flow

    Link Mauve, +1

  390. lovetox

    <error> can have "fi"

  391. lovetox

    it does not matter

  392. Link Mauve

    lovetox, the other one may not have it on the <text/> element, but on the stanza.

  393. lovetox

    because the directly set xml:lang on the text will always overrule parent or not?

  394. Link Mauve

    It still MUST be understood as German.

  395. Link Mauve

    lovetox, yes it will.

  396. 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.

  397. 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'

  398. flow

    or, even better, your parser sould provide you mechanism to determine the effective xml:lang of the element

  399. Link Mauve

    And not "" either.

  400. Link Mauve

    And not '' either.

  401. Link Mauve

    And not '' either (which means no language set, as per XML 1.0).

  402. flow

    Link Mauve, yep, today I sadly learned that the empty string is valid for xml:lang

  403. Link Mauve

    TIL too!

  404. flow

    another fun fact: xml 1.0 mentions BCP 47 for xml:lang, xml 1.1 mentions rfc 3066

  405. flow

    now go out and find out the fun :)

  406. lovetox

    does the rfc not define one them self

  407. lovetox

    rfc says BCP 47

  408. flow

    ahh you spoiled the fun for the others, yes rfc 3066 is bcp 47

  409. Link Mauve

    :p

  410. Ge0rG

    it's not as bad as stringprep vs precis, eh?

  411. 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)

  412. Link Mauve

    flow, isn’t BCP47 a live standard, as in it will point to whichever RFC is currently considered the one?

  413. lovetox

    either way, servers in general should get translation going, i see it working in ejabberd, its a nice thing

  414. flow

    Link Mauve, are they? but yes, that could be a reason

  415. Ge0rG

    lovetox: there should also be a translations project for the common error conditions.

  416. flow

    translate your favorite error message!

  417. Ge0rG

    This is especially important for stream errors, where the text element is an extension for the technical details, not the actual explanation

  418. wurstsalat

    > lovetox: there should also be a translations project for the common error conditions. +1

  419. lovetox

    yes also common forms

  420. Ge0rG

    Those too

  421. Link Mauve

    Yes please, Someone™ do that.

  422. Ge0rG

    The JSF should do it.

  423. Ge0rG

    Do we have a complete list of all places where the same translations are needed for all implementations?

  424. Ge0rG

    Forms, error conditions,...?

  425. Link Mauve

    Ge0rG, take a translated server’s .pot file?

  426. lovetox

    forms and error conditions, i didnt come across any other places where a server adds userfacing text

  427. Link Mauve

    lovetox, user configuration maybe?

  428. Ge0rG

    Link Mauve: there is no 1:1 mapping between conditions and server side error messages

  429. lovetox

    whats user configuration?

  430. Link Mauve

    lovetox, some servers may expose e.g. a web interface to their admins.

  431. Link Mauve

    Ge0rG, I know.

  432. Zash

    Create a repo, stick some .po files or whatever in it, pre-seed it with text from the RFC?

  433. Ge0rG

    Zash: on github!

  434. lovetox

    :D

  435. Mikaela has left

  436. lovetox

    i think one would need some translation website, like pootle or something

  437. Zash

    Not strictly, but such a thing can be used

  438. Ge0rG

    Transiflex?

  439. Ge0rG

    Launchpad?

  440. eevvoor has left

  441. lovetox

    transifex is pretty expensive

  442. Zash

    Are you supposed to do xml:lang inheritance yourself or can libexpat do it?

  443. Ge0rG

    Zash: yes.

  444. Zash

    .

  445. lovetox

    Why would you care as server?

  446. lovetox

    just set the attr on the top element

  447. lovetox

    and be done

  448. Zash

    lovetox: The question is "Can the XML parser library do the thing you just asked us to do?"

  449. lovetox

    setting an attribute on a stanza?

  450. Zash

    Inheriting xml:lang from the stream to child elements

  451. lovetox

    im pretty sure it can do it

  452. Zash

    I'm not sure you grasp just how deep this can of worms is

  453. Zash

    If something copies one of the child tags of the stanza, they should probably also carry the xml:lang

  454. Zash

    Ie it should work similar to xmlns, which the xml parser supposedly handles for us

  455. lovetox

    I think you overthink that

  456. 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

  457. lovetox

    of course only if its not already there

  458. lovetox

    and this can never be wrong, as we set it on the stream already, so it is inherited in message, iq, presence anyway

  459. lovetox

    you just make it explicit

  460. lovetox

    you dont change anything here

  461. lovetox

    and thats only because these stanzas will reach entitys which dont have the c2s stream context

  462. lovetox

    and nobody asks you should make it explicit all the way down to the last child

  463. lovetox

    only the childs of stream

  464. 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.

  465. Link Mauve

    The original body didn’t contain any @xml:lang, but the copy should contain it as xml:lang="fr".

  466. lovetox

    storing and restoring messages and all of its content correctly is a general issue that does not stop at that attr

  467. Link Mauve

    xmlns, xml:lang, something else?

  468. lovetox

    yes if the server does not preserve attr on the message

  469. lovetox

    there needs to be changes to make this right

  470. Link Mauve

    lovetox, it’s not only on the message, it should be “propagated” to all children of the stanza in that case.

  471. 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

  472. Tobias has left

  473. lovetox

    No Link Mauve server should replicate the message exactly

  474. lovetox

    if i send a message with lang=de, i expect it to be routed that way

  475. lovetox

    and not with lang=de on all childs set

  476. lovetox

    i mean yes it would be still correct

  477. Zash

    lang=de is implied

  478. lovetox

    but weird to rewrite a stanza that way

  479. lovetox

    and you do it with jabber:client already?

  480. lovetox

    why dont you copy it into every body?

  481. Zash

    magic

  482. Zash

    It's implied

  483. Link Mauve

    lovetox, it’s not about rewriting, it’s about representing in memory or serialised.

  484. Link Mauve

    And having an easy way to access it.

  485. lovetox

    yeah Link Mauve but thats totally different problem, sorry i cant believe that xml:lang attr suddently is the big challenge of serializing

  486. lovetox

    i see that a server dev, maybe has to change or adapt his serialization process

  487. 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.

  488. lovetox

    and in that way, my pervious statement "just add the attr" is wrong

  489. lovetox

    but i dont think this is a problem hard to solve

  490. Zash

    Actually you have to change jabber:client to jabber:server when sending it over s2s, so that's already messy

  491. waqas has left

  492. 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

  493. lovetox

    are you telling me this does not work currently?

  494. Link Mauve

    lovetox, it does, but I’m talking about internal server processing (or any entity really).

  495. lovetox

    but im not proposing to change anything here

  496. 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.

  497. Zash

    MUC subjects maybe?

  498. lovetox

    what im asking is, that the server sets the attr, not the client, so this change can not lead to problems

  499. Link Mauve

    Zash, yes, that’s a good example.

  500. Zash

    Tho Prosody only saves the text there

  501. Link Mauve

    It should also support setting multiple subjects, each in a different language. :)

  502. Zash

    My head hurts

  503. Steve Kille has joined

  504. Link Mauve

    In xmpp-parsers I made each text element a hash map of language to value.

  505. andy has left

  506. lovetox has left

  507. wurstsalat has left

  508. Ge0rG

    Is xml:lang preserved by MAM?

  509. Link Mauve

    Should be.

  510. Ge0rG

    Link Mauve: and then you implemented a getOptimalLanguageValue() based on a doubly weighted list from the Accept-Language header?

  511. Ge0rG walks himself out

  512. 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.

  513. Link Mauve

    Without any normalisation (so for instance it won’t pick fr-FR if the user prefers fr).

  514. karoshi has left

  515. karoshi has joined

  516. andy has joined

  517. Nekit has left

  518. UsL has left

  519. UsL has joined

  520. Douglas Terabyte has joined

  521. lskdjf has left