Newsgroup: it.comp.www.php
Titolo: Associare caratteristiche identiche a prodotti diversi

Salve,
 
visto che sto postando da qualche giorno tengo a precisare che quello 
che chiedo non è per lavoro ma per chiarirmi le idee a livello tecnico 
per poi affidarmi a dei professionisti che implementeranno il tutto 
evitando di farli smattire con richieste "assurde" o cambiamenti in 
corso d'opera onerosi sotto tutti i punti di vista (...).
 
Nel creare una tabella in mysql ci sarebbe l'esigenza di associare 
caratteristiche simili (pensiamo agli ingredienti dei prodotti che si 
comprano al supermercato) a prodotti diversi.
 
Ad esempio in una tabella potrei inserire i valori "zucchero", "sale", 
"farina", etc. e nel momento in cui inserisco un prodotto dovrei 
associargli/inserire più valori (ovvero più ingredienti) obbligando però 
l'utente a scegliere tra quelli disponibili.
 
Inserire gli ingredienti in un'apposita tabella mi permetterebbe anche 
di tradurli in lingue diverse però credo che non si potrà lavorare a 
livello di db ad esempio con delle FK per avere vincoli di integrità ma 
bisognerà agire direttamente con uno script php che legga e proponga i 
valori della tabella ingredienti.
 
Saluti.
GabrieleMax

 valori della tabella ingredienti.
 
Definisci una tabella di ingredienti come "master language" (di solito 
inglese) e la fai come ho detto sopra.
 
Poi definisci le tabelle di traduzione.
 
create table ingredients(id primary key, name text, description text);
 
create table ingredients_it_IT(id int references ingredients(id), name 
text, description text)
 
Nota che l'id in quella di traduzione non è primary key, nè 
auto_increment: viene assegnata allo stesso valore della tabella 
ingredienti originale.
 
In questo modo puoi avere il fallback della lingua automaticamente:
 
select 
i.id
, 
i.name
, i.description, 
t.name
 as name_it, t.description as 
description_it from ingredients i left join ingredients_it_IT t on 
(
i.id
=
t.id
)
 
Da PHP, se name_it è null, prendi name, e lo stesso con description.
 
Puoi anche fare (left) join multilpe per avere tutte le traduzioni allo 
stesso tempo, ma questo te lo lascio come esercizio per casa. :P
 
Bye.

livello di db
 
Puoi crearti una VIEW ingredienti_locali che, data una lingua, ti mostri un
campo contenente o il nome localizzato o, se non c'è, il nome default dalla
tabella ingredienti.
 
(O puoi usare un file .po adatto al posto di nomi_ingredienti)
 
Leonardo
-- 
 
"You all presumably know why" :-) :-(

 Leonardo
 
Saluti!
GabrieleMax
 

 Bye.
 
Saluti!
GabrieleMax

 
 
Se non li scegli tra gente che passa per caso non hai bisogno di entrare
in questi dettagli. Un sacco di scelte tecniche dipendono troppo dal
progetto. Un esempio sono proprio le traduzioni, che si possono fare in
cinque/sei modi diversi, tutti sensati se rapportati al giusto caso.
 
Prova piuttosto a scrivere, in maniera che consideri perfetta, quello che
vuoi ottenere alla fine. Come tecnico, troppe volte capita di trovare
qualcuno che ti dice come fare questo o quello, ma non sa cosa vuole
di *preciso*.
 
 
Ciao!

di *preciso*.
 
+137


 Ciao!
 
Saluti!
GabrieleMax
 

 Leonardo
 
Saluti.
GabrieleMax

tabella lingua dove inserirò i vari IT, EN, etc. giusto?
 
Sì. Ma come giustamente ricorda fmassei, questo tipo di decisioni è bene se le
lasci al programmatore.
 
Tu preoccupati magari di cose tipo "La mappatura delle lingue deve potersi sia
scaricare facilmente per mandarla al servizio di traduzione, sia uploadare per
l'aggiornamento". Questo può influenzare poi la scelta del sistema da usarsi.
 
Al programmatore vanno dette cose come:
 
	"ogni ingrediente deve poter avere un nome in N lingue, con
	 N che potrebbe aumentare, in un secondo tempo; ma potrebbe
	 anche non averlo, e allora deve usare un nome di default".


 
 
I dati in persistenza dipendono anche dal data-flow, se te o il tuo
programmatore decidete in un secondo momento di usare Ajax per facilitare
gli utenti, puoi buttare sia le pagine che probabilmente parte del tuo db.
 
Per dire.
 
Capisco che vuoi dare una mano anche a livello tecnico, ma secondo me stai
facendo una fatica inutile.
 
Ciao!

 
 
Questo livello di chiarezza purtroppo non ci se lo può aspettare da uno
che non scrive specifiche di mestiere, ma sicuramente è possibile andarci
vicino anche per chi non l'ha mai fatto, con un po' di buona voglia.
 
 
Ciao!

come penso tutti.
 
Dipende anche da come sono manutenute le traduzioni. Se sono aggiornate una
volta ogni tanto è più efficiente gettext - infatti scrivevo,
 
    (O puoi usare un file .po adatto al posto di nomi_ingredienti)
 
- poi uno uploada il file .mo appropriato. Per dare possibilità a un utente
esterno di modificare on line le traduzioni, si potrebbe fare lo stesso (ho
trovato 
https://github.com/phpmo/php.mo
 ), ma il database è più facile. Poi
ti consente più flessibilità, se ti serve (per es., lo stesso messaggio, in
due file diversi, tradotto in modi diversi; che si fa pure con gettext, ma,
a scoprire solo dopo quanto ti serviva, è una faccenda pelosa).
 
Comunque, è vero che si può passare da gettext a database, e viceversa, con
uno sforzo abbastanza ridotto.


 
 
"Ridotto" è da definire... Sul mio progetto attuale, se dovessi cambiare,
sarebbe un bagno di sangue :)
 
Ciao!


Sostituisci _() con _t(), dopo di che... :-)


 
 
Dopo di che devo rivedere tutte le query? :D
Certo, a meno che non vuoi farne mille a pagina, o avere ogni pagina che
carica il tabellone senza motivo...
 
Ciao!

Dopo di che devo rivedere tutte le query? :D
 
Nooo. Ma immagino che se usi gettext tu abbia qualcosa del tipo _('STRING')
più o meno ovunque. A quel punto è relativamente semplice passare a __(), e
quella funzione poi chiamerà il database. A seconda dei casi e di come sono
fatte le stringhe, e quante ce ne sono, può convenire caricare in memoria -
che so - le diecimila stringhe della lingua in uso (diciamo che siano sugli
80 caratteri l'una, vengono circa 800 Kb - in PHP, in realtà, più verso gli
1.2 - 1.5 MB; comunque tutto sommato accettabile) come hash. Oppure fare in
effetti una query per ogni __(). O trasformare _() in __(__FILE__,...), per
effettuare una query meno onerosa (o usare qualcos'altro invece di __FILE__
- la view attiva, per dire).
 
Il viceversa è più semplice, ma AFAIR pure il file .MO viene caricato tutto
in memoria [benché in modo meno memory-intensive] alla prima chiamata.


 
 
Eh, infatti. O fai mille query o carichi sempre il tabellone.
L'ultima alternativa mi sembra mostruosamente complessa da gestire, con
stringhe a caso piazzate qua e la.
 
Ciao!

stringhe a caso piazzate qua e la.
 
Noo, è più la paura che il danno :-)
 
Ammesso di avere una funzione __(prefix, string, [num=1]) che oltre che una
stringa messaggio accetta un prefisso, puoi cercare nella tabella hash
 
	prefix/string
	default/string
	string
 
e ritornare il primo che trovi. Tutta la "complicazione" è in __(), cioè in
un posto solo (per elenchi piccoli, chiaro che $prefix non ti serve).


 
 
Non capisco. La stringa "log in" dove la metti? E "Questa è la pagina dei
contatti"?. E come fa un utente, o il servizio di traduzione, ad aggiornare
i testi? Continua a sembrarmi un casino tremendo.
 
Ciao!

 i testi? Continua a sembrarmi un casino tremendo.
 
Il servizio di traduzione riceve un file TMX, generato dal database: la stessa
LEFT JOIN che mi trova i "default" delle parole non tradotte mi può dire quali
termini non sono tradotti. Poi uploada il file.
 
L'utente in genere non può, ma volendo boh, gli potrei far comparire magari un
cazzibuffo in sovraimpressione sui testi, per non sballare il layout, e se uno
clicca lì sopra (magari solo le parole non tradotte) un prompt gli chiede cosa
suggerisce. Non l'ho mai fatto, eh, e pare un casino anche a me, però in fondo
in fondo in certi casi (utenti seri, autenticati, motivati, bastonabili) non è
una cosa così fuori dal mondo.
 
(Ovviamente potrei farlo anche con gettext, basta installare gettext-utils sul
server).



 
No, penso mi hai risposto: hai un sistema a lato che gestisce le traduzioni
con un formato apposta. Se ce l'hai pronto bene, altrimenti è un sacco di
lavoro in più che devi fare.
 
 
Ciao!

Magari va bene per i tuoi casi, a me non andrebbe tanto bene...
 
Ehi, non sto cercando di convertirti al DB :-) -- io sono convinto che vada
bene per quasi tutti i miei casi (e tollerabilmente per tutti i miei) ma so
che i miei non sono tutti quelli che ci sono.
 
Banalmente se il database magari non c'è - ma anche se ha il profilo di uso
sbagliato, e la mia tabella di stringhe viene buttata fuori "troppo spesso"
dalla cache del server, è chiaro che mi serve qualcos'altro. O, m'immagino,
ennemila altri casi.
 
N'ho viste tante, ma ormai so che non le vedrò mai tutte :-D
