start

Questa pagina fornisce informazioni su come far girare un server Pootle, come quelli elencati in PootleServers.

## Risorse di Sistema

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:

1. almeno 512MB RAM, preferibilmente 1GB o più (con più progetti attivi, Pootle può facilmente utilizzare 300MB diRAM ...)
2. spazio su disco sufficiente per gestire i file PO di tutti i progetti, più qualcosa extra ... (20MB per copia di OpenOffice.org dovrebbe essere OK)
3. un processore con almeno 2GHz

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:

1. 128 MB di RAM (Pootle stesso usa fino a 30MB con questa quantità di dati)
2. 20 MB di spazio su disco
3. un processore da 1GHz in su (più è veloce, meglio è)

Potresti ospitare lo sviluppo di Pootle? Guarda il nostro resources proposal.

# Installazione di Pootle dal codice sorgente

A partire dalla versione 0.9 di Pootle, è necessario il seguente software:

- Translate Toolkit
- jToolkit
- Kid versione 0.9
- ElementTree
- zip

Software opzionale:

- PyLucene (per velocizzare le ricerche)
- apache
- CVS and/or SVN (per l’integrazione al controllo di versione)

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.

- Pootle 0.9.x usa toolkit 0.9.x
- Pootle 0.10 usa toolkit 0.10

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)

## Versioni precedenti

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:

- jToolkit >=0.7.5, Translate Toolkit 0.8, Pootle 0.6.3 (potete usare translate-toolkit-after-0-8 tag dal CVS)
- jToolkit >=0.7.5, Translate Toolkit da CVS HEAD, Pootle da CVS HEAD
- jToolkit 0.7.6, Translate Toolkit da CVS HEAD, Pootle da CVS Pootle-kid-conversion branch (vedi sotto)

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/.

## PyLucene (Optional)

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.

## Installazione come non-root

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.

# File di configurazione iniziale

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.

- pootle.prefs --- contiene le informazioni di configurazione generale per Pootle
- users.prefs --- contiene le info di login degli utenti: nome, hashed password, etc. Questo file è opzionale e se non è presente, le info sull’utente possono essere memorizzate in pootle.prefs. Per comodità di manutenzione è consigliabile avere 2 files separati.

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. }

# Service Script

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

# Proxying attraverso Apache

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.

## Localizzazione di Pootle

##### Creazione di files POT

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"`

##### Installazione delle traduzioni

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.

#### Creazione di Progetti

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.

#### Diritti sui Progetti

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

# Obiettivi

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.