[Python] Localizzazione in python

Gollum1 gollum1.smeagol1 a gmail.com
Mer 15 Maggio 2013 15:36:51 CEST


Il 15 maggio 2013 00:44, Pietro Battiston <me a pietrobattiston.it> ha scritto:
> Il giorno mar, 14/05/2013 alle 22.54 +0200, Gollum1 ha scritto:
>> > Se stai chiedendo "come faccio a sapere qual'è la cartella in cui sono
>> > contenute le traduzioni", beh allora dipende da come hai disposto le
>> > cose _e_ da dove avvii il programma, ovviamente. Io di solito nei miei
>> > programmi metto un file tipo questo, perché funzionano sia quando
>> > installati che dalla cartella dei sorgenti:
>> > http://www.pietrobattiston.it/gitweb?p=gallery-uploader.git/.git;a=blob;f=galleryuploader_lib/config.py
>> > (ignora le righe da 28 a 68).
>>
>> Sì, è proprio questo che intendevo... ti ringrazio del tuo esempio...
>>
>> mi sono copiato le due parti che mi interessano, e poi me le studio
>> con più calma, anche se credo di aver capito come procedere...
>>
>> nel mio caso in cui la funzione che avvia la localizzazione si trova
>> in un modulo separato, e addiritura in una sua directory separata,
>> vuol dire che devo passare la directory del locale come argomento alla
>> funzione (visto che sono in due scope diversi, non hanno le stasse
>> variabili globali).
>>

mi sono studiato il tuo codice, un paio di chiarimenti:

>
> Se ho capito quello che dici, non c'entrano gli scope: devi passare la
> directory del locale _comunque_ perché è quello che richiede la funzione
> locale.bindtextdomain().

e questo diventa palese, a meno che non riesca a far capire in altro
modo alla funzione che ho scritto qual'é il path del chiamante.

>> vedo che hai fatto una distinzione di due situazioni diverse, una per
>> quando stai sviluppando e una per quando la installi nel sistema.
>>
>> Io mi trovo e sto sviluppando per linux, i processi di installazione
>> sono fatti da uno script a parte? quindi in qualche modo sa dove
>> mettere i tuoi file, le tue librerie, i tuoi locales oppure ogniuno si
>> scrive il suo file di installazione (una sorta di makefile presumo)
>> dove decide a modo suo dove mettere le cose? nel primo caso, una volta
>> scritto il programma, è indipendente dal sistema, se l'installazione è
>> demandato ad un installatore standard, a cui passi solo alcuni
>> parametri, nel secondo caso, devi scrivere il tuo script di
>> installazione per ogni situazione e/o sistema operativo...
>>
> Non so dirti quanto siano lecite le mie assunzioni. Io controllo in
> [sys.prefix, path.join( sys.prefix, 'local' )] più la cartella corrente,
> e mi è sempre bastato.

praticamente questa parte posso metterla direttamente nel modulo che
contiene la "libreria", che mi venga passato come argomento della
chiamata, oppure riesca  a sapere in qualche altro modo qual'é il path
del chiamante, posso fare quello che hai scritto localmente nel
modulo.

>
> La "sorta di makefile" di solito si chiama setup.py, e sì, standardizza
> parecchio l'installazione.
>
> Ciò detto, non credo proprio che il mio config.py funzionerebbe sotto
> Windows, neanche con un'installazione standard. Però non dovrebbe essere
> complicato adattarlo.

Non credo che possa funzionare sotto windows, visto che la cartella di
sistema dei locale non è sicuramente /usr/share/locale, però si
potrebbe fare un piccolo workaround per ovviare nel modulo stesso
(come già faccio per capire quale locale usa la macchina, che è
diverso per *nix, OS-X e Win

quindi dal chiamante (o direttamente nei parametri o con qualcosa che
mi dica chi è il chiamante) ho il suo path, nel modulo "calcolo" il
path di sistema, e con il tuo modello posso fare il locale sia nel
caso di installazione che di utilizzo in sviluppo.

va da se che con questo metodo che mi hai suggerito non ho più la
dipendenza del locale da un path relativo, e quindi non dipende dalla
posizione in cui mi trovo quando lancio il programma.

> N.B: la ricerca della cartella "stuff" invece è una convenzione
> puramente mia. In generale,

Bhe nel mio caso lo stuff potrebbe essere la cartella delle librerie,
che è in una cartella separata rispetto ai programmi veri e propri.

> non ti aspettare dal mio codice niente di
> più di un "works for me".

io spero in un work for me too. (il mio inglese è pessimo, lo so).

> L'ho fatto sempre rispondendo a tre soli
> criteri: 1) gira dalla cartella sorgente

e questo è importante anche per me, per lo sviluppo...

> 2) gira sotto Linux dopo il classico "python setup.py install"

idem, ma vorrei in qualche modo slegarmi dal S.O, e forse con il
workaround che ti dicevo prima, in questo caso è possibile.

questa cosa del setup.py diventa parecchio interessante, a livello di
codice per ora posso non preoccuparmene, oppure è necessario tenere in
considerazione qualcosa durante lo sviluppo?

Nel senso, me ne posso occupare quando il mio programma è finito e
voglio cominciare a distribuirlo?

> 3) gira quando installato come pacchetto Debian.

Altra cosa che mi interessa parecchio, visto che lavoro con debian e
vorrei poi distribuire il mio pacchetto principalmente per Debian (ma
non solo).

>
> Forse ci sono soluzioni più pulite.

con python sto scoprendo che ci si può aspettare sempre di tutto...
quindi potrebbe anche essere... se le scopro, te le farò sapere.

> ciao

Grazie delle info.

Byez
--
Gollum1
Tesssssoro, dov'é il mio tessssoro...


Maggiori informazioni sulla lista Python