Costruire un sito con supporto di internalizzazione

Question

Costruire un sito con supporto di internalizzazione

#1 da (3 voti)

0

Quando un utente naviga in una pagina e poi cambia una lingua, dovrebbero verificarsi le seguenti azioni:

Se c'è una traduzione per una pagina che sta navigando ora, quindi reindirizza a quella pagina.
Se non c'è una versione tradotta di quella pagina, quindi esegui il reindirizzamento a una home page.

Quindi, ad esempio, un utente sfoglia la pagina /about-us , quindi passa alla lingua tedesca, quindi deve essere reindirizzato a /uber-uns se esiste una traduzione di /about-us in tedesco.

Attualmente ho una struttura come questa,

CREATE TABLE 'pages' (

  'id' INT NOT NULL PRIMARY KEY AUTO_INCREMENT
  'language' varchar(3),
  'urlSegment' varchar(250), 
  'content' TEXT

) DEFAULT CHARSET=UTF8;

Quali relazioni / colonne dovrebbero essere aggiunte per ottenerlo?

mysql internationalization

posta Yang 21.02.2014 - 12:46

fonte

1 risposta

Leggi altre domande sui tag mysql internationalization

Come incapsulare i parametri del metodo in Java? Passa / seleziona caso ecc. rispetto a If ... ElseIf ... Else [duplicate]

score 3 · Accepted Answer

Vorrei provare a spiegare a chi è venuta l'idea di slug URL localizzati che sarà piuttosto difficile da mantenere. Man mano che il sito si ingrandisce e viene tradotto in più lingue, è probabile che incontriate parole simili o uguali in diverse lingue e quindi avrete problemi a trovare URL univoci, senza contare che sarà difficile per il web master per trovare la pagina tradotta corrispondente ad un originale. Perché inevitabilmente il webmaster non capirà tutte le lingue.

Quindi la mia raccomandazione è di usare /en/about-us , /de/about-us , /fr/about-us , /zh_CN/about-us ecc. In questo modo:

non hanno bisogno di relazioni extra e
puoi vedere rapidamente quale pagina corrisponde a quale

D'altra parte se insisti sugli URL localizzati, tutto ciò che devi veramente aggiungere è una colonna enUrlSegment (indicizzata correttamente). O ID numerico, che è un po 'più efficiente, ma un po' più difficile da lavorare, poiché devi sempre selezionare il segmento URL inglese per qualsiasi tipo di interfaccia amministrativa.

Anche in questo caso, ti consiglio comunque di avere /en/about-us , /de/uber-uns ecc. per evitare potenziali problemi con le stesse parole in più lingue.

Ovviamente questa è davvero la parte facile, il supporto per più lingue o l'internazionalizzazione (i18n). La parte difficile è mantenere tutte le traduzioni sincronizzate, la localizzazione (l10n). Posso consigliare di suddividere le pagine in paragrafi utilizzando html2po da Traduci Toolkit e utilizza uno dei tanti strumenti disponibili per il formato po per la traduzione. In questo modo, quando il copywriter modifica la versione principale, esegui semplicemente gli strumenti, i traduttori vedranno esattamente i paragrafi modificati e eseguirai nuovamente gli strumenti e otterrai versioni tradotte esattamente corrispondenti alla versione principale.