Come Adapter per Zend_Translate prediligo gettext, con Poedit si lavora molto bene!

In fase di deploy di un’applicazione, dopo aver tradotto i miei file, mi sono accorto che mancavano le traduzioni dei messaggi di errore di Zend_Validate (Alpha, EmailAddress, StringLength, ecc.). Dopo un po’ di ricerche ho scoperto che esiste una directory resources/languages (solo nella versione full di ZF) in cui risiedono tutti i file con le traduzioni dei suddetti messaggi di errore.

Il file però presenta le traduzioni in un array e quindi ho dovuto generare un testo da integrare nel file .po
Per fare ciò ho utilizzato queste semplici 2 righe di codice:

foreach($myAr AS $en => $it)
{
echo ‘msgid “‘ . $en . “\”\n”;
echo ‘msgstr “‘ . $it . “\”\n”;
echo “\n”;
}

Dove ovviamente $myAr è l’array che trovate nei vari file di traduzioni (i file si chiamano Zend_Validate.php).
Ho creato così un nuovo Catalogo di Poedit, poi l’ho aperto con un Editor di testo e ho incollato dentro il risultato visualizzato nel browser dalla suddetta procedura. Aprendolo con Poedit e salvando il gioco è fatto!

Potreste incontrare problemi (a seconda del SO e dell’Editor che usate) sulla codifica dei file. A me, ad esempio, Poedit è andato in errore perchè il file, una volta salvato con l’Editor, aveva perso la codifica UTF-8. Per fortuna l’editor del Mac (TextEdit) permette di scegliere la codifica in fase di salvataggio. Ripristinato l’UTF-8 tutto è filato liscio.

Esistono diversi metodi comunque per convertire la codifica dei file di testo (UTF-8).

E’ da ieri che sbatto la testa su questo problema!
Sul mio server di sviluppo tutto ok, nessun problema. In ambiente di produzione invece riscontro un problema col quoting dei campi passati dalle form create con Zend_Form. Appena aggiungo le virgolette (“) la procedura di salvataggio dati me li quota (\”) e non capivo il perchè!

Il problema sta nell’impostazione magic_quotes_gpc del PHP.
Sul server in produzione infatti questo è settato a On. Ecco la differenza tra l’ambiente di sviluppo (su cui è Off, infatti monta PHP 5.3.x) e quello in produzione (PHP 5.2.x). A questo punto le alternative per risolvere il problema sono diverse.

Una soluzione è disabilitare tale impostazione via file .htaccess inserendo in questo file la riga:

php_flag magic_quotes_gpc Off

In alternativa, ove questo non sia possibile, consiglio l’utilizzo dell’ottimo Filter_StripSlashes creato e descritto da Phil Brown.

Lavoro in ambiente OSX e uso Eclipse per scrivere codice e SmartSVN come client Subversion.
Avevo necessità di aprire un vecchio progetto (proveniente da macchina Windows) di un copia in locale prima di effettuare operazioni sul repository. Ho provato a fare un Relocate della copia locale in modo da poterlo poi sincronizzare con il repository ma ho ricevuto questo errore:

Relocate: Cannot rename file ‘/project/css/.svn/tmp/entries’ to ‘/project/css/. svn/entries’

La soluzione ai miei problemi l’ho trovata su StackOverflow dove si legge:

If you’re changing workspaces on OS X and you import an SVN-based project into your new workspace, some of your files may have the uchg flag set. SubClipse/SVN will not be able to update this project.

Effettivamente le cose stavano così anche nel mio caso e per sistemare correttamente il flag uchg (“user immutable flag“) basta dare il comando (al livello più alto della directory del progetto) da riga di comando:

chflags -R nouchg .

Ho aggiornato la classe PgConsTriv che implementa una serie di metodi utili alla realizzazione di siti e-commerce che necessitano di interfacciarsi al Payment Gateway del Consorzio Triveneto S.p.A.

La gestione multi lingua era un po’ ostica e ho preferito metterci mano risolvendo il problema a monte. Dalla nuova versione (Rel. 1.3) in poi la lingua verrà passata direttamente secondo i codici standard della codifica ISO 639-1.

La piattaforma del Payment Gateway accetta un codice (langid) per impostare la lingua con cui verrà visualizzata la HPP al Cardholder. I codici consentiti (come da Documentazione) sono:

• ITA = Italiano
• USA = Inglese
• FRA = Francese
• DEU = Tedesco
• ESP = Spagnolo
• SLO = Sloveno

Io invece preferisco l’utilizzo dei codici standard secondo la codifica ISO 639-1. A questo punto le due cose cozzavano e quindi ho messo mano alla classe. Ora il parametro dovrà essere passato secondo la codifica standard (it, en, fr, de, es, sl) e non quella del PG qui sopra. La classe (tramite l’array $arLingue – proprietà della classe) converte poi il valore automaticamente quando deve essere passato al PG.

Già che c’ero ho rinominato i file (classe e file di configurazione). Mi sono trovato ad installarlo su Zend Framework e c’erano troppi underscore e meno di troppo!