[Standards-JIG] Separation of concerns in JEP-0171, Translation

Fletcher, Boyd C. GS-13 J9935 Boyd.Fletcher at je.jfcom.mil
Thu Feb 16 23:20:05 UTC 2006


The plan for detecting the origin language was by reading the XML:LANG
attribute of the senders message for which there is no associated
<translation> tag (section 4.1)  but after rereading section 4.1 I can
see that is less than clear. However, there is no way to specifically
state what your preferred language is - we made the assumption that the
client's default language is the same as the user. 

Perhaps we could use jep-0145's languages_lesswell and languages_well
for determing preferred language for a user or add preferred_language
tag for your primary language or implement ordering in the
languages_well.

We would really like to keep a single JEP but we are very interested in
any changes you would like to make.

boyd



> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Jay Carlson
> Sent: Thursday, February 16, 2006 5:01 PM
> To: Jabber protocol discussion list
> Subject: [Standards-JIG] Separation of concerns in JEP-0171, 
> Translation
> 
> After reading through JEP-0171, it seems to me as if there 
> are two different areas that might be covered by the Translation JEP.
> 
> The first is provision of translation services.  This is 
> concerned with discovery and message exchange with 
> translation providers.  There's only one showstopper there 
> (the lack of ids to tie responses to requests), and some 
> other issues that range from matters of taste to 
> expressiveness.  For example, some translation engines 
> support stackable dictionaries, leading to a 2^n explosion in 
> enumeration.
> 
> The second is the utilization of translation services by user 
> agents.  I think this is less well developed. 
> 
> It is unclear how to discover the preferred language spoken 
> by someone, and very hard in the case of multiparty chat.  
> This is useful for translation-on-receipt, but critical to 
> translation-before-send.
> 
> (Pre-translation also raises security issues; that is, my 
> translator could sense-invert "I will not pay you" to "I will 
> pay you" before sending to you.  However, trying to plug that 
> one goes down a rathole of enclosing translation 
> request/response pairs signed by the translator, so let's not 
> go there.  We can bury it in the security considerations.)
> 
> Right now the <translation/> tag is used for all three of the 
> following:
> 
> 1) Requesting a translation
> 2) Receiving a translation response
> 3) In chat messages intended for a human, to indicate that 
> some of the multiple message bodies were machine-translated
> 
> I know #3 sounds awkward, but reuse there *seems* awkward to 
> me, so excuse my poor rephrasing of it. :-)
> 
> If anybody's interested, I could slice up the current JEP 
> into some smaller parts, either internal to the text, or by 
> forking off another.
> 
> I've got a list of potential issues with the translation 
> service parts, but I'll send mail about that separately.
> 
> Jay Carlson    nop at mitre.org    (781) 271-2378
> Principal Engineer       The MITRE Corporation
> 



More information about the Standards mailing list