[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
We would really like to keep a single JEP but we are very interested in
any changes you would like to make.
> -----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,
> 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
> 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
> (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
> 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