[Standards] UPDATED: XEP-0171 (Language Translation)

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 15 20:49:35 UTC 2008


Boyd Fletcher wrote:
> comments inline below.

Ditto.

> On 2/1/08 7:27 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
> 
>> XMPP Extensions Editor wrote:
>>> Version 0.3 of XEP-0171 (Language Translation) has been released.
>>>
>>> Abstract: This document defines an XMPP protocol extension for
>>> providing language translation facilities over XMPP. It supports
>>> human, machine, client-based, and server-based translations.
>>>
>>> Changelog: [See revision history] (kl/bf)
>>>
>>> Diff:
>>> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0171.xml?r1=257&r2
>>> =1649
>>>
>>>
>>> URL: http://www.xmpp.org/extensions/xep-0171.html
>> As far as I can see, the earlier feedback regarding this spec has not
>> yet been addressed. In particular the following issues:
>>
>> 1. Registering a translation provider with a server
>>
>> http://mail.jabber.org/pipermail/standards/2006-October/012579.html
>>
>> I agree with Ralph Meijer that this can be done via entity capabilities
>> (XEP-0115):
>>
>> http://mail.jabber.org/pipermail/standards/2006-October/012596.html
>>
>> But it would be good for the spec to say that explicitly.
>>
>> And see also:
>>
>> http://mail.jabber.org/pipermail/standards/2006-October/012581.html
>> http://mail.jabber.org/pipermail/standards/2006-October/012582.html
>> http://mail.jabber.org/pipermail/standards/2006-October/012585.html
>>
> 
> this problem is essentially "how do remote services register themselves as a
> service to an XMPP server"
> 
> Once this problem is solved for the community in a generic way, then the
> lang trans spec can be updated to reflect the data fields required for a
> registering a remote lang translation service.

Yes, that seems out of scope for the language translation spec. It might
be interesting to define a method for registration of remote services
with an XMPP server, but I would not expect the language translation
spec to define that. :)

>> 2. Server-requested translation
>>
>> http://mail.jabber.org/pipermail/standards/2006-October/012580.html
>>
> 
> after investigating this further it does not appear we need to change the
> spec as it already supports a mechanism for the server to ask for
> translation. Essentially what Chris is suggesting here, which is a neat
> idea, is translations could occur without the specific request of the user.
> There is nothing stopping a developer from modifying the presence and MUC
> services on an XMPP to support using XEP-171 to translate text. So we are
> not sure why the spec would need to be modified.
> 
> there is one pitful however is inline automated translations, because there
> are many cases where a user would not want that behavior done as machine
> lang trans is not 100% and that could lead to problems/misunderstandings if
> a message was translated without a user being aware of that occurring.
> BTW, the language a user is speaking is identified by the XML:Lang attribute
> to the presence or message packet which unfortunately major clients to not
> send. 

I looked at Chris's original message. He's saying that it would be nice
if the server could ask you to translate a certain message or presence
stanza and then resend it. I have a few objections to that. For one, if
the server or MUC service wants to translate some text, it could do so
on its own (this might be especially helpful in a MUC room). Or the
receiving client could request a translation of text it receives (e.g.,
send text it doesn't understand to a bot for translation). I don't know
if putting the burden on the sending client makes much sense.

Yes, there are issues of unwanted translation and that is something we'd
probably want to avoid (e.g., I'm in a MUC room and I understand English
and Czech so I don't want the MUC service to translate messages sent in
those languages, but I want it to translate messages from other
languages into English). This would require some kind of protocol for
managing the translation-related behavior of the MUC room. While that is
interesting, it is also complicated and, I think, out of scope for the
language translation spec itself.

>> I'll try to complete my own detailed review soon.

I still need to do that...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080215/af27417b/attachment.bin>


More information about the Standards mailing list