Questa pagina fornisce informazioni su come far girare un server Pootle, come quelli elencati in PootleServers.
La tua installazione di Pootle dovrà essere sufficientemente flessibile da sostenere il carico delle traduzioni. Se vuoi ospitare molto software (traduzioni multiple di OpenOffice.org / Firefox / o altri progetti grandi), è consigliabile un minimo di:
Comunque se si vuole gestire un set di software con minori traduzioni i requisiti sono minori... Ad esempio, ospitando una sola lingua di 30000 parole (e.g. Mozilla) dovrebbero essere sufficienti le seguenti risorse:
Potresti ospitare lo sviluppo di Pootle? Guarda il nostro resources proposal.
A partire dalla versione 0.9 di Pootle, è necessario il seguente software:
Software opzionale:
Per release ufficiali di Pootle e del translate toolkit, fate riferimento alle pagine di SourceForge : https://sourceforge.net/project/showfiles.php?group_id=91920 . Per jToolkit, vedere http://translate.sourceforge.net/snapshots/
Dalla versione 0.9 di Pootle, è necessario utilizzare translate toolkit con lo stesso numero di versione.
Per versioni di Pootle precedenti alla 0.9 , usate almeno jToolkit versione 0.7.8 (l’ultima versione al momento). Anche le versioni successive funzioneranno. Per versioni precedenti di Pootle, vedere la sezione Older versions.
Su sistemi Linux RPM-based si consiglia di creare rpms e installarli. Scompattare (untar) ed eseguire
./jToolkitSetup.py bdist_rpm
e si otterrà un jToolkit RPM file nella directory dist . Scompattare (untar) ed eseguire
./pootlesetup.py bdist_rpm
per Pootle si otterrà un pootle RPM file in dist. Assicuratevi di non essere loggati come root durante la creazione dei packages, poiché si otterrebbe un errore error: Bad owner/group: .
Sulle altre distribuzioni Linux / Operating Systems, eseguire
./jToolkitSetup.py install
nella directory jToolkit e poi
./pootlesetup.py install
nella Pootle directory. Eseguire
./jToolkitSetup.py --help-commands
e
./pootlesetup.py --help-commands
rispettivamente per vedere un lista di opziioni disponibili quando si creano packages.
Una volta installato Pootle, fate partire il server eseguendo
PootleServer
Eseguire
PootleServer --help
per una lista di parametri a linea di comando.
In caso di difficoltà nell’installazione mandate una email alla lista translate-pootle http://lists.sourceforge.net/lists/listinfo/translate-pootle con i dettagli esatti di ciò che avete fatto e di cosa non funziona. Se possibile, allegate l’output di
PootleServer --version
(presente solo da Pootle 0.9)
Kid e elementtree non sono necessari per versioni di Pootle precedenti alla 0.9.
Pootle, jToolkit e Translate-Toolkit sono in continuo sviluppo, e le seguenti combinazioni dovrebbero funzionare:
Siate attenti che attualmente, per usare translate-toolkit0.8rc6 dovete avere una versione di Pootle0.6.3 precedente alla 20060127, ad esempio:
http://translate.sourceforge.net/snapshots/20060126/.
L’installazione di PyLucene è facoltativa, Pootle funzionerà ancora anche senza questo software. PyLucene usa il software di indicizzazione Lucene . Pootle usa PyLucene per fornire un metodo veloce di indicizzazione dei files PO.
Seguite le istruzioni sulla home page PyLucene downloaded per installarlo.
E’possibile installare Pootle come non-root, ad es. nella home directory o in un’altra directory come /usr/local/. E’ necessario avere accesso alla shell per il Webserver ed essere in contatto con l’amministratore di rete per creare il virtual host (VH) come descritto sotto.
Prima creare il package di installazione bdist . Cioé, eseguire, ./jToolkitSetup.py bdist e ./pootlesetup.py bdist rispettivamente, per jToolkit e Pootle. Packages binari di installazione(in .tar.gz form) saranno creati nella sottocartella dist di ogni programma.
Scompattare i packages nella directory di destinazione. Nel nostro caso era:
$ cd /home/pootle/ $ tar xvfz /home/pootle/POOTLE/jToolkit-0.6.2/dist/jToolkit-0.6.2.tar.gz $ tar xvfz /home/pootle/POOTLE/Pootle-0.6.0.20050518/dist/Pootle-0.6.0.20050518.tar.gz
Lo script PootleServer, che invoca Pootle, viene messo in usr/bin/PootleServer mentre gli altri file vengono posti in usr/lib/python2.3/site-packages/.
Poi, aggiungere usr/bin/ al vostro PATH, e istruire python su dove trovare il codice python jToolkit/Pootle. Se usate bash o sh, eseguite
export PATH=$PATH:/home/pootle/usr/bin/ export PYTHONPATH=/home/pootle/usr/lib/python2.3/site-packages/
o se usate tcsh o csh, eseguite
set -l path = ( $path /home/pootle/usr/bin/ ) setenv PYTHONPATH /home/pootle/usr/lib/python2.3/site-packages/
Ora, eseguite PootleServer per far partire Pootle.
Per iniziare ad usare PootleServer avrete bisogno di alcuni files di configurazione iniziale, che sono pootle.prefs e users.prefs. Nel package di pootle sono disponibili degli esempi con commenti.
E’possibile usare un file pootle.prefs differente utilizzando l’opzione --prefsfile.
PootleServer --prefsfile=/path/to/my/pootle.prefs
Alla prima esecuzione di Pootle dovrete avere almeno un utente con diritti di siteadmin. users.prefs contiene un esempio di utente startup con password startup che ha diritti di siteadmin. Potete abilitare questo utente, scommentando lo startup user nel file. E’ molto importante rimuovere questo utente dopo aver attivato il sito.
{omgs: people not used to python basics (like me) need this extra basic info about the paths used. For instance, if installing pootle as root, the destination directory is not clear. In debian, I’ve found it’s installed under /usr/lib/python2.3/site-packages/. Also, some specific reference stating that the default directory, when no directory is specified, is the installation directory. }
Questo script è per RedHat 7.3, ma l’idea può essere applicata copiando altri service scripts sulla macchina e adattandoli per Pootle.
#!/bin/bash # # /etc/rc.d/init.d/pootle # # Starts the pootle daemon # # Source function library. . /etc/init.d/functions pootledir=/var/www/pootle pidfile=pootle.pid prog="pootlewebserver" test -x $pootledir/$prog || (echo $pootledir/$prog not found - aborting ; exit 0) RETVAL=0 # # See how we were called. # start() { # Check if pootle is already running if [ ! -f /var/lock/subsys/pootle ]; then echo -n $"Starting $prog: " daemon $pootledir/$prog RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/pootle echo fi return $RETVAL } stop() { echo -n $"Stopping $prog: " # killproc $pootledir/$prog # TODO: fix this to use killproc if [ -f $pootledir/$pidfile ] then pid=`<$pootledir/$pidfile` kill -9 $pid success "pootle shutdown" else failure "pootle shutdown" fi rm -f $pootledir/$pidfile RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/pootle echo return $RETVAL } restart() { stop start } reload() { restart } status_at() { local base=pootle local pid # First try "pidof" pid=`ps -eo "%p.%a" | grep pootle.py | grep -v grep | grep ${base} | cut -d. -f1` if [ -n "$pid" ] && grep pootle /proc/$pid/cmdline > /dev/null ; then processcount=`pgrep -P $pid | wc -l | xargs echo` echo $"${base} (pid $pid) is running... ($processcount children)" grep ^Vm /proc return 0 fi # Next try "/var/run/*.pid" files if [ -f $pootledir/$pidfile ] ; then read pid < $pootledir/$pidfile pid2=`ps -p ${pid} -o "%p.%a" | grep pootle | cut -d. -f1` pid2=`echo ${pid2}` if [ "$pid" = "$pid2" ] ; then processcount=`pgrep -P $pid | wc -l | xargs echo` echo $"${base} (pid $pid) is running... ($processcount children)" grep ^Vm /proc/$pid/status return 0 fi if [ -n "$pid" ]; then echo $"${base} dead but pid file exists (pid ${pid})" return 1 fi fi # See if /var/lock/subsys/${base} exists if [ -f /var/lock/subsys/${base} ]; then echo $"${base} dead but subsys locked" return 2 fi echo $"${base} is stopped" return 3 } case "$1" in start) start ;; stop) stop ;; reload|restart) restart ;; condrestart) if [ -f /var/lock/subsys/pootle ]; then restart fi ;; status) status_at ;; *) echo $"Usage: $0 {start|stop|restart|condrestart|status}" exit 1 esac exit $? exit $RETVAL
pootlewebserver mentioned above is a script to trap errors and redirect output, something like this:
#!/bin/bash
traperror() { # don't do anything, just prevent signals from killing the shell script echo trapped error... } export srcpath=/var/www/pootle/src/ export pootlesrc=$srcpath/Pootle/ export controldir=/var/www/pootle/ trap traperror SIGQUIT SIGKILL SIGTERM ( nice -n 1 python $pootlesrc/PootleServer --port 8989 --prefsfile $controldir/pootle.prefs --instance wordforge --htmldir=$pootlesrc/html/ --pidfile=$controldir/pootle.pid --servertype=threaded # --autorestart --maxrequests=500 ) >> $controldir/results.log 2>&1 &
Se usate una distribuzione tipo Debian come Ubuntu, potete utilizzare questo script di start up.
#!bin/bash # /etc/init.d/pootle: start and stop the Pootle Server # Pootle runs as user -pootle- via sudo PREFIX=/vol2 test -x /usr/bin/PootleServer || exit 0 . /lib/lsb/init-functions case "$1" in start) log_begin_msg "Starting Pootle Server..." $PREFIX/bin/start_pootle_iptables /usr/bin/sudo -u pootle $PREFIX/bin/start_pootle & log_end_msg 0 ;; stop) log_begin_msg "Stopping Pootle Server..." $PREFIX/bin/stop_pootle >/dev/null 2>&1 $PREFIX/bin/stop_pootle_iptables >/dev/null 2>&1 log_end_msg 0 ;; restart) log_begin_msg "Stopping Pootle Server..." $PREFIX/bin/stop_pootle >/dev/null 2>&1 log_end_msg 0 log_begin_msg "Starting Pootle Server..." sudo -u pootle $PREFIX/bin/start_pootle & log_end_msg 0 ;; status) $PREFIX/bin/status_pootle ;; *) log_success_msg "Usage: /etc/init.d/pootle {start|stop|restart|status}" exit 1 esac exit 0
$PREFIX=folder where we are placing customized the start, stop, status scripts
Lo script init.d chiama 5 differenti scripts che possono essere personalizzati: start_pootle, stop_pootle, status_pootle, start_pootle_iptables and stop_pootle_iptables. Nell’esempio facciamo partire Pootle come user pootle sulla porta 8081, separando gli errori dal log normale e redirigendo le connessioni dalla porta 80 alla porta 8081
start_pootle:
#!/bin/bash # $PREFIX/bin/start_pootle # Start script in port 8081, separates errors from normal logs /usr/bin/PootleServer --prefsfile=/vol2/etc/0.9.prefs -p 8081 $@ > /vol1/var/log/pootle_`date "+%F_%T"` 2> /vol1/var/log/pootle_`date "+%F_%T"`.err
stop_pootle:
#!/bin/bash # Stop script $PREFIX/bin/stop_pootle # TODO. Use pidof instead? echo "Killing Pootle" pidpootle=`ps -ef |grep PootleServer |grep python | awk '{print $2}'` pidpootle2=`ps -ef |grep start_pootle |grep bin | awk '{print $2}'` kill $pidpootle2 >/dev/null 2>&1 kill $pidpootle >/dev/null 2>&1
status_pootle:
#!/bin/bash # Pootle Status $PREFIX/bin/status_pootle pidpootle=`ps -ef |grep PootleServer |grep python | awk '{print $2}'` if [ "$pidpootle" != "" ] then echo "Pootle Server running in pid ("$pidpootle")" else echo "Pootle Server is not running" fi
start_pootle_iptables:
#!/bin/bash # $PREFIX $PREFIX/bin/start_pootle_iptables # Creates port redirection # /sbin/iptables -t nat -A PREROUTING -i eth+ -p tcp --dport 80 -j REDIRECT --to-port 8081
stop_pootle_iptables:
#!/bin/bash # $PREFIX $PREFIX/bin/stop_pootle_iptables # Deletes port redirection # /sbin/iptables -t nat -D PREROUTING -i eth+ -p tcp --dport 80 -j REDIRECT --to-port 8081
Un server per le traduzioni Pootle `e costituito di contenuto statico and dinamico. Sebbene sia possibile fare in modo che Pootle serva tutti i contenuti (serve almeno quello dinamico), per avere bassa latenza `e meglio fare in modo che Apache fornisca il contenuto che non cambia (statico). Attualmente, per default Pootle pu`o servire tutto il contenuto, a meno che non seguiate questi passi. E’ proprio la bassa latenza che rende le traduzioni piu’ interattivee vi porta ad usare il proxying con Apache.
Per iniziare dovete autorizzare le richieste proxy in proxy.conf (/etc/apache2/mods-enabled/proxy.conf in ubuntu) altrimenti potreste ottenere un sito irraggiungibile : proxy:http://localhost:8080/ in your log files:
<Proxy localhost:8080> Order Allow,Deny Allow from localhost </Proxy>
Qui c’ e’ un esempio httpd.conf per creare un virtual host per Pootle e fare proxy da Apache alla porta di Pootle. Apache dovrebbe essere compilato con mod_proxy.
<VirtualHost *:*> ServerName pootle.wordforge.org ServerAlias pootle.sjsoft.com ServerAlias www.wordforge.org ServerAlias wordforge.org ProxyPass /images ! ProxyPass /js ! ProxyPass /pootle.css ! ProxyPass /favicon.ico ! ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/ <Directory proxy:http://localhost:8080/*> Order deny,allow Allow from all </Directory> ErrorLog logs/pootle-error_log CustomLog logs/pootle-access_log common # Fallback for static html content DocumentRoot "/usr/lib/python2.4/site-packages/Pootle/html/" <Directory "/usr/lib/python2.4/site-packages/Pootle/html/"> Order deny,allow Allow from all </Directory> </VirtualHost>
Se cercate di accedere al contenuto statico, puo’ capitare di ottenere uno strano errore HTTP error 400 (Bad Request). Se capite perch’e accade, saremmo felici di conoscerlo. Attualmente capita su Apache 1.3 (old) e quindi non `e molto importante.
Per creare il file pootle.pot, eseguire il seguente comando nella directory di Pootle:
xgettext --language=Python --keyword=localize --keyword=nlocalize:1,2 --default-domain=pootle --msgid-bugs-address=translate-pootle@lists.sourceforge.net --copyright-holder="Zuza Software Foundation" `find . -name "*.py"`
Questo produrrà un file chiamato pootle.pot, che può essere convertito in un file PO file rinominandolo o eseguendo pot2po da index
Dovrete anche creare un file jToolkit.pot se non ne avete già uno, nella directory in cui è installato jToolkit, eseguite
xgettext --language=Python --keyword=localize --keyword=nlocalize:1,2 --default-domain=jToolkit --msgid-bugs-address=davidf@sjsoft.com --copyright-holder="St James Software" `find . -name "*.py"`
Semplicemente mettete i files PO in un progetto chiamato “pootle”, e un’appropriata directory per le lingua. Potrete tradurre Pootle “dal vivo” - ogni modifica che farete alle traduzioni via Pootle apparirà immediatamente nell’interfaccia. Attualmente è necessatio selezionare la lingua al login.
Dopo aver installato Pootle correttamente, potrete aggiungere il vostro progetto PO. Usate il login administration/administrator per creare la lingua (se necessario) e il progetto. Poi sulle directory “pootle/po” dovrete creare la lingua ed il progetto. Esempio: pootle/po/project/language Nell’ultima directory dovrete mettere i vostri file Po. Solo dopo questa operazione saranno visibili in Pootle.
Se siete un amministratore per un progetto, dovreste vedere un link in cima alla pagina a admin.html (e.g. da/pootle/admin.html) che è la pagina di amministrazione per quel progetto. Questa pagina vi permetterà di settare i diritti di amministratore e altro. E’ possibile anche eseguire questa operazione manualmente:
In po/project/language editate il seguente file pootle-project-language.prefs
# Pootle preferences for project xxx, language xxx rights: default = 'view' nobody = 'view' user = 'view, review, translate, pocompile, assign' admin = 'admin'
Diritti possibili: view suggest translate review archive pocompile assign admin
E’ possibile definire degli obiettivi a livello di language/project. Un obiettivo contiene un sottoinsieme di files e directories del progetto principale. Dovrete avere diritti di amministratore per il language/project per poter definire degli obiettivi.
Cliccate su Mostra Goals e l’ interfaccia vi permettera’ di creare un nuovo obiettivo e aggiungere files a quell’ obiettivo.
Poi dovrete aggiungere le persone a quell’ obiettivo. Selezionate semplicemente l’ utente dalla lista.
Poi potrete assegnare il lavoro da fare all’ interno dell’ obiettivo ai traduttori che appartengono a quell’ obiettivo. Oppure si pu`o fare in modo che Pootle condivida il lavoro fra tutti i traduttori.