This JEP defines a protocol for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0171
Version: 0.1
Last Updated: 2006-01-24
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030
Supersedes: None
Superseded By: None
Short Name: langtrans
Wiki Page: <http://wiki.jabber.org/index.php/Language Translation (JEP-0171)>
Email: boyd@spawar.navy.mil
Email: daniel.laprade@je.jfcom.mil
Email: keith.lirette@je.jfcom.mil
Email: brian.raymond@je.jfcom.mil
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
There currently exists no standard for describing language translations over a text chat protocol. While numerous products and services exist to provide translation of text, there exists no standardized protocol extension for requesting a translation and expressing the details of the translation XMPP (see RFC 3920 [1]). This document describes how to express a translation and its components in an XMPP message as well as a method to request translation.
Direct translation can be realized by either client-side translation before sending or transparent components translating messages on the fly. Discovering XMPP entities capable of translation allows for clients to request translation from them based on their capabilities. The remote XMPP entity could be either an automated translation service or a human providing translation.
Table 1: Glossary
| Term | Definition |
|---|---|
| Original Text | This is the message text that was originally created by the sender. This is the text that is translated. |
| Translated Text | This is the message text that has been translated by the language translation engines. This also called the destination text. For any given message there can be multiple destination text message bodies. |
| Pivot Language | Pivoting is the process of using one or more intermediate languages to translate from a given source language to a specific destination language. For example, if you needed to translate from English to Russian but only had translators that went from English to French and French to Russian then you could use French as a pivot language. |
| Pivot Text | This is the translated text of the original message in a pivot language. For any given destination language, there can be zero or more pivot text bodies. The ordering of pivoting is required to be specified for the destination language. |
| Language Translation Engine | Since not all language translation engines are the same quality it is important to some classes of users that they know what translation engine was used. It is equally important to also be able to select a specific translation engine for a given language pairing if more than one engine is available. |
| Language Translation Character Set | Some language translation engines can only translate text between languages if certain character sets (or code pages) are used. |
| Language Translation Dictionary | In order to enhance the accuracy of translation engines most support the concept of mission specific dictionaries. |
The protocol defined herein addresses the following requirements:
Enable an XMPP entity to request a translation from a remote XMPP entity.
Enable an XMPP entity to express the following mandatory elements of a translation for any receiving entities.
Enable an XMPP entity to express the following optional elements of a translation for any receiving entities.
The following methods of translation are supported:
The following use cases simple scenarios for expression translation as well as requesting them from remote entities.
A message directly translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with only the required elements of source and destination language; this is the simplest case for a translation from one language to another. The source language is known because there is no <translation/> tag describing it. Three translation methods are supported by doing the following:
Example 1. Entity sends a message translated from English to French
<message from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
<subject xml:lang='en'>Hello</subject>
<subject xml:lang='fr'>Bonjour</subject>
<body xml:lang='en'>How are you?</body>
<body xml:lang='fr'>comment allez-vous?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr' derived_from='en'/>
</x>
</message>
A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.
Example 2. Entity sends a message translated from French to Russian via English using human translators
<message from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
<subject xml:lang='fr'>Bonjour</subject>
<subject xml:lang='en'>Hello</subject>
<subject xml:lang='ru'>x443;лте</subject>
<body xml:lang='fr'>comment allez-vous?</body>
<body xml:lang='en'>How are you?</body>
<body xml:lang='ru'>Как вы?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='en' derived_from='fr'/>
<translation destination='ru' derived_from='en'/>
</x>
</message>
A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity using pivot languages and machine translation. The source language is known because there is no <x/> translation tag describing it.
Example 3. Entity sends a message translated from French to Russian via English using a machine translation engine.
<message from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
<subject xml:lang='fr'>Bonjour</subject>
<subject xml:lang='en'>Hello</subject>
<subject xml:lang='ru'>x443;лте</subject>
<body xml:lang='fr'>comment allez-vous?</body>
<body xml:lang='en'>How are you?</body>
<body xml:lang='ru'>Как вы?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='en' derived_from='fr' engine='SYSTRANS'/>
<translation destination='ru' derived_from='en' engine='SYSTRANS'/>
</x>
</message>
When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using Service Discovery [2]. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.
Example 4. Entity sends discovery request to server
<iq type='get' id='disco1' to='shakespeare.lit'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
Example 5. Server returns items, including translation providers
<iq type='result' id='disco1' from='shakespeare.lit' to='bard@shakespeare.lit/globe'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
<item jid='towerofbabel@shakespeare.lit'
name='Tower of Babel Translation Bot'/>
<item jid='translation.shakespeare.lit'
name='Translation Provider Service'/>
...
</query>
</iq>
Service Discovery is used to determine if a JID provides translation services. The JID can also be a bot (e.g., <towerofbabel@shakespeare.lit>) or a server component (e.g., <translation.shakespeare.lit>).
Example 6. Entity queries service regarding identity
<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
Example 7. Service reports identity
<iq type='result' to='bard@shakespeare.lit/globe' from='translation.shakespeare.lit'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<identity category='automation' type='translation'/>
<feature var='http://jabber.org/protocol/langtrans'/>
...
</query>
</iq>
The supported languages and other details for the service must be known to use it. It is permissible for a translation service to provide multiple translation engines for the same language pairing -- if this is done, then a separate <item/> tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific <item/>. In order to specify more than one dictionary for a given language pairing then a separate <item/> tag MUST be used for each dictionary specification for that language pairing.
Example 8. Entity queries service for further information
<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
<query xmlns='http://jabber.org/protocol/langtrans#items'/>
</iq>
Example 9. Service replies with language details
<iq type='result' to='bard@shakespeare.lit/globe' from=' translation.shakespeare.lit'>
<query xmlns=' http://jabber.org/protocol/langtrans#items'>
<item src_lang='en' jid='translation.shakespeare.lit' dst_lang='fr'
engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item src_lang='en' jid='translation.shakespeare.lit' dst_lang='ko'
engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item src_lang='en' jid='translation.shakespeare.lit' dst_lang='ru'
engine='SYSTRANS 2005 Release 2' pivotable='true'/>
<item src_lang='en' jid='translation.shakespeare.lit' dst_lang='ru'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='medical'/>
<item src_lang='fr' jid='translation.shakespeare.lit' dst_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='standard'/>
<item src_lang='ru' jid='translation.shakespeare.lit' dst_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='Medical 1.0'/>
<item src_lang='ko' jid='translation.shakespeare.lit' dst_lang='en'
engine='SYSTRANS 2005 Release 2' pivotable='true'/>
</query>
</iq>
To request service from a translation provider you can send a message to a provider requesting translations. The lack of a 'derived_from' attribute in the <translation/> element indicates a request for a translation.
Example 10. Entity requests a translation from English to French
<message from='bard@shakespeare.lit/globe' to='translation.shakespeare.lit'>
<subject xml:lang='en'>Hello</subject>
<body xml:lang='en'>How are you?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr'/>
</x>
</message>
Example 11. Translation is returned from translation provider
<message from='translation.shakespeare.lit' to='bard@shakespeare.lit/globe'>
<subject xml:lang='fr'>Bonjour</subject>
<subject xml:lang='en'>Hello</subject>
<body xml:lang='fr'>comment allez-vous?</body>
<body xml:lang='en'>How are you?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr' derived_from='en'/>
</x>
</message>
Example 12. bard requests a translation from English to French and Russian
<message from='bard@shakespeare.lit/globe' to='translation.shakespeare.lit'>
<subject xml:lang='en'>Hello</subject>
<body xml:lang='en'>How are you?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr'/>
<translation destination='ru'/>
</x>
</message>
Example 13. Translation is returned from translation provider
<message from='translation.shakespeare.lit' to='bard@shakespeare.lit/globe'>
<subject xml:lang='en'>Hello</subject>
<subject xml:lang='fr'>Bonjour</subject>
<subject xml:lang='ru'>x443;лте</subject>
<body xml:lang='fr'>comment allez-vous?</body>
<body xml:lang='en'>How are you?</body>
<body xml:lang='ru'>Как вы?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr' derived_from='en'/>
<translation destination='ru' derived_from='en'/>
</x>
</message>
If a specific dictionary is required you MAY request a dictionary. This SHOULD have been returned when discoing the server although a dictionary MAY be requested which was not. The dictionaries are translation engine specific and are free form text.
Example 14. Requests a translation from English to French using the 'medical' dictionary
<message from='bard@shakespeare.lit/globe' to='translation.shakespeare.lit'>
<subject xml:lang='en'>Hello</subject>
<body xml:lang='en'>How are you?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr' dictionary='medical'/>
</x>
</message>
Example 15. Translation provider returns translation with dictionary details
<message from='translation.shakespeare.lit' to='bard@shakespeare.lit/globe'>
<subject xml:lang='fr'>Bonjour</subject>
<subject xml:lang='en'>Hello</subject>
<body xml:lang='fr'>comment allez-vous?</body>
<body xml:lang='en'>How are you?</body>
<x xmlns='http://jabber.org/protocol/langtrans'>
<translation destination='fr' derived_from='en' dictionary='medical'/>
</x>
</message>
If the translation service cannot complete the translation it SHOULD return a error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.
Example 16. Translation could not be completed
<message from='translation.shakespeare.lit' to='bard@shakespeare.lit/globe' type='error'>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
</error>
</message>
If privacy or security considerations make returning an error not feasible it SHOULD return a error.
Example 17. Service unavailable
<message from='translation.shakespeare.lit' to='bard@shakespeare.lit/globe' type='error'>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
</error>
</message>
In order to reduce user confusion and misunderstanding of a translated message body, it is RECOMMENDED that implementations of langtran implement the following user interface features.
Note: The 'reviewed' and 'pivotable' attributes are of type "boolean" and MUST be handled accordingly. [3]
In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in RFC 3920.
Potential attacks may be easier against services that implement translation because of the potential disclosure of information regarding language pairings, engines, and dictionaries used however no specific vulnerabilities are introduced.
This possible weakness can be mitigated by not returning specifics to requesting entities and the responding entity MAY perform authorization checks in order to determine how to respond.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].
The Jabber Registrar [5] shall include 'http://jabber.org/protocol/langtrans' and 'http://jabber.org/protocol/langtrans#items' in its registry of protocol namespaces.
The Jabber Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns='http://jabber.org/protocol/langtrans'
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/langtrans'
elementFormDefault='qualified'>
<xs:element name='x'>
<xs:complexType>
<xs:sequence>
<xs:element ref='translation'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='translation'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='charset' type='xs:string' use='optional'/>
<xs:attribute name='derived_from' type='xs:language' use='optional' />
<xs:attribute name='destination' type='xs:string' use='required'/>
<xs:attribute name='dictionary' type='xs:string' use='required'/>
<xs:attribute name='engine' type='xs:string' use='optional' />
<xs:attribute name='reviewed' type='xs:boolean' use='optional' default='false'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns='http://jabber.org/protocol/langtrans#info'
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/langtrans#info'
elementFormDefault='qualified'>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='dictionary' type='xs:string'/>
<xs:attribute name='dst_lang' type='xs:language'/>
<xs:attribute name='engine' type='xs:string' use='optional'/>
<xs:attribute name='jid' type='xs:string' use='required'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
<xs:attribute name='pivotable' type='xs:boolean' use='optional' default='false'/>
<xs:attribute name='src_lang' type='xs:language' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
2. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
3. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
5. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END