1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00

Sort i18n sections

This commit is contained in:
Steve Kille 2016-11-30 10:06:53 +00:00
parent ab3740dff2
commit 62c9595fbb

View File

@ -1075,9 +1075,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
</register>
</iq>
]]></example>
<p>On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.</p>
<p>On success, the service informs the user of its nick. MIX SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700; to the requested nick. This means that nick that is issued might be different from the nick that was requested.</p>
<p>
MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
</p>
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
@ -1253,7 +1253,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
Two approaches to message retraction may be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
</p>
<p>
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redcated.
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element that shows the JID of user performing the retraction and the time of the retraction.
</p>
<example caption="Retracted message tombstone in a MAM result"><![CDATA[
@ -2022,8 +2022,10 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>TBD.</p>
<p>Discuss normalization of nicknames.</p>
<p>MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the subject of a MIX channel and name and description information. These strings may have language set using an xml:lang attribute, and multiple values may be set provided that each one is distinguished using xml:lang.
</p>
<p>Nicknames SHOULD be normalized using the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. </p>
</section1>
@ -2052,6 +2054,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.</p>
</section1>
</xep>
<!--TODO: Query whole service for MAM. Provide data form for filtering by node ID.