Vous n'êtes pas identifié(e).
Vous avez jamais eu ces ennuyeux messages quand vous lancez apt-get update ? Depuis un moment ça commençait à me courir, surtout que je ne me rappelle jamais la ligne de commande par cœur. J'ai repris des bouts d'un script et j'ai fait ça:
[Clé d'authentification]clés manquantes dans Ubuntu - script
Et puis hier, je me suis dit qu'il y avait bien un script pour faire des fichiers pot (pour les traductions) depuis un shell script. Bon il a disparu mais il en restait encore des traces sur un forum. Je l'ai récupéré et testé, commencé à le modifier un petit peu, enfin c'est pas pour une petite chaîne de caractères de rien du tout dans un "echo", je voulais voir si j'arrivais à faire un fichier pot utilisable, et ce sera (surtout) pour s'en resservir pour d'autres scripts shell dans le futur. Et c'est dans le post suivant:
Re : [Clé d'authentification] clés manquantes dans Ubuntu - script
Ça a encore besoin d'être amélioré, ça marche mais pour le faire fonctionner c'est un peu bizarre. Améliorations bienvenues.
Hors ligne
Su ma debian, je n'ai jamais eu ce genre de messages perso, c'est propre à ubuntu à cause de l'usage de PPA à outrance, la réponse de ton test sur ton lien le prouve bien
gpg: clef 76F09DD6 : clef publique « Launchpad PPA for Mateusz Łukasik » importée
L'ajout de PPA n'a jamais été un gage de stabilité, mais la manie que les gens ont à toujours vouloir la dernière version de tel ou tel logiciels est la plus grande faiblesse d'ubuntu.
Perso je préfère la méthode debian, des paquets moins anciens mais éprouvé, car en réalité seul le navigateur web et les services ayant une ouverture publique ont réellement besoin d'être à jours.
Pour les paquet manquant l'usage d'un dépôt testé -backport est préférable.
Pour ceux qui ont déjà regardé le nombre de PPA présent pour ubuntu se rendent bien compte que c'est un énorme foutoir qui génère à la longue des incompatibilité de version si on en abuse.
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Salut,
Le sujet des PPA est une toute autre discussion. Je m'en venais partager ce script + demander de l'aide pour améliorer le script bashtrans.sh vers lequel j'ai fait un petit détour, qui a des faiblesses, et peut être utiliser pour générer des fichiers de traduction (.po et .pot) pour tout script shell/bash
comportant du texte affiché lors de l'exécution.
Pour ce qui est des PPA, ça ne cause pas de problème si on sait ce qu'on fait. Pour les incompatibilités de version ça m'étonnerait, parce que pour chaque PPA il y a sur la page dédiée une indication des versions pour lesquelles il est destiné. Je te propose deux exemples. Voici un ppa pour Clipgrab, le programme graphique qui permet de télécharger et réencoder des vidéos de youtube ou ailleurs:
https://launchpad.net/~clipgrab-team/+a … ubuntu/ppa
Puis tu regardes cette partie: "Overview of published packages
Published in:" Tu cliques sur le bouton pour avoir le menu déroulant, tu vois les versions pour lequel il est prévu.
Justement, ce que je trouve embêtant avec Debian, c'est que c'est figé, et si on veut utiliser le pinning pour assouplir, c'est très délicat pour conserver une version stable. Alors que avec les PPA il suffit de s'assurer qu'il n'y a pas besoin d'un ou de plusieurs PPA supplémentaires pour obtenir les dépendances (problème qui se produit aussi parfois sous Archlinux avec les PKGBUILD, et idem, sous Archlinux j'utilise beaucoup ce système, cela sans défaillance depuis quand même presque 10 ans).
Voici un autre exemple de PPA:
https://launchpad.net/~starws-box/+arch … eef-player
pareil, il est dispo pour beaucoup de versions, de Oniric à Vivid. Celui-ci est un lecteur audio simple, il a très peu de dépendances, fonctionne bien et il est très léger. Dans ces deux exemples nous avons des programmes disponibles dans notre gestionnaire de paquets, alors qu'ils ne sont pas dans les dépôts Debian et par conséquent pas dans les dépôs Ubuntu non plus. Mais, justement, il pourraient être portés vers les dépôts Debian depuis les PPA ! Il suffirait que quelqu'un poste une ITP et fasse le paquet pour Debian. Ou que quelqu'un poste une ITP et que quelqu'un d'autre l'adopte pour faire le paquet : c'est ce qui s'est passé pour openbox-menu ! Voici mon (très vieux) PPA de openbox-menu:
https://launchpad.net/~meets/+archive/ubuntu/ppa
et là, tu vois bien en cliquant sur le bouton "Published in" qu'il n'est prévu *que* pour la version 12.04 ! …
Cela m'avait pris un temps fou juste pour y arriver, en suivant toutes les instructions de packaging pour Debian. Je passe sur le reste parce que c'est compliqué. Mateusz Łukasik est le développeur Debian en charge du paquet Openbox et de tout ce qui y est associé. Il a vu mon ITP qui avait genre 1 an et a adopté le paquet. Quand j'ai vu la notification, je l'ai contacté et lui ai montré le PPA dont il s'est servi comme base, je me suis chargée de tester ses paquets avant qu'ils soient mis dans sid.
Enfin, les erreurs de clés se produisent également après une simple installation, sans aucun PPA utilisé, il suffit de sélectionner l'un des composants "autres" dans le gestionnaire des sources, ou même sans rien faire, juste parce qu'il y a un bug non corrigé dans la version : j'ai constaté cela depuis plusieurs mois sur la version LTS de 2014. (Bento Trusty en cours de création).
Pour finir, le ppa de Mateusz Łukasik m'apporte une version git de Openbox que je teste dans une de mes installations, car il comporte un patch permettant d'utiliser… xdg-autostart alternativement à python-xdg, si le paquet obsession des dépôts est installé (il l'a mis en recommandé, dans cette version openbox de développement), ce qui m'intéresse tout particulièrement (Cela permet de résoudre le bug des icônes qui apparaissent en double dans la zone de notification). J'en profite pour tester, et signaler des bugs si j'en trouve (et j'en ai trouvé un, qu'il a déjà corrigé après que je lui aie envoyé mon feedback).
Alors, un petit coup de main pour bashtrans ?
PS: /me en mode multitâches
Dernière modification par mélodie (26-04-2015 15:16:04)
Hors ligne
Alors, un petit coup de main pour bashtrans ? :)s
Perso je n'ai pas le même avis sur les PPA car bien souvent on retrouve des tuto à foison ou l'on installe des PPA pour 12.04 sur une 14.04 par exemple.
Sur Arch c'est parfois le cas avec les package build mais certains standard sont respecté ce qui fait que ça reste quand même correct.
Sur debian le seul dépôt que j'utilise c'est celui de mozilla pour le reste contrib et non-free ainsi que backport suffisent.
Pour bashtrans essaye ceci
#!/bin/bash
#
# Build for PCLinuxOS 2010
# By Leiche (kellerleicheorig at aol.com)
# Licence GPL
# Generate pot, and *-language.po files, to translate bash scripts
# Apr Sun 26 2015 modified
Encoding=UTF-8
usage ()
{
echo "No File"
exit 1 #exit script
}
if [ $# -eq 0 ]; then
usage
fi
SCRIPT="$1"
SAVE=$(zenity --file-selection --title "Bash-Script-Translator-Generator" --save)
if [ "$SAVE" = "" ]; then
exit
else
LOCALE=$(grep LC_CTYPE /usr/share/i18n/locales/i18n | tail -1 | awk -F' ' '{print $2}')
bash --dump-po-strings "$SCRIPT" | xgettext -L PO -o "$SAVE".pot -
xterm -e "msginit -l $LOCALE -i $SAVE.pot -o $SAVE-$LOCALE.po"
fi
exit 0
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Perso je n'ai pas le même avis sur les PPA car bien souvent on retrouve des tuto à foison ou l'on installe des PPA pour 12.04 sur une 14.04 par exemple.
Des gens qui écrivent n'importe quoi sur internet on en trouve partout.
Sur Arch c'est parfois le cas avec les package build mais certains standard sont respecté ce qui fait que ça reste quand même correct.
Quels standards ?
Pour faire un paquet pour les PPA on doit signer une charte de conduite, créer une paire de clés GPG si l'on n'en a pas et fournir la clé publique, puis sur le plan technique:
* attraper la documentation Debian, (c'est un jeu de piste, et à la fin sur le chan des dev debian on te dit "non, c'est ça qu'il faut utiliser maintenant !" - mdr - )faire un paquet aussi correct que possible localement, dans un répertoire Build méthode Debian : 25 pages de doc en français quand même ! et une fois que ça ne produit plus d'erreur Lintian critique, - il y a une page spéciale avec la description pour chaque erreur, et puis il y a Qelt aussi (je sais même plus ce que c'est) on peut le copier vers un nouveau répertoire, et de là faire les légères modifications nécessaires pour qu ça soit compatible avec Ubuntu.
* enfin, on peut lancer la commande qui va envoyer le fichier de build vers le dếpôt, lequel va construire un paquet 32 et un paquet 64bits.
Pour mettre un PKGBUILD sur AUR ce n'est pas si compliqué, et même des binaires y sont acceptés. Pas question de ça sur le dépôt PPA.
Sur debian le seul dépôt que j'utilise c'est celui de mozilla pour le reste contrib et non-free ainsi que backport suffisent.
Sur Archlinux (.org), il y a des archers qui disent qu'ils ne font pas de support pour ceux qui emploient AUR, ou même yaourt. Que ce soit l'un ou l'autre, si on prend des risques, on doit savoir ce qu'on fait et pourquoi on le fait.
Sous Debian, il y a les utilisateurs (avancés ou pas), qui ont besoin d'un système stable. Puis pour d'autres utilisateurs il y a les autres versions, puis les backports, puis le pinning, tout cela est bien pour ceux qui le comprennent, sont à l'aise avec. Ce n'est pas mon cas. Cela dit, cela ne me gêne pas d'installer et d'utiliser Debian de temps en temps. (Avec un petit Bento dedans bien sûr. ).
Pour bashtrans essaye ceci
J'ai essayé, il se comporte comme l'autre. (Je l'ai nommé bashtranscoyotus.sh pour l'occasion et pour le distinguer du premier). Il produit les fichiers de traduction aussi bien, mais il ne fait rien si je lui fournis pas le fichier en argument, et il le redemande encore une fois en ouvrant une fenêtre sur le dossier où ils se trouvent l'un et l'autre, une fois qu'il est lancé.
J'espérais qu'il ouvrirait directement le fichier une fois qu'on lui passe l'argument. Ou bien qu'il ouvre la fenêtre, sans avoir à passer l'argument…
Hors ligne
Pour bashtrans tu n'a pas marqué ce que tu voulais exactement dans le post initial, donc je me suis contenté de corriger le code.
Maintenant je sais que tu ne veux pas mettre de fichier en argument, il suffit de lui rajouter un file selection avec zenity.
Essaye ceci:
#!/bin/bash
#
# Build for PCLinuxOS 2010
# By Leiche (kellerleicheorig at aol.com)
# Licence GPL
# Generate pot, and *-language.po files, to translate bash scripts
# Apr Thu 30 2015 modified
Encoding=UTF-8
SCRIPT=$(zenity --file-selection --title "Bash-Script-Translator-Generator")
SAVE=$(zenity --file-selection --title "Bash-Script-Translator-Generator" --save)
LOCALE=$(grep LC_CTYPE /usr/share/i18n/locales/i18n | tail -1 | awk -F' ' '{print $2}')
bash --dump-po-strings "$SCRIPT" | xgettext -L PO -o "$SAVE".pot -
if [ -e "$SAVE".pot ]
then
xterm -e "msginit -l $LOCALE -i $SAVE.pot -o $SAVE-$LOCALE.po"
else
zenity --warning --text="Script do not contain po strings."
fi
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Salut,
Maintenant il ne nécessite plus le fichier en argument. Mais, il le demande deux fois d'affilée, en lançant la fenêtre une seconde fois consécutivement, après que j'aie sélectionné le fichier une première fois.
Autres points:
le script d'origine produit les deux fichiers "getkey.sh.po" et "getkey.sh.pot", ce qui est correct
Le script remanié produit "getkey.sh-LC_CTYPE.po" et "getkey.sh.pot" (pas souhaité)
Le script d'origine produit deux fichiers corrects, à part une chaine de caractères "#, fuzzy" en trop après l'en-tête
Le script remanié ajoute le chemin complet vers le fichier cible dans le fichier pot juste avant la chaine à traduire, ce n'est pas souhaité (c'est commenté, ça peut s'éditer, mais quand même pas souhaité).
Crois-tu possible de l'améliorer encore ?
Hors ligne
Il ne demande pas 2 fois le fichier en argument mais une fois le fichier en argument et une fois le nom du fichier à sauver, si tu sélectionne le même fichier, il va remplacer le fichier ou prendre le même nom comme base.
Ensuite pour l'améliorer il me faudrait un exemple du fichier que tu veux convertir et savoir sur quel distribution tu fait le script car moi je le fais sur une debian.
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Salut,
C'est dans le premier post:
J'ai repris des bouts d'un script et j'ai fait ça:
[Clé d'authentification]clés manquantes dans Ubuntu - script
La seconde version:
[== shell ==]
#!/bin/sh
unset KEYNUMBER
export TEXTDOMAIN=getkey.sh
export TEXTDOMAINDIR="/usr/share/locale"
echo $"Please provide the key signature you want to add?"
read KEY
if [ -n "$KEY" ]; then
KEYNUMBER="-${KEY}"
fi
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com $KEY
Pour le /bin/sh, si /bin/bash est mieux, n'hésite pas à me le dire (je ne me souviens pas de ce que ça fait comme différence dans l'utilisation)
Je souhaite pouvoir l'utiliser sur n'importe quelle distribution. Archlinux, Ubuntu ou autre.
une fois le fichier en argument et une fois le nom du fichier à sauver
Pour simplifier l'opération, sauvegarder automatiquement vers un .pot serait suffisant. Par exemple,
source turlututu.sh → destination automatique → turlututu.pot
(à moins que "turlututu.sh.pot" soit préférable ?)
Dernière modification par mélodie (30-04-2015 15:25:13)
Hors ligne
J'ai pas compris le truc, c'est pas getkey.sh que je dois mettre en argument ? il me crée un retour vide
avec ta version ou la mienne.
Quel script prends-tu en argument ?
Je souhaite pouvoir l'utiliser sur n'importe quelle distribution. Archlinux, Ubuntu ou autre.
Déjà getkey c'est que pour ubuntu, donc je ne pense pas que ce soit ce fichier ou alors c'est uniquement pour ubuntu like et du fait que je teste sur une debian cela ne fonctionne pas ?
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Salut,
Clarifions, tu me demandes un fichier à fournir, pour avoir un exemple. Je te donne le fichier que j'ai sous la main, c'est à dire indeed (anéfé ) getkey.sh qui est fait pour Ubuntu.
Je pourrais essayer de faire un fichier bidon plus universel. L'important, c'est que le script bashtrans traduise les parties d'un script shell qui sont affichée en sortie, ce qu'il fait déjà, et qu'il le fasse avec des étapes compréhensibles (c'est la partie où j'ai besoin d'aide). Voici un fichier plus universel:
breakfast.sh
[== bash ==]
#!/bin/bash
unset BREAKFAST
export TEXTDOMAIN=breakfast.sh
export TEXTDOMAINDIR="/usr/share/locale"
echo $"Please bring me my breakfast I'm hungry man?!"
read BREAKFAST
if [ -n "$BREAKFAST" ]; then
BREAKFASTNUMBER="-${BREAKFAST}"
fi
sudo apt-get install $BREAKFAST
Pour Mandriva, la dernière ligne sera:
sudo rpm -i $BREAKFAST
pour Fedora,
sudo yum install $BREAKFAST // il me semble
Pour Slackare et dérivées
sudo slapt-get $BREAKFAST
Pour NuTyX
sudo cards install $BREAKFAST
Pour Archlinux,
sudo pacman -S $BREAKFAST //enfin j'ai cité Arch
Pour Suse
zypper install $BREAKFAST
…
Hors ligne
C'est plus clair, tu veux traduire les messages derrière les 'echo' en somme.. Je ne vois pas trop a quoi ca va servir de traduire un script bash car, ben c'est un script, et que l'anglais est une convention. A la limite pour des messages ou --title dans zenity ca peut avoir de l'interet pour les gens qui veulent leur message traduits dans leur petite boite de dialogue mais alors autant faire un truc du genre:
#!/bin/bash
LOCALE=`echo ${LANGUAGE} | cut -d: -f2` # sous kali faire un echo $LANGUAGE me retourne fr_BE:fr
case ${LOCALE} in
fr ) MSG="Apportes moi a manger, j'ai faim ?!"
TITLE='Petit dejeuner'
;;
* ) MSG="Please bring me my breakfast I'm hungry man?!"
TITLE='Breakfast'
;;
esacunset BREAKFAST
export TEXTDOMAIN=breakfast.sh
export TEXTDOMAINDIR="/usr/share/locale"#version zenity
#BREAKFAST=`zenity --entry --text "${MSG}" --title "${TITLE}"`#else
echo ${MSG}
read BREAKFAST
if [ -n "$BREAKFAST" ]; then
BREAKFASTNUMBER="-${BREAKFAST}"
fisudo apt-get install $BREAKFAST
Bon j'ai fait un truc simple, ca serait plus complexe avec beaucoup de phrases a traduire.
PS: la commande LOCALE=$(grep LC_CTYPE /usr/share/i18n/locales/i18n | tail -1 | awk -F' ' '{print $2}') sous kali me renvoit juste LC_CTYPE
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-04-25 15:33+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"#: getkey.sh:7
msgid "Please provide the key signature you want to add?"
msgstr ""
Oui je vois, ca serait surtout utile si il y a beaucoup de "echo' dans ton script.. autrement c'est useless
Hors ligne
Salut,
Je ne vois pas pourquoi:
fr ) MSG="Apportes moi a manger, j'ai faim ?!"
TITLE='Petit dejeuner'
;;
* ) MSG="Please bring me my breakfast I'm hungry man?!"
TITLE='Breakfast'
?
Quand on traduit, on part de un fichier dont l'extension est ".pot". Il contient les chaînes à traduire en anglais, grâce à quoi n'en déplaise aux inconditionnels de l'Espéranto, les contributeurs du monde entier peuvent traduire nos chers logiciels libres dans leur langue natale, vu que beaucoup de gens sont bilingue anglais et pas beaucoup de gens sont polyglottes tout ça.
PS: la commande LOCALE=$(grep LC_CTYPE /usr/share/i18n/locales/i18n | tail -1 | awk -F' ' '{print $2}') sous kali me renvoit juste LC_CTYPE
Ici sous Ubuntu 15.04 ça ne renvoie rien. Donc elle ne sert à rien ? o_o
PS: la partie "#
#, fuzzy
msgid ""
msgstr """ dans le header ne sert à rien. Les msgid et msgstr viennent après le header, et le #,fuzzy je l'ai aussi, il ne gène pas mais il n'a rien à y faire non plus.
PS2: j'ai trouvé des infos sur le processus de traduction, si tu es intéressé, http://docs.slackware.com/howtos:misc:i … ll_scripts
Cela dit, un fichier pot je l'ouvre avec poedit, qui produira un po éditable et un mo compilé. Sauf s'il y a des erreurs dans le pot, alors je l'ouvre avec un éditeur classique.
Dernière modification par mélodie (02-05-2015 12:53:09)
Hors ligne
cat /usr/share/i18n/locales/i18n |grep LC_CTYPE |tail -1 |cut -c 10-14
te renvois quoi sur ubuntu ?
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Cela renvoie YPE
PS: voilà le fichier, http://pastebin.fr/39476
Dernière modification par mélodie (02-05-2015 13:04:07)
Hors ligne
lol la commande est mauvaise, il renvois simplement YPE parce que c'est un bout de LC_TYPE.
$ cat /usr/share/i18n/locales/i18n |grep LC_CTYPE |tail -1
END LC_CTYPE
Utiliser des logiciels propriétaires, c'est comme les plats préparés, on est incapable de dire les conservateurs qu'ils contiennent, on dira toujours que c'est bon, mais ça ne remplacera jamais le repas fait maison par sa maman.
]:D #! Crunchbang & Archlinux GNU/Linux User ]:D
Hors ligne
Oui exact,
END LC_CTYPE
Hors ligne