[Standards-JIG] JEP-0171 (Translation): One successful upon-receipt model

Boyd Fletcher boyd.fletcher at je.jfcom.mil
Wed Feb 22 05:54:22 UTC 2006


> 
>> The second is that presence data has arbitrary key/value pairs.  This allows
>> us to stuff a preferred language field into each user's profile in a
>> distinguished spot.
> 
> In XMPP you can include an xml:lang attribute anywhere you want -- doing
> that in all the presence stanzas you send would be good.
> 
> <snip/>
> 

what about using jep-0145. the problem I see with using the XML:Lang tag of
the message, is that it indicates what the client is operating at, but might
not necessarily represent what the user's preferred language is.



>> In any case, anybody with a translation-on-receipt model needs to have a
>> reliable way of having multiple translation requests in the air, and
>> returned in indeterminate order.  The simplest way we can think of to
>> support this is to allow requestors to specify a thread id on request, and
>> have the response include it.
>> 
>> I think the JEP should be modified to state that translation responses will
>> echo the thread id of the request, and that will solve the showstopper for
>> us.  This doesn't deal with the issue of providing continuing context to a
>> translation engine, but I think it's much closer.  I don't know enough XMPP
>> to figure out how to solve both the need for a unique ID for a
>> request/response pair, and an association with an ongoing translation
>> context.
> 
> That seems reasonable to me. Your two options for tracking would be the
> 'id' attribute or the message <thread/> element. The ThreadID seems more
> useful in this context, since it seems that you want to track that a
> received message is related to the original message (where you might
> receive multiple translated messages for the reasons you state).
> 
> Peter

I like the thread approach as well. Peter, do you want us to update the JEP
or do you want to do it?




More information about the Standards mailing list