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

Jay Carlson nop at mitre.org
Thu Feb 16 22:01:11 UTC 2006


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