2010-10-28 10 views
5

Sto sviluppando un sito di social networking di nicchia che sta diventando multilingue. Ciò significa che la nostra struttura URL corrente avrà presto bisogno di iniziare a utilizzare parole tradotte per lumache come la seguente:Il modo migliore per ottenere URL multilingue?

www.example.com/home diventa www.example.com/inicio

www.example.com/profile diventa www.example.com/perfil

www.example.com/help diventa www.example.com/ayuda

E così via. La mia domanda è: qual è il modo migliore per supportarlo in un'applicazione PHP? Per le richieste in entrata, ho pensato che un dizionario come il seguente nel mio file router.php sarebbe sufficiente:

<?php 
$request = explode("/", trim($_SERVER['REQUEST_URI'], "/")); 

// Dictionaries of page slugs. 
$slugs = array(
    'es' => array(
     'inicio' => 'home', 
     'perfil' => 'profile', 
     'ayuda' => 'help', 
    ) 
    // additional languages can be added here 
); 

// Rewrite any incoming (foreign) requests 
if ($host=="www.example.es") { // to be made programmatic 
    $lang = "es"; // pick up from locale constant rather being hard-coded 
    if (array_key_exists($request[0], $slugs[$lang])) { 
     $request[0] = $slugs[$lang][$request[0]]; 
    } 
} 

... 

Quale è quasi esclusivamente segmenti di URL e li abbina contro un contro-parte in inglese, se esiste. In caso contrario, procederà normalmente e molto probabilmente causerà un 404 poiché un controller non esiste per il segmento URL.

Nonostante queste parole, ho bisogno che sia compatibile anche con le versioni precedenti. Ad esempio, quando si costruiscono URL nella mia applicazione.

Naturalmente, poiché l'applicazione è solo inglese al momento, questi sono solo hardcoded. Così dicono, quando va a prendere un oggetto User ho effettuare le seguenti operazioni:

<?php 
class User { 

    function __construct($id) { 
     // fetch user details 
     $this->profile_url = ROOT . "/profile/" . $this->username; 
    } 
} 

Qual è il metodo migliore per sostituire le istanze di "/profile/" essere hard-coded per ottenere la versione tradotta, vale a dire "/perfil/" nel sito spagnolo?

+0

Si sta utilizzando un certo tipo di framework PHP, o si tratta di un sistema di auto codificato? – mth

+0

Al momento della traduzione, di solito scelgo di memorizzare effettivamente le pagine in un database, facendo riferimento a esse tramite id o nome interno, e trasformandole in oggetti completi con metodi come 'getUrl()' che possono essere localizzati. – Wrikken

+0

I frammenti di percorso tradotti sono molto rari. Il mio istinto è di evitare di renderlo troppo flessibile. – mario

risposta

1

Ho qualcosa di simile in un'applicazione che sto sviluppando.

Ogni pagina ha un ID univoco che è abbinato a una lumaca, titolo della pagina, meta descrizione e tale per ogni lingua in una tabella.

Per quanto riguarda le persone che dicono che non è una pratica standard e non preoccuparsi di ciò, non sono d'accordo sul fatto che avere URL ben tradotti può aiutare il SEO in diverse lingue.

+0

Esattamente il mio ragionamento. Grazie per il tuo contributo. –

1

Bene, uno schema comune che ho visto per php è creare un file php per ogni lingua e inizializzare un dizionario di grandi dimensioni in cui le chiavi sono le stesse per tutte le lingue.

Avere una variabile di sessione denominata lingua che può inizialmente essere 'en' per l'inglese (o qualsiasi altra cosa si preferisca), e quindi includere usando il comando "include (lingua. '/main.php');" in cui hai una cartella chiamata 'en' che contiene tutti i file php da includere per le traduzioni. Se il main diventa troppo grande, puoi suddividere e includere qualsiasi traduzione che soddisfi le tue esigenze (ad esempio un /en/forum.php per le traduzioni dei forum e un /en/blob.php per le traduzioni in prima pagina).

Ha l'enorme vantaggio di essere flessibile e consente di controllare la lingua semplicemente modificando una variabile di sessione. Puoi persino fare trucchi come rilevare le impostazioni della lingua del browser e assegnare una lingua in base a quella se non è stata già definita piuttosto che renderla semplicemente inglese.

+0

Sì. Spero di utilizzare una variabile locale o una costante insieme a 'gettext' per determinare quale contenuto della lingua e URL invocare. –

+0

Penso che la chiave qui sia che non devi preoccuparti dell'URL. Il cambio di lingua/roba di caricamento viene gestito sul server. –

1

potrei sempre sbagliarmi, ma qui va ...

Il metodo standard per realizzare siti web multilingue è quello di utilizzare le tecniche dizionario i18n/modello in cui si dispone di un dizionario per ogni lingua, e in alcuni casi diversi modelli.

Tuttavia, in tali casi, non ho mai visto nessuno cambiare la lingua dei loro URL. La mappa dell'URL richiede ai file sul disco del server (in generale), e lì per non dovrebbe cambiare in base alla lingua se è possibile evitarlo.

E 'comune prefisso sezione 'percorso' del tuo URL con la lingua si richiede - vale a dire: http://foo.bar/en-us/foobar.html

In sintesi: Io non mi preoccuperei traducendo i tuoi URL come esso isn è una pratica standard (almeno, non quella che ho visto). Inserisci semplicemente il "percorso" dell'URL con una denotazione della lingua come nell'URL sopra.

+0

Non sarebbe una lingua * annunciatore *? : P –

+0

In effetti sarebbe, anche se penso che la "denotazione" sia un sinonimo migliore. L'ho corretto sopra. – Craige

0

Stavo pensando a questo, mentre sto percorrendo questa strada ora. Stavo per usare un metodo simile, ma non lo stesso ...

Stavo per avere i file "include" della lingua con tutte le stringhe del sito. Quindi ...

/languages/en.php

avrebbe tutte le corde giuste per la lingua inglese, e gli altri file di lingua potrebbe essere lasciato cadere come sono fatte nuove traduzioni.

Nel file en.php, stavo andando a mettere in campi come questo

define('PageTitleWelcomeMessage', 'Welcome to Foo'); 

E poi chiamare quella variabile statica in qualsiasi parte del sito. La lingua it sarebbe definito nel loro profilo

ho potuto quindi chiamare tale variabile in questo modo:

echo PageTitleWelcomeMessage;