[totoo]

Onkelborg Okej, då förstår jag vad du menar. Men det är inget problem jag har, för jag är noga med att ha mallar för allt, så jag behöver aldrig ändra på två ställen, sådana nybörjarmisstag gör jag inte efter alla år.

martine satte absolut huvudet på spiken! Det där var absolut en snygg lösning, snyggare än vad jag trodde fanns! TACK!

Däremot känns det i min värld smidigare att t.ex. nyheterna har ett enskilt objekt i databasen per språk.
Inte att tabellen har fält för varje språk, utan att tabellen ser ut mer såhär

CREATE TABLE nyhet (
id INT,
subject VARCHAR,
lang VARCHAR,
text VARCHAR
)

sedan kör man query i stil med select * from nyhet where lang=$lang - eller var det så du menade? Det känns ju "mer skalbart" (smidigare) att göra så då man slipper skapa nya fält för varje språk.

Nu till en parantes, vad är det för xml-lib ni använder för att få en sån där fin objekthierarki? $rot->barn->barn->wheeo ??

Jag har aldrig parsat xml i just php, så jag tänkte höra om ni använder något vettigt istället för phps inbyggda som känns rörig (jag är van med olika libs från c++ som är rätt rena, typ tinyxml).

[tartareandesire]

Tycker personligen varianten med variabler i separata språkfiler är att föredra då det blir smidigare om möjligheten finns att man senare ska låta andra personer översätta till ytterligare språk. Det blir lättare att se alla ord än i en xml-fil tycker jag. Inget hindrar förstås att man konverterar xml-filer just för detta ändamål men det innebär ju merarbete.

[Daniel.st]

Använd en sida som "master". Varje ytterligare språk är skilda i filer/dbn men har en lösare kopplad relation till mastern för att kunna hålla ihop sidorna i navigeringen osv. Om antalet sidor osv. inte är samma i alla variationer och mastern har man bara relationer till mastern i det fall det går att skapa en logisk sådan.

[allstars]

Originally posted by martine@Oct 10 2007, 01:24
Min lösning (som jag tycker fungerar rätt bra) är att:
1. Använda xml-filer för all statiskt innehåll på sidan, menyer, bakåtknappar, felmeddelanden och
2. Databas språksorterad för dynamiskt innehåll som t.ex. nyheter, artiklar, etc.

Självklart beror det lite på applikationen eller sidan hur man lägger upp det men en enkel lösning är t.ex.

<rubrik>
 <sv>Hej</sv>
 <en>Hello</en>
</rubrik>

då räcker de med att använda t.ex. $xml->rubrik->$lang för att konsekvent sätta språket på alla sidor om man sätter $lang till språket. Databasen kan exempelvis se ut som (med psuedo-sql)[CODE]

Jag är lite nyfiken på hur jag anropar xml-noderna från klassisk ASP till sidan.

Jag hade från början tänkt att använda teknik 2 & 3 tillsammans. Det gjorde jag för en site jag gjorde åt en kund i våras, men det blev lite rörigt med alla statiska meddelanden då jag hade lite ostruktur i språkfilen.
Jag skall snart påbörja en flerspråkig sajt, så det är alltid intressant att få tips.

[martine]

Originally posted by totoo@Oct 10 2007, 07:53
martine satte absolut huvudet på spiken! Det där var absolut en snygg lösning, snyggare än vad jag trodde fanns! TACK!

Däremot känns det i min värld smidigare att t.ex. nyheterna har ett enskilt objekt i databasen per språk.
Inte att tabellen har fält för varje språk, utan att tabellen ser ut mer såhär

…

Jag har aldrig parsat xml i just php, så jag tänkte höra om ni använder något vettigt istället för phps inbyggda som känns rörig (jag är van med olika libs från c++ som är rätt rena, typ tinyxml).

Hur du exakt lägger upp databasen beror förstås på vad du har för material, om alla nyheter alltid översätts till alla språk eller om olika nyheter finns på olika språk osv. Det gäller som vanligt att ha en välstrukturerad (normerad) databas utan redundanta fält.

I php:

$xml = simplexml_load_file('meny.xml');
echo $xml->meny1->rad3->$lang

för att dynamiskt kunna förändra menyn så använder du foreach för att loopa igenom och skriva ut hela menyn t.ex. Titta på phps simplexml-funktioner (php5).

[Onkelborg]

Originally posted by martine@Oct 10 2007, 13:29

Hur du exakt lägger upp databasen beror förstås på vad du har för material, om alla nyheter alltid översätts till alla språk eller om olika nyheter finns på olika språk osv. Det gäller som vanligt att ha en välstrukturerad (normerad) databas utan redundanta fält.

Hm.. Man borde rimligtvis inte ha en kolumn för varje språk någonsin :/

Förslagsvis har man språk, land, en nyckel samt själva texten. språk är helt enkelt språk, land är inte helt fel att ha (t.ex. du kan ha svensk sida, men viss information skiljer sig beroende på om besökaren är bosatt i sverige eller finland.. Eller engelskan, viss information kan mycket väl vara specifik för usa, annan för uk.) Man kan land-kolumnen tom som standard. Nyckeln är någon form av nyckel för vad det är för text bara

[anders.n]

För php gillar jag Smarty Template Engine (smarty.php.net). Då kan man helt skilja kod från layout.

Man skapar en template-mapp som innehåller designen, och kan t.ex. ha olika template-mappar för olika språk.

Sedan läser man in sidinnehåll från en databas (eller direkt från filer om man så vill), och använder Smarty för att "rita ut sidan". Man kan även använda dess cache-funktioner, och loopar på sidan, etc.

t.ex /templates/main_page.tpl

<html>
<head><title>{$title}</title></head>
<body>{include file='left_menu.tpl'}

{$body_content}

</body></html>

sedan... website.php

$language = 'english';
if (isset($_GET['language'])) $language=mysql_real_escape_string($_GET['language']);

// Kolla om den finns i cache... cache_id är per språk.
if (!$smarty->is_cached('main_page.tol', $language))
{ // Finns inte i cache, läs in från databasen...
  $title = read_from_database('index_sida', 'title', $language);
  $content = read_from_database('index_sida', 'content', $language);

  // Sätt värden i Smarty-template
  $smarty->assign('title', $title);
  $smarty->assign('body_content', $content);
}

// Sätt cache till... 24 timmar... (så att den bara behöver ansluta till databasen en gång om dagen för sidan)
$smarty->cache_lifetime = 60 * 60 * 24;

// Visa sidan... antingen från cache eller nyhämtat från databas om den inte var cachad...
$smarty->display('main_page.tpl', $language);

(sådär skulle jag inte koda, och man ska inte ha ofiltrerad input som cache_id, språk som id i databasen, och kunna falla tillbaka till engelska, men.. ;P)

Det jag gillar är att man enkelt kan loopa igenom arrayer och hantera associativa arrayer i templaten, och ha enkel ...

Man kan hämta t.ex. en medlemslista från databasen som en array av associativa arrayer... sedan loopa igenom dem, och i templaten ha typ:

<h1>Lista</h1>
{section name=i loop=$users}
<p>Namn: {$users[i].namn}<br />
Ålder: {$users[i].alder}<br /></p>
{sectionelse}
Finns inga! Tom array!
{/section}

om man skickar den en array som innehåller [ [name => 'kalle', alder=5], [name => 'olle', alder=7 ] (vilket ENKELT kan hämtas direkt från databasen), så får man följande output:

<p>Namn: kalle<br />
Ålder: 5<br /></p>
<p>Namn: olle<br />
Ålder: 7<br /></p>

Sedan kan man ju med hjälp av mod_rewrite och/eller path_info få "snygga" URLer:
www.example.com/english/nice_page_name

Finns naturligtvis många andra befintliga template-klasser för olika språk, men för php har jag av någon anledning fastnat för Smarty.

[Magnus_A]

Oavsett hur man struktuerar sin språkhantering så bör man nog tänka på administrationen så man får en bra överblick över vilka ord/textbitar som motsvarar varandra på respektive språk.
Antar att du har ett "master"-språk och att alla versioner av sajten är översättningar från detta master-språk. Om du då byter text/funktion på knappen "Framåt" till "Bakåt" så måste du kunna överblicka och verifiera att denna ändring översätts och genomförs i alla språkfiler/tabeller/fält.

[danjel]

Som jag planerar att införa på en site är det helt databas drivet,
kom fram till att det bästa för vår situation var ett admingränsnitt där man kan gå in och ändra språken.
Tanken är en admin kan skapa ett "textobjekt", det kan vara en sida eller en meny eller ett mailutskick m.m
Sen kan han skapa ett eller flera "text id " till det objektet..
För varje "text id " kan man sen lägga in en olika översättningar/språk.

Om sedan ett text id heter "header" för en viss sida får man fram rätt språk
genom att anropa en funktion :
Translate("header")

(Det sker ett db anrop per text objekt)