Dumt välja statisk webbsidor när man har flera språk?
 

När man har flera språk (eller åtminstone bara /se/ och /en/) så brukar väl multispråks-CMS vara vägen framåt, men visst måste man kunna bygga det också statiskt lite smartare än:


Kan man se till att med htaccess ha regel som letar efter ett /se/ i URL:en, och i så fall skriver ut ett /se/ och hämtar upp en fil som heter t ex index_se.php i stället utan att skriva ut filändelsen?

För i så fall skulle man inte behöva översätta alla sidor direkt, utan default skulle ändå kunna vara att man har index.php på engelska? Så det snarare blir:

Verkar det vettigt, eller bara dumt om man sen skulle vilja inkludera en header.php och en footer.php fil som OCKSÅ skulle vara på endera språket?

....eller tänker jag fel och ska ändå gå på Drupal trots att vi kanske bara har ett 20-tal sidor nu (som ändock kan tänkas växa framgent...)?

Det är bättre om du väljer att ha samma php filer för alla språk och sen läser in språk dynamiskt.
Typ:
<?php
echo translate('text_id1');

?>

Och att du t.ex har en språk fil för varje språk,
ett enkelt sätt är att ha en array med alla text nycklar
array('text_id1' => 'hej', 'text_id2' => 'bla bla')

Det finns även "gettext" som är lite mer avancerat...

Fast olika urler ska det väl vara för olika språk?

Jag gjorde en sida i php med separata språkfiler med variabler (alt arrays). Användarens språk till en variabel "$lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);" och sen en switch med default engelska ifall man inte lagt in språket. Efter det så skickade jag användaren till "header( 'Location: /'.$lang.'/'.$p );". Med $p tom om det inte är en undersida då såklart.
Sen får man ju styra upp med htaccess så indexfilen får rätt variabler och visar rätt sidor samt hämtar rätt språkfiler med variabler (eller arrays). Busenkelt att lägga till fler språk sen (om man har nån som orkar översätta).

Finns säkert lika många idéer som sätt att göra det på :)