plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441

First of all, thank you for helping translating SàT :)

NOTE: *.po files are in i18n directory

To translate a file, you can use a dedicated tool as the excellent gtranslator:

- use the template .pot file (e.g. sat.pot) and name it to your translated language (e.g. fr.po for french); you can preferably generate a new template directly from the source with the following command (eventually adapted, the following command use zsh's globbing syntax), launched from root sat dir after having emptied the build directory:
> xgettext -L python -d sat --keyword=D_ -p i18n  **/*(.py|.tac|primitivus)(.) **/jp(.)

- then to start a new translation, copy i18n/sat.pot to your language file, e.g. cd i18n; cp sat.pot fr.po

- use the choosed tool (a simple text editor can be sufficient) to edit the file: e.g. gtranslator fr.po

- once you translation is finished (or partly finished: the english sentences are used if there is no translation), you can test them by generating a binary and moving it to the right place with the following commands:
> msgfmt -o sat.mo fr.po
> mv sat.mo i18n/fr/LC_MESSAGES/sat.mo

- if you have already a translation, and want to update it (new translations to do, some sentences have changed), you can use the following commands:
> msgmerge fr.po sat.pot > fr2.po
and if everything is allright
> mv fr2.po fr.po

Don't forget that you can (and should !) use the version-control system (mercurial, the "hg" command) to keep history of you translations.

You can check the fr.po file to see how it's done and to know what to put while you set up you translation tool.

Thank you again for you help, don't forget to give me your name and contact email so I can credit you, and don't hesitate to contact me if you need help (goffi@goffi.org, or the sat XMPP room at sat@chat.jabberfr.org).