Provided by: emdebian-tdeb_3.0.7_all bug

NOM

       em_installtdeb - Creer les paquets de traduction TDeb d'Emdebian et les sources

SYNOPSIS

       em_installtdeb

       em_installtdeb [LANG_CODE]

       em_installtdeb [--no-act]

       em_installtdeb [--no-sign]

Copyright et Licence

        Copyright (C) 2007-2008  Neil Williams <codehelp@debian.org>

       Ce logiciel est libre; vous pouvez le redistribuer selon les termes de la licence GNU
       General Public License telle que publiee par la Free Software Foundation; en prenant la
       version 3 de la licence ou (selon votre choix) n'importe quelle version subsequente.

       Ce logiciel est distribue dans l'espoir qu'il soit utile, mais AUCUNE GARANTIE n'est
       donnee tant pour des raisons COMMERCIALES que pour REPONDRE A UN BESOIN PARTICULIER.
       Consulter la Licence Publique Generale GNU pour plus de details.

       Vous devriez avoir recu une copie de la Licence Publique Generale de GNU avec ce
       programme. Sinon, voir <http://www.gnu.org/licenses/>.

DESCRIPTION

       em_installtdeb est un ajout a debhelper cree par Emdebian pour creer des paquets de
       traduction (tdebs). em_installtdeb est prevu pour separer les fichiers individuels de
       traduction des paquets Debian courants en paquets sans aucun fichier de traduction et une
       serie de paquets tdeb de localisation, un par traduction. Les paquets generes ainsi
       utilisent la syntaxe : $package-locale-$language_code_$version_all.deb

       (Depuis la version 3.0.0, les TDebs sont independants de l'architecture.)

       Une fois qu'un paquet utilise em_installtdeb, les fichiers de traduction devraient etre
       enleves de tous les paquets dans la construction normale. em_installtdeb s'execute comme
       une deuxieme construction (tres petite, tres rapide) qui convertit simplement et
       empaquette les fichiers *.po en tdebs. Un paquet source tdeb est cree (.dsc, .tar.gz et
       .changes) a cote des donnees de la construction existante. Le paquet source est utilise
       par des traducteurs pour construire des mises a jour ou de nouveaux paquets tdeb. Les
       fichiers .changes de Tdeb doivent etre envoyes seulement dans les depots de localisation
       secondaires a la place des miroirs Debian principaux et ces depots peuvent avoir une
       politique d'envoi beaucoup moins stricte. Les paquets Tdeb n'ont pas de dependances et
       aucun paquet ne peut dependre d'eux.

       em_installtdeb n'utilise actuellement que les traductions gettext.

       Certains encodages linguistiques doivent etre modifies pour etre des composants
       acceptables d'un nom de paquet debian. Les X _ X sont convertis en traits d'union, X @ X
       est converti en X + X et tous les codes sont ecrits en minuscules. Ces changements ne
       s'appliquent qu'aux noms de paquet, l'endroit de l'installation est inchange.

       Le paquet locale doit utiliser GETTEXT_PACKAGE pour le nom du fichier binaire de
       traduction eventuel X bien que ceci puisse etre identique a $dh{MAINPACKAGE}.
       GETTEXT_PACKAGE est determine en amont, pas par Debian. En construisant le paquet entier,
       le fichier binaire de traduction peut-etre dans
       debian/tmp/usr/share/locale/$lang/LC_MESSAGES mais lorsque l'on se trouve dans le mode
       traducteur, cet endroit n'est pas disponible. Au lieu de rechercher GETTEXT_PACKAGE a
       partir du nom de fichier POT,  de la macro Makefile GETTEXT_PACKAGE ou, si ceux-ci ne sont
       pas renseignes, utiliser le nom du paquet source amont. Cette partie doit peut-etre etre
       allongee.

       La X source X pour les traducteurs inclut donc :

        debian/rules  /* dummy file */
        debian/control
        debian/changelog
        po*/$lang.po  /* if any */
        po*/$GETTEXT_PACKAGE.pot /* may be more than one */

       Certains paquets utilisent plusieurs repertoires po et em_installtdeb recherche un fichier
       POT dans tous les repertoires po, et les inclut dans le source tdeb avec tous les fichiers
       PO : par exemple

        po/fr.po
        po-lib/fr.po
        po/application.pot
        po-lib/library.pot

       Une fois empaquete, le tdeb construit a partir de ce source contiendra :

        ./usr/share/locale/fr/LC_MESSAGES/application.mo
        ./usr/share/locale/fr/LC_MESSAGES/library.mo

       Un equivalent tdeb pour la localisation X de X contiendrait :

        ./usr/share/locale/de/LC_MESSAGES/application.mo
        ./usr/share/locale/de/LC_MESSAGES/library.mo

       Ceci est a comparer avec le modele Debian X l'espace-disque-ne-coute-pas-cher X qui separe
       les fichiers application.mo et library.mo mais combine toutes les traductions dans un seul
       paquet, de sorte que le paquet Debian equivalent contiendrait :

        ./usr/share/locale/cs/LC_MESSAGES/application.mo
        ./usr/share/locale/de/LC_MESSAGES/application.mo
        ./usr/share/locale/fr/LC_MESSAGES/application.mo
       ...
        ./usr/share/locale/sv/LC_MESSAGES/application.mo
        ./usr/share/locale/ro/LC_MESSAGES/application.mo
        ./usr/share/locale/vi/LC_MESSAGES/application.mo

       (repete a nouveau pour les autres paquets.)

       Beaucoup de paquets contiennent des douzaines de traductions X certains contiennent plus
       de 70 fichiers .mo et la taille des fichiers .mo peut varier entre 2 kb et 30 kb chacun.
       Sans les tdebs, tous les utilisateurs auraient les 70 traductions meme si seulement une ou
       deux seraient utilisees. Avec les tdebs, tous les utilisateurs obtiennent la bibliotheque
       et les traductions d'application mais seulement pour les une ou deux localisations gerees
       par cette installation. La granularite supplementaire obtenue en eclatant les fichiers
       application.mo et library.mo dans des paquets separes pour la meme localisation ne vaut
       probablement pas la charge de travail qu'elle induit. (En effet, ceci signifie que des
       paquets avec des traductions multiples ne sont pas reellement geres X au moins pas de la
       facon classique.) Il est possible que des developpements comme dpkg filtering pourront
       mettre en application ce niveau final de division, en cas de besoin.

       em_installtdeb va essayer de generer le(s) fichier(s) POT necessaire(s) et ensuite creer
       un $package_$version_tdeb.tar.gz contenant les fichiers de source.

       N'importe quel paquet peut avoir un tdeb source, tant que le fichier POT est empaquete ou
       peut etre construit. Le paquet n'a pas besoin d'avoir deja ete traduit.

       Pour plus de details sur Tdebs, consultez
       <http://www.emdebian.org/emdebian/langupdate.html>
       <http://wiki.debian.org/i18n/TranslationDebs>

       Notez que l'implementation Embdebian des tdebs differe de celle proposee par Debian car
       Emdebian ne s'inquiete pas des pages de manuel en general, et encore moins des pages de
       manuel traduites. Une fois que l'option DEB_BUILD_OPTION X nodocs X sera geree dans
       debhelper, ce ne sera pas un probleme puisque les tdebs peuvent etre construits pour
       Emdebian sans aucune page de manuel. Les autres documentations traduites seront aussi
       omises par X nodocs X. Les images contenant des textes traduits sont relativement peu
       nombreuses.

       Pour controler l'augmentation du nombre de paquets (en moyenne 10 fois plus), le depot de
       localisation secondaire organise les paquets tdeb par racine locale (de parametres
       regionaux), par exemple X en_GB X est sous X en X et X sr@Latn X sous X sr X. Chaque
       racine locale (de parametres regionaux) devient un source apt unique dans le depot locale
       (de parametres regionaux) pour gerer le passage d'une localisation specifique vers une
       racine locale plus generale. De cette maniere, chaque dispositif a seulement a faire face
       aux donnees de cache pour une fraction du nombre total de paquets tdeb (approximativement
       1 sur 30).

       Une nouvelle application C/C++ manipule alors l'installation et la mise a jour des paquets
       tdeb selon la liste des parametres regionaux geres et la liste des paquets installes. Les
       donnees mises en cache par langupdate le sont temporairement et ne le sont pas dans
       l'optique de les conserver entre les executions consecutives de langupdate.

OPTIONS

       L'action par defaut est de traiter tous les fichiers PO disponibles.

       Ce mode est utilise par les mainteneurs de paquets pour generer des sources tdeb et des
       binaires a la fin de la construction Debian (Debian build) (avec les fichiers de
       traduction omis). Notez que cela signifie un deuxieme .dsc, un deuxieme .changes, un
       deuxieme (beaucoup plus petit) .tar.gz utilisant le suffixe tdeb.tar.gz et un envoi separe
       vers le second depot locale. emdebian-tools inclura des gestionnaires (X handlers X) pour
       ces operations et Debian pourra creer des encapsuleurs (X wrappers X) similaires si
       necessaire.

       Ce mode de mise a jour unilingue d'em_installtdeb est peu susceptible d'etre maintenu une
       fois que le dpkg-gentdeb sera disponible parce que les traductions sont moins susceptibles
       d'etre mises a jour dans Emdebian que dans Debian.

       LANG_CODE
           LANG_CODE peut etre soit le nom de la localisation comme specifie dans le nom du
           fichier PO (fr, en_GB, sr@Ltn, etc.) soit le nom de la localisation comme specifie
           dans le nom du paquet eventuel (fr, en-gb, sr+ltn, etc.)

           Si un fichier PO existe deja pour cette localisation, em_installtdeb traite juste
           cette traduction et construit un seul paquet tdeb.

           Si le fichier PO n'existe pas, em_installtdeb quitte avec une erreur. (Copier le
           fichier POT du source original pour creer un nouveau fichier PO pour la nouvelle
           localisation et l'editer pour inclure la nouvelle traduction, puis executer a nouveau
           em_installtdeb).

           LANG_CODE est prevu comme un X mode traducteur X ou les paquets tdeb individuels
           peuvent etre construits par un traducteur et transferes vers le depot approprie.
           em_installtdeb cree l'archive du tdeb source, un fichier .dsc utilisable pour decrire
           le fichier source tdeb et un fichier tdeb.changes.

       no-act
           em_installtdeb va juste imprimer les donnees de controle qui vont etre utilisees pour
           les tdeb si l'option --no-act de debhelper est utilisee.

       no-sign
           em_installtdeb appelle normalement X debsign X quand le .changes est ecrit. Cette
           option supprime ce comportement.

Utilisation dans Debian

       Notez que l'utilisation de debian/xcontrol dans le script actuel signifie que XS-TDeb-
       Build-Directory et XS-TDeb-POT-Names devront etre geres dans debian/control avant
       l'adoption par Debian. En meme temps, XC-Package-Type: tdeb a, lui aussi, besoin d'etre
       traite.

       reprepro a besoin d'un patch pour accepter les .tdeb et autoriser .tdeb dans les fichiers
       du depot :
        $ reprepro --ignore=extension -b /path/ includedeb \
        unstable ../qof-locale-sv_0.7.5-1em1_arm.tdeb
        $ ls /opt/reprepro/locale/pool/main/q/qof/
        qof-locale-sv_0.7.5-1em1_arm.deb

       Nom de fichier : pool/main/q/qof/qof-locale-sv_0.7.5-1em1_all.deb
        Description : traduction sv pour qof (tdeb)

       reprepro a besoin egalement d'une facon de manipuler des fichiers .tdeb et .changes.
        reprepro -b /opt/reprepro/locale/ include unstable ../qof_0.7.5-1em1_arm.changes
        'qof-locale-id_0.7.5-1em1_arm.tdeb' is not .deb or .udeb!
        There have been errors!

       Pour que le fichier de regles debian (debian/rules) dans le paquet source cree soit
       utilisable, em_installtdeb doit etre fractionne de sorte que dpkg-buildpackage recoive les
       donnees correctes pour creer un fichier .changes utilisable car em_installtdeb est trop
       efficace en nettoyant derriere lui-meme.

boutisme (X endianness X)

       Avant la version 3.0.0, les paquets Emdebian utilisaient des TDebs dependants de
       l'architecture mais cela c'est avere inutile, les TDebs sont maintenant independants de
       l'architecture en utilisant l'enveloppe gettext interne.

Autres traductions

       Les paquets peuvent aussi contenir des pages de manuel traduites et des traductions pour
       des templates debconf. Ces traductions ne sont pas empaquetees ou traitees par
       em_installtdeb car Emdebian n'a pas besoin de manipuler de tels fichiers et parce que
       chaque variante necessiterait une prise en charge specifique (la majorite de la prise en
       charge de debconf est deja disponible). Si les Tdebs doivent etre geres dans Debian, ces
       problemes devront etre resolus de facon a ce qu'Emdebian puisse continuer d'empaqueter
       seulement les traductions gettext, en omettant les pages de manuel traduites et en
       laissant la gestion des traductions debconf aux outils existants.

Utilisation de debhelper::init

       Le probleme avec init est que $dh{DOPACKAGES} fonctionne a partir de debian/control mais
       que les paquets de localisation ne sont pas *dans* debian/control. Donc em_installtdeb
       recupere le nom du paquet X Source: X pour l'utiliser comme un prefixe pour le nom du
       paquet de localisation.

Mode traducteur

       Ceci est un mode special, pas quelque chose que delhelper ferait couramment. Dans le mode
       traducteur, debian/rules n'est pas utilisee. em_installtdeb fait tout ce qui est
       necessaire pour configurer, construire, installer et empaqueter le tdeb demande et le
       paquet source tdeb approprie en utilisant un repertoire temporaire pour s'assurer que le
       fichier de controle et le changelog soient disponibles.

       Il y a quelques problemes avec cette methode X la construction a besoin d'un changelog
       debian (debian/changelog) mais a besoin aussi de creer la traduction comme un paquet natif
       (pour eviter le besoin d'un fichier .diff.gz vide) meme si le paquet amont n'est pas
       natif. La solution actuelle est de creer une nouvelle version (avec le tdeb annexe) pour
       creer une entree changelog propre qui n'essaye pas de refermer les bogues du fichier
       originalement telecharge et qui ensuite utilise cette version pour forcer dpkg-source a
       traiter le tdeb source en tant que paquet natif. Ceci pourrait changer a l'avenir mais de
       tels changements ont probablement besoin d'etre geres par dpkg. Cette methode, bien que
       non ideale, fonctionne avec la facon de faire actuellement. Utiliser une version modifiee
       garantit aussi que les fichiers produits n'interferent pas avec les autres constructions
       qui sont au meme endroit. Bien qu'inutilise, un fichier debian/rules est ajoute.

       Si DEBSIGN_KEYID est defini, em_installtdeb essaye d'utiliser debsign pour signer les
       fichiers .tdeb.changes et .dsc. Ceci pourrait etre rendu facultatif si on decide plus tard
       que les envois de traduction auront besoin de l'ensemble des entrees changelog pour fermer
       les bogues dans le BTS Debian. Une partie de l'attrait des tdebs est due au fait que les
       bogues i18n n'auront normalement pas besoin d'etre renseignes dans le BTS.