faretesto > comp.www.* > comp.www.php

^Bart (15.06.2019, 22:52)
Salve,

vi spiego brevemente il problema, ipotizziamo un database di un libro di
ricette in cui ogni ricetta deve avere gli ingredienti tradotti in "x"
lingue.

Ho ipotizzato di crearmi una tabella principale di ingredienti in lingua
inglese ed un altra più generica con tutte le lingua da associare con
una FK alla main table in inglese:

engtable
----------
ID NAME
1 milk
2 bread
3 water

alllangtable
-----------------------------
ID LANG NAME FK_id_engtable
1 ita latte 1
2 ita pane 2
3 ita acqua 3
4 spa leche 1
5 spa pan 2
6 spa agua 3

Con questa soluzione non ci si sbaglia perché voglio una completa
corrispondenza con l'inglese e con le FK non si sfugge, a marzo una
risposta nel n.g. è stata quella di crearmi una tabella singola con
tutte le lingue inglese completo e formare una "internal key" verso gli
ingredienti in inglese ma si rischiavamo casini senza una vera e propria FK.

Una teacher di php/mysql mi ha consigliato di crearmi dei file esterni
per le lingue ma non ho ben capito a cosa si riferisse e soprattutto se
voi reputaste tale scelta, in base al problema, vincente.

Saluti!
^Bart
bramante (16.06.2019, 22:28)
Il 15/06/19 22:52, ^Bart ha scritto:
[..]
> voi reputaste tale scelta, in base al problema, vincente.
> Saluti!
> ^Bart


A mio avviso ti ha consigliato bene. puoi crearti dei file .po (tramite
ad esempio poedit) e leggerli tramite gettext


prendi la lingua dall'url e carichi il file corretto.

esempio




ecc..

sai perfettamente che se l'url non contiene la lingua è in inglese
altrimenti carichi il file corrispondente it.po, de.po ecc

all'interno dell'applicazione setti il locale con la lingua caricata

ancora più complesso ma ancor meglio ed è quello che ho fatto per una
mia applicazione è prendere la lingua del browser

$lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2)

e caricare il file .po corrispondente, se non è presente prendi l'IP del
browser e cerchi in quale nazione è l'IP

(tramite una chiamata API)

, altrimenti imposto l'inglese come default, con la facoltà di scegliere
la lingua da un menù.

Ciao
Ammammata (17.06.2019, 09:03)
Il giorno Sun 16 Jun 2019 10:28:50p, *bramante* ha inviato su
it.comp. il messaggio news:qe68q0$1l2a$1. Vediamo
cosa ha scritto:

> ancora più complesso ma ancor meglio ed è quello che ho fatto per una
> mia applicazione è prendere la lingua del browser
> $lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2)
> e caricare il file .po corrispondente, se non è presente prendi l'IP del
> browser e cerchi in quale nazione è l'IP
> (tramite una chiamata API)


quella dell'IP è una cagata pazzesca, quando sono in svizzera mi arriva
tutto in tedesco perché l'italiano è considerato meno dello swahili e i
siti vanno secchi e diretti sul crucchese, senza nemmeno porsi la domanda
su quale delle QUATTRO lingue ufficiali debba essere usata, fottesega che
abbia il computer installato in inglese con tutte le applicazioni in
inglese e i regional settings in inglese giusto per fargli venire un dubbio

pensa che bello se mentre sono in vacanza in thailandia e cerco un albergo
o un taxi mi vengono date tutte risposte in geroglifici orientali

la cosa giusta è: lingua del sistema = lingua da cercare/proporre punto
se uno vuole cose diverse deve essere il sito a offrire la scelta oppure
l'utente cambia la lingua del sistema al volo

....e non voglio dover sottoscrivere per forza un account google per poter
memorizzare le mie scelte (che tanto poi non le rispetta nemmeno google
stesso)
Alessandro Pellizzari (17.06.2019, 11:07)
On 15/06/2019 21:52, ^Bart wrote:

> Una teacher di php/mysql mi ha consigliato di crearmi dei file esterni
> per le lingue ma non ho ben capito a cosa si riferisse e soprattutto se
> voi reputaste tale scelta, in base al problema, vincente.


Pessima idea, secondo me, visto il tipo di applicazione che stai facendo.

I file .po sono ottimi per tradurre le interfacce, perché, oltre ad
avere ottime prestazioni (sono "precompilati") hanno un ottimo supporto
per i plurali, e ci sono applicazioni che aiutano i traduttori a tradurli.

Ma tu stai facendo un sito di ricette. Si presume che gli ingredienti
possano cambiare costantemente, e possano arrivare nuove traduzioni in
qualsiasi momento.

Usando file esterni dovresti rifare il deploy dell'applicazione a ogni
minima modifica.

Bye.
bramante (17.06.2019, 21:53)
Il 17/06/19 09:03, Ammammata ha scritto:
[..]
> ...e non voglio dover sottoscrivere per forza un account google per poter
> memorizzare le mie scelte (che tanto poi non le rispetta nemmeno google
> stesso)


quella dell'ip nell'applicazione che ho sviluppato viene come seconda
opzione
la prima è la lingua del browser, se l'applicazione non ha il file po
corrispondente cerca l'ip da dove si connette l'utente e cerca il
relativo po, se non lo trova allora imposta l'inglese come default.

Se tu hai il browser in italiano, e il sito gestisce il file po italiano
lo carica altrimenti presume che se ti colleghi dalla svizzera tu sia
svizzero e prende l'ip del provider che al 90% (ci abito) sarà nella
svizzera tedesca.

PS
in quei casi setto il browser in inglese (3 click nelle impostazioni) e
vivo felice.

PPS
la lingua del sistema operativo un applicazione web non può
intercettarla a meno di bucare la sandbox del browser

Saluti
^Bart (22.06.2019, 18:09)
> Pessima idea, secondo me, visto il tipo di applicazione che stai facendo.
> I file .po sono ottimi per tradurre le interfacce, perché, oltre ad
> avere ottime prestazioni (sono "precompilati") hanno un ottimo supporto
> per i plurali, e ci sono applicazioni che aiutano i traduttori a tradurli.


Avendo "studiato" il discorso dei file *.po ho capito anch'io che l'idea
(per questo specifico lavoro eh!) risulta pessima!

> Ma tu stai facendo un sito di ricette. Si presume che gli ingredienti
> possano cambiare costantemente, e possano arrivare nuove traduzioni in
> qualsiasi momento.


Esatto, la mia idea è quella di creare una tabella "mainlanguage" dove
tutti gli ingredienti sono in inglese, la tabella "recipes" punta per
leggere gli ingredienti con una FK verso "mainlanguage" morale della
favola ogni ricetta avrà solo gli ingredienti in inglese.

L'utente quando si registrerà sceglierà la propria lingua e qui viene il
bello ovvero in base alla lingua che sceglie se nella ricetta c'è
scritto milk, onion, etc. lui dovrebbe vedere "in automatico" gli
ingredienti tradotti nella propria lingua!

Per far si che quanto sopra descritto possa accadere ho pensato ad una
terza tabella "allanguages" con le traduzioni degli ingredienti in "x"
lingue che mi interessano collegate in FK verso la mainlanguage in inglese.

Se l'utente è inglese leggerà direttamente gli ingredienti così come
sono nella tabella recipes!

> Usando file esterni dovresti rifare il deploy dell'applicazione a ogni
> minima modifica.


Esatto, come già accennato per il mio specifico problema questa
soluzione non è la migliore!

> Bye.


Saluti.
^Bart
Clayton (08.01.2020, 20:38)
Il 15/06/2019 22:52, ^Bart ha scritto:
> ma si rischiavamo casini senza una vera e propria FK.


casini! quali casini?
la seguente tabella cosa avrebbe che non va?

ID LANG NAME
1 eng milk
2 eng bread
3 eng water
1 ita latte
2 ita pane
3 ita acqua
4 spa leche
5 spa pan
6 spa agua
Ammammata (10.01.2020, 11:55)
Il giorno Wed 08 Jan 2020 07:38:49p, *Clayton* ha inviato su
it.comp. il messaggio news:qv57jn$1qtd$1. Vediamo
cosa ha scritto:

> la seguente tabella cosa avrebbe che non va?


manca una chiave univoca, ma almeno i codici lingua sono corretti



nota però che nell'esempio il latte spagnolo ha codice 4 mentre nelle
altre due lingue ha codice 1 (pane 5-2, acqua 6-3)

immagino sia un errore di copia/incolla o una numerazione automatica fatta
da excel ;)
Clayton (12.01.2020, 16:10)
Il 10/01/2020 10:55, Ammammata ha scritto:
> Il giorno Wed 08 Jan 2020 07:38:49p, *Clayton* ha inviato su
> it.comp. il messaggio news:qv57jn$1qtd$1. Vediamo
> cosa ha scritto:
>> la seguente tabella cosa avrebbe che non va?

> manca una chiave univoca, ma almeno i codici lingua sono corretti


certo, ma la puoi mettere,
la sintassi può variare in base al DB in uso, ma più o meno:

ALTER TABLE database.alllangtable
ADD CONSTRAINT chiave_unica UNIQUE (ID, LANG);

oppure

CREATE UNIQUE INDEX alllangtable_uidx
ON database.alllangtable (ID, LANG);

valuta se meglio il constaint o l'index

>
> nota però che nell'esempio il latte spagnolo ha codice 4 mentre nelle
> altre due lingue ha codice 1 (pane 5-2, acqua 6-3)
> immagino sia un errore di copia/incolla

errore di copia/incolla
Discussioni simili