-
Notifications
You must be signed in to change notification settings - Fork 121
/
xep-0026.xml
210 lines (199 loc) · 11.7 KB
/
xep-0026.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Internationalization (I18N)</title>
<abstract>NOTE WELL: this document was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
&LEGALNOTICE;
<number>0026</number>
<status>Retracted</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies/>
<supersedes/>
<supersededby><spec>XMPP Core</spec></supersededby>
<shortname>N/A</shortname>
<author>
<firstname>Max</firstname>
<surname>Horn</surname>
<email>[email protected]</email>
<jid>[email protected]</jid>
</author>
<revision>
<version>0.2</version>
<date>2003-11-05</date>
<initials>psa</initials>
<remark>The status of this document has been changed to Retracted since it has been superseded by XMPP Core.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-03-14</date>
<initials>mh</initials>
<remark>Initial version.</remark>
</revision>
</header>
<section1 topic='Introduction'>
<p>
Jabber is meant to allow people everywhere in the world to communicate
with each other. However, people converse in many different languages, not just
English. Many humans in fact don't even understand English. Hence,
Jabber should not be tied to a particular language, but rather allow
usage of any language, be it English, Chinese, Inuit, or anything else.
</p>
<p>
One important step towards this goal is that Jabber is based upon
Unicode, allowing for many different languages. But that alone is not
enough. Jabber promotes a server-based system for many of its
components and services, like the JUD, or transports. Many of these have
to interact with users in some way. Currently, they do so in only one
fixed language (usually English). Even if the server admin is willing
to translate the messages, forms, etc. involved, there can only be one
localization active for a given server/component.
</p>
<p>
Hence, Jabber must support a way for clients to inform the server about
their preferred language. In addition, the server and other components
have to understand and honor this information. Only this way can we
ensure that Jabber is able to work in a multi-national, multi-lingual
environment.
</p>
<p>
Some examples on how this information could and should be used, include
</p>
<ul>
<li>Forms (e.g. for registration or searching, refer also to &xep0004;) can be localized, so that instructions and field labels are in the native language of the person who has to fill them out</li>
<li>Even if the form can't be sent in the proper language (e.g. simply because it hasn't yet been translated), the component still should tag its reply with the language being used</li>
<li>Incoming messages in a different language could be automatically translated (server-side or client-side)</li>
<li>Redirection of messages based on their language (think of a help desk which services world wide requests)</li>
<li>Transports to services which are not unicode based could use the language information as a hint at the best encoding (least lossage) for converted messages</li>
</ul>
</section1>
<section1 topic='Implementation'>
<p>
The basic idea behind this proposal was to use existing standards where possible, and to make it fully backward compatible. Furthermore it was a goal to allow clients to support it now, even without any server support, while at the same time permitting improved functionality once servers start to implement this spec.
</p>
<section2 topic='Encoding the locale'>
<p>To encode the locale on any given XML packet, we use the xml:lang attribute, as defined in the <link url="https://www.w3.org/TR/REC-xml#sec-lang-tag">XML specification</link>. This in turn uses values as specified in <link url="https://www.ietf.org/rfc/rfc1766.txt">RFC 1766</link> to encode languages and regions. This way, you can even distinguish between British and Australian English.
</p>
<example caption='Example message with locale set to German'>
<message to='[email protected]' xml:lang='de-DE'>
<body>Ich bin ein Berliner!</body>
</message> </example>
<p>
An xml:lang tag can be put onto any XML element; for the purposes of this document, however, we will limit its usage to the four central Jabber elements: <stream/>, <message/>, <iq/> and <presence/>.
</p>
</section2>
<section2 topic='Client support'>
<p>
A client claiming to support this document has to initiate server connection slightly differently by putting an xml:lang attribute in the initial <stream:stream> element.
</p>
<example caption='Jabber session initiated with Canadian French as default'>
<?xml version="1.0" encoding="UTF-8" ?>
<stream:stream to='jabber.org' xmlns='jabber:client'
xmlns:stream='https://etherx.jabber.org/streams' xml:lang='fr-CA'> </example>
<p>
Servers not supporting this document will just ignore the additional attribute. Compliant server can be distinguished by the fact that their reply <stream:stream> element also contains an xml:lang attribute, indicating the main language of the server. A compliant client has to detect whether the server is compliant or not, and base its future behavior on this information.
</p>
<example caption='Reply by an English-language Jabber server'>
<stream:stream from='jabber.org' id='12345' xmlns='jabber:client'
xmlns:stream='https://etherx.jabber.org/streams' xml:lang='en'> </example>
<p>
If the client thus determines that the server is compliant, then it doesn't have to do anything beyond this point. All its outgoing messages will automatically be flagged by the server with an xml:lang attribute if necessary. Thus writing a minimal compliant client is trivial.
</p>
<p>
If it is determined that the server does not support this document, and the client still wants to offer locale support, it may start flagging all its outgoing message/iq/presence elements with the xml:lang attribute, to ensure that other components/clients which do conform to this document can handle the localization despite the local server not doing so.
</p>
<p>
Finally, if for whatever reasons the client wants to flag particular messages with a different locale (e.g. if the user is bilingual), it can do so at any time by putting an appropriate xml:lang element in the outgoing data. This will override the previously set default locale for this message only.
</p>
</section2>
<section2 topic='Server support'>
<p>
A compliant server must detect the xml:lang attribute in incoming <stream:stream> elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
</p>
<p>
Additionally, a compliant server must attach an xml:lang attribute to the reply <stream:stream> element sent in response to a newly initiated connection. This attribute should reflect the default language of that server, and is used to indicate to clients that the server implements this document.
</p>
<p>
The server should not only allow user clients to specify a default language this way, but also server-side components, like the JUD should be allowed to do this.
</p>
<p>
Whenever a message leave the server, it has to tag the message automatically with the xml:lang attribute of the corresponding seesion, if any was specified, unless the message is already tagged this way. In that case, the already existing xml:lang attribute takes precedence, thus allowing for greater flexibility.
</p>
<p>
If a client send a message to another local client which uses the same xml:lang value, then no change is applied. But if the recipient uses a different xml:lang, and if the message has no xml:lang attribute attached yet, the xml:lang of the server has to be attached before delievey of the message.
</p>
</section2>
<section2 topic='Service support'>
<p>
Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on &xep0004;.
</p>
<example caption='Search form in English'>
<iq from='users.jabber.org' type='result' id='4' xml:lang='en'>
<query xmlns='jabber:iq:search'>
<instructions>
Fill in a field to search for any matching Jabber users.
</instructions>
<nick/>
<first/>
<last/>
<email/>
<x xmlns='jabber:x:data'>
<instructions>
To search for a user fill out at least one
of the fields below and submit the form.
</instructions>
<field type='text-single' label='First (Given)' var='first'/>
<field type='text-single' label='Last (Family)' var='last'/>
<field type='text-single' label='Nick (Alias)' var='nick'/>
<field type='text-single' label='Email' var='email'/>
</x>
</query>
</iq> </example>
<p>
This way, a client could for example offer to translate the form since it now knows the language the form was written in. Previously it could just guess the language was English, which never was guaranteed.
</p>
<p>
To be able to tailor replies to the user's preferred language, the component has to know this information. This is simply inferred from any xml:lang attribute on incoming requests. If none is present, the default locale is assumed. If the client's default locale diverges from that of the component, it is the server's responsibility to tag the query with an appropriate xml:lang attribute (refer to the "Server support" section). If on the other hand the server is not compliant, then any interested client will manually tag its queries with an xml:lang attribute. Thus it is sufficient to check for this attribute.
</p>
<example caption='Request for a German-language search form'>
<iq to='users.jabber.org' type='get' id='5' xml:lang='de'>
<query xmlns='jabber:iq:search'/>
</iq> </example>
<p>
A more sophisticated component supporting multiple localizations of its forms/messages could now honor the requested language and send this search form instead of the English one shown previously:
</p>
<example caption='Search form in German'>
<iq from='users.jabber.org' type='result' id='5' xml:lang='de'>
<query xmlns='jabber:iq:search'>
<instructions>
Füllen Sie ein Feld aus um nach einem beliebigen
passenden Jabber-Benutzer zu suchen.
</instructions>
<nick/>
<first/>
<last/>
<email/>
<x xmlns='jabber:x:data'>
<instructions>
Um nach einem Benutzer zu suchen, füllen Sie mindestens eines
der folgenden Felder aus und schicken dann das Formular ab.
</instructions>
<field type='text-single' label='Vorname' var='first'/>
<field type='text-single' label='Nachname' var='last'/>
<field type='text-single' label='Spitzname' var='nick'/>
<field type='text-single' label='Email' var='email'/>
</x>
</query>
</iq> </example>
<p>
If the component doesn't have the requested localization available, it replies with the default localization (but of course with the matching xml:lang attribute tagged to it, and not the one of the request).
</p>
</section2>
</section1>
</xep>