XSF Discussion - 2018-12-22

  1. ta

    > it would be better to use google translate api As someone struggling with a supposedly spanish guy, asking weird questions in a german "Linux Q&A"-MUC in horrible tanslated english i fear any automation in this direction.

  2. flow

    I'd also challenge the statement that data forms do not allow for i18n

  3. lovetox

    yeah flow, the whole xep mentions lang not once except as examples in toplevel stanzas (iq, message etc)

  4. flow

    but that does not imply that data forms have an i18n issue. Ad-hoc commands are a good example

  5. lovetox

    of course it implies that, if implementors have to do their own interpretation how i18n *could* maybe work, then its a very real issue for a standard

  6. Zash

    flow: Label in an attribute isn't problematic?

  7. lovetox

    and i dont get your reference to ad-hoc commands, in the xep there is a own section that just deals with localization

  8. flow

    Zash, I'm sorry, but I don't understand, could you rephrase your question?

  9. Zash

    https://xmpp.org/extensions/xep-0004.html#protocol Description goes into the `label` attribute, so it can't work like <body> with multiple xml:lang.

  10. flow

    lovetox, that is why I believe that data forms are well designed without i18n/xml:lang: You deal with the localization on the data-form using XEP

  11. lovetox

    you could duplicate the whole form ^^

  12. lovetox

    so you are saying we should not use dataforms if they are not part of another xep?

  13. lovetox

    i guess thats one way to solve it

  14. flow

    Zash, right a <{jabber:x:data}x/> element can only have exactly one xml:lang

  15. flow

    lovetox, I guess it possibly could come down to a philosopical question, but do we ever use data forms without another XEP?

  16. Zash

    flow: Mhm. If you only ever send that after knowing the preferred target language then it's fine I guess.

  17. lovetox

    hm i recently wrote a plugin that just does that, simple usecase, bot sends out a form, user fills it out and submits, bot acts on it

  18. flow

    Zash, aggreed, the question is how to handle situations where you don't know the xml:lang of the recipient *and* perform delayed communication (i.e., you can't probe xml:lang of the recipient)

  19. lovetox

    just out of interest how do i prope the xml lang of a contact?

  20. Zash

    Send `<message><body xml:lang="en">Hello</body><body xml:lang="fr">Bonjour</body><body xml:lang="sv">Hej</body> etc.. </message>` and wait for a reply? :)

  21. lovetox

    wow .. :D

  22. lovetox

    hence my idea to put it into the disco info

  23. flow

    then you still have the xml:lang of the stanza, or, if you don't know the recipients lang, you would probably define a wrapping extension element that maps a data form for every lang (not ideal but still)

  24. flow

    lovetox, I would imagine that xml:lang is a property of the account, and not the device

  25. flow

    so put it into PEP :)

  26. pep.

    Zash, what if the other side replies `<message><body xml:lang="en">Hello</body><body xml:lang="fr">Bonjour</body><body xml:lang="sv">Hej</body> etc.. </message>`

  27. flow

    but then again, it appears i18n in IM systems is basically non-existend and people are fine with it

  28. flow

    cause you usually know the language you are going to use with your contact

  29. lovetox

    yes i agree, it feels a bit verengineered ✎

  30. lovetox

    yes i agree, it feels a bit overengineered ✏

  31. flow

    and most bots are happy with just using english, or esperanto

  32. Zash

    flow: Bots and XMPP UIs like MUC room config and such tho?

  33. flow

    lovetox, I feel like the term overengineered is overused, I'd rather say that it is not a top prority, having facilities for i18n is still nice

  34. flow

    Zash, well for most XMPP UIs you know the xml:lang of the initiating entity I'd assume, so it is nice to have i18n here

  35. Zash

    True

  36. lovetox

    yeah its nice on muc config forms :)

  37. lovetox

    also IBR maybe

  38. lovetox

    everything that interacts with the server

  39. flow

    the problem is really only if you want to send a dataform to someone who did not ask for it

  40. Zash

    Where you have an initiating entity

  41. Zash

    flow: Have you ever wanted to?

  42. lovetox

    also you dont really use i18n on the form there, the server just sends out the form in the correct language

  43. flow

    I can't remember that I ever found myself in the situation, but that doesn't mean that it couldn't be beneficial to be prepared for it

  44. lovetox

    Zash, your issue tracker could send you a new ticket was created and you could act on it from inside xmpp

  45. lovetox

    i find that a nice usecase

  46. flow

    But here the i18n issue could be solved by putting xml:lang into PEP

  47. Zash

    Just Do It!

  48. flow

    I'm going to make another cup of tea, that is what I'm just doing right now

  49. Zash

    As long as it supports multiple languages and you've studied prior art like Accept-Lang and whatever the language field in vcard was.

  50. flow

    sure, that is what I also had in mind

  51. flow

    but then again, not a top priority (for me) right now. I gotta find out how to UEFI boot from a soft-raid1 ESP

  52. pep.

    > Flow> the problem is really only if you want to send a dataform to someone who did not ask for it > Zash> flow: Have you ever wanted to? Wouldn't it be the case for polls with dataforms

  53. pep.

    (If that existed, but it's among the discussed topics right, /me not entirely following)

  54. lovetox

    yes you could facilitate a vote with it, even voting for multiple things in one go

  55. lovetox

    but its deemed to complicated, mostly because most clients dont implement a generic form viewer which you would need for it

  56. flow

    pep., well if you consider the memberbot for example, then there is an initial message to start the poll

  57. pep.

    What about non-bots? You're assuming you've got the lang from previous discussions as well?

  58. flow

    pep., I'm not sure which scenario you are sketching

  59. pep.

    Somebody wants to submit a poll in a MUCs. Somebody that is not a bot. I definitely know MUCs where not everybody speaks the same language

  60. pep.

    I could send multiple forms, but then I might want a way to reconcile

  61. flow

    I'm not sure if this is how I would implement it. A, possibly ad-hoc based, voting service appears to be a better approach. But if you want to send a poll to a MUC with probably mulit-lang participants, then you need to submit the poll multiple times in every language anyways

  62. pep.

    Would be good of other users could chime in and translate it, like sending a new form with a different xml:lang with the same stanzaid or sth, maybe. I have no idea how horrible this is protocol design wise

  63. moparisthebest

    And how do you know they are translating your form instead of insulting everyone

  64. pep.

    You don't, but that's probably not something I want to worry about, they can already do that anyway

  65. pep.

    Or well you do, they're still sending messages in the same room

  66. Neustradamus

    https://github.com/horazont/xmppoke-queue is planned to move to https://github.com/xmpp-observatory/ like others?

  67. rion

    Can anyone explain me what is ni:///sha3-256;wqfDv8OGw7jCvx7Dl2ZRw4FHVsKgYcOWYsO14oKsw79Nw6Q7ScO64oCaw5gKS-KCrMO4Q0o in SIMS?

  68. rion

    ah found.