XSF logo 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