---

Jeg er igang med at implementere flere sprog valg på vores hjemmeside og vil
i den forbindelse høre hvad I mener er mest hensigtsmæssigt.


Vi har flere sites med samme indhold, men med forskellige sprog.
Pt er sprogene hardcodet i phpfilerne og det vil vi gerne væk fra, så vi på
sigt kan ændre til et fælles template system og ende med flere sites baseret
på samme filer, med flere sprog.

Jeg havde forestillet mig en fælles database, hvor alle tekststrenge blev
indtastet og hevet ud én gang om dagen og herefter lade php bruge gettext
til at hente de relevante tekststrenge ud (for at minimere database opslag).

Hvordan går I andre ?

// chris

---

On Sun, 28 Apr 2002 18:04:29 +0200, "Chrsitian Bjerre" <no@spam.com>
wrote:

>Jeg er igang med at implementere flere sprog valg på vores hjemmeside og vil
>i den forbindelse høre hvad I mener er mest hensigtsmæssigt.
>
>
>Vi har flere sites med samme indhold, men med forskellige sprog.
>Pt er sprogene hardcodet i phpfilerne og det vil vi gerne væk fra, så vi på
>sigt kan ændre til et fælles template system og ende med flere sites baseret
>på samme filer, med flere sprog.
>
>Jeg havde forestillet mig en fælles database, hvor alle tekststrenge blev
>indtastet og hevet ud én gang om dagen og herefter lade php bruge gettext
>til at hente de relevante tekststrenge ud (for at minimere database opslag).
>
>Hvordan går I andre ?

Jeg har alt tekst skrevet i forskellige filer i en language bibliotek

fx
dansk.lang.php
english.lang.php

i www/side/language biblioteket

Også nå man kan vælge forskellige sprog ja så kører der lige en løkke
som tager filnavne i biblioteket (og sletter .lang.php )

Så har du en option boks med de forskellige sprog, og ja så kan du
enten vælge at sætte en sessions variabel eller en cookie med det
valgte sprog.

Det er min metode. Grunden er fordi jeg ikke har VILDT meget mysql
plads på mit hotel, så derfor den løsning.

---

Chrsitian Bjerre skrev:

> Jeg er igang med at implementere flere sprog valg på vores hjemmeside
> og vil i den forbindelse høre hvad I mener er mest hensigtsmæssigt.

Den metode, jeg bruger, er følgende: Jeg har en funktion ved navn tr(),
der ser således ud:

<?php
function tr($string) {
return ($value = $GLOBALS['text'][$string]) ? $value : $string;
}
?>

Så er der nogle sprogfiler (den relevante sprogfil inkluderes efter at
brugeren/administratoren har valgt sprog), der f.eks. kan se sådan ud:

<?php
$text["This is the headline"] = "Her er overskriften";
$text["This is the body"] = "Her er selve teksten.";
?>

I selve PHP-scriptet skrives al tekst så vha. tr()-funktionen. Et
eksempel:

<?php
echo "<h1>".tr("This is the headline")."</h1>\n";
echo tr("This is the body")."\n";
?>

Fordelen ved den metode er, at sprogfilerne ikke behøver være
opdaterede. Er de ikke opdateret, så vælges standardsproget (her
engelsk) bare.

For at systemet skal køre ordentligt, så skal der laves et program, der
hiver alle forekomster af tr("Noget tekst"); ud af et PHP-script og
danner en sprogfil. Samme program skal også kunne opdatere en
eksisterende sprogfil. Jeg har desværre ikke fået det program lavet
færdigt endnu - og indrømmet; det er da et argument for ikke at bruge
mit system : ) Ikke desto mindre synes jeg, der er mange fordele
alligevel ved ovenstående - bl.a.:

- Det er ikke nødvendigt at bruge en sprogfil, mens man programmerer
scriptet. Al tekst skrives direkte i scriptet som tr("Noget tekst"), og
når så scriptet er færdigt, beder man det program, jeg endnu ikke har
lavet færdigt, om at lave en sprogfil.
- Det kører på alle versioner og udgaver af PHP. Ingen moduler er
nødvendige.
- Sprogfilerne behøver ikke at være opdaterede. Findes der ikke en
oversættelse af en bestemt streng, så viser tr()-funktionen bare
strengen på standardsproget, som normalt vil være engelsk.

--
Jonas Koch Bentzen

Fasdab - nu med ODBC!
http://understroem.dk/fasdab/

---

After I finished the 3 Pan Galactic Gargle Blasters, Jonas Koch
Bentzen <ingen.emailadresse@eksempel.dk> just offered me, he muttered
some weird stuff, and I had to correct this gibberish:

>Så er der nogle sprogfiler (den relevante sprogfil inkluderes efter at
>brugeren/administratoren har valgt sprog), der f.eks. kan se sådan ud:
>
>$text["This is the headline"] = "Her er overskriften";
>$text["This is the body"] = "Her er selve teksten.";

Uden lige at have taget mig tid til at undersøge det:
Findes der nogle tekniske-begrænsninger for denne måde?

Hvad hvis jeg har en tekst der er 300+ linier lang, kan jeg så godt
have et array med denne key?
--
Nano Martin Mouritzen Phone +45 24899896
Vesterbrogade 30C. 2. Programmer Advanced Simplicity
DK-8000 Århus martin@nano.dk http://www.nano.dk
Nano nu officiel dansk distributør af UltraEdit, se mere på websitet

---

On Mon, 29 Apr 2002 01:27:57 +0200, Martin Mouritzen wrote:

> Hvad hvis jeg har en tekst der er 300+ linier lang, kan jeg så godt have
> et array med denne key?

Ja, ligesåvel som der ikke er begrænsninger på længden af arrays.

--
Christian Jørgensen | The difference between theory and practice is that in
http://www.razor.dk | theory there is no difference between theory and
| practice, but in practice there is.

---

Davs

Jeg har lavet mig en klasse som parser en tekstfil med alle mine tekster i
og lægger dem i et associativt array. Filerne ser sårn her ud:

   <id="paragraph_first">
       Her kan der stå noget <strong>vilkårlig</strong> HTML
   </id>
   ...

.... og de kan parses med følgende lille sag:

   $lang_buffer = implode("", file(sprogfil));
   $pattern = "/ <id=\" (\w+) \"> (.*) <\/id> / xsU";
   $matches = array();
   preg_match_all($pattern, $lang_buffer, $matches);
            
Herefter jeg kan sætte dem ind med et kald til en metode a la:

   echo $language->get("paragraph_first");

Fordelen er at man bliver nødt til at konstruere sin sprogfil samtidig med
scriptet, og da get-metoden kalder trigger_error, hvis den ikke kan finde
den ønskede streng, er man sikker på at fange sine fejl med det samme - i
modsætning til Jonas' forslag :)

Når man senere vil oversætte til serbokroatisk tager man bare sprogfilerne
og oversætter dem streng for streng - DET er bare noget der funker :)

--
Thomas Lindgaard
thomas@it-snedkeren.BLACK_HOLE.dk

Fjern det sorte hul hvis du vil sende mig noget

---

Thomas Lindgaard skrev:
>
> Fordelen er at man bliver nødt til at konstruere sin sprogfil samtidig
> med scriptet

Det er da netop en ulempe. Det, der er fedest, er, hvis man kan have en
udviklingsproces, der er næsten lig den, man ville have, hvis man ikke
brugte sprogfiler. Det er muligt med mit system, fordi man skriver
teksten direkte i PHP-scriptet, ikke i sprogfilen. Sprogfilen bliver
først genereret senere, når man har brug for en oversættelse.

> og da get-metoden kalder trigger_error, hvis den ikke
> kan finde den ønskede streng, er man sikker på at fange sine fejl med
> det samme - i modsætning til Jonas' forslag :)

Min funktion kunnne på sådan cirka to sekunder skrives om til at bruge
trigger_error(), hvis en bestemt oversættelse ikke findes : ) Ikke
desto mindre mener jeg netop, det er en kæmpestor fordel, at min
funktion ikke kommer med en fejlmeddelelse, hvis en bestemt streng ikke
er oversat, men i stedet bare viser den engelske tekst. Lad mig give et
eksempel på hvorfor: Jeg har skrevet et open source-program, der er
blevet oversat til 19 forskellige sprog. Når man skriver den slags
programmer, er man jo afhængig af frivillige oversættere fra
forskellige steder i verden, og de oversættere følger ikke altid med -
dvs., de er ikke altid villige til at oversætte nogle få ekstra linjer
hver gang jeg forbedrer programmet og tilføjer nogle få ekstra
tekststrenge. Derfor er det vigtigt, at ens oversættelsessystem selv
falder tilbage til et standardsprog (som regel engelsk), hvis en
bestemt streng ikke findes i oversat stand.

Mht. det med at fange sine fejl: Jeg går ud fra, du dér mener, at man
hurtigt finder ud af, hvis der er nogle strenge, man har glemt at
oversætte. Det er ikke noget problem med mit system - for man kører jo
et program, der genererer eller opdaterer sprogfilerne hver gang, man
skal til at udgive en ny version af sit program. Så kan man jo direkte
i sprogfilen se, om der er nogle strenge, der ikke er blevet oversat.

--
Jonas Koch Bentzen

Fasdab - nu med ODBC!
http://understroem.dk/fasdab/

---

On Mon, 29 Apr 2002 23:28:12 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:


>oversætte. Det er ikke noget problem med mit system - for man kører jo
>et program, der genererer eller opdaterer sprogfilerne hver gang, man
>skal til at udgive en ny version af sit program. Så kan man jo direkte
>i sprogfilen se, om der er nogle strenge, der ikke er blevet oversat.

denne metode har imho også sine begrænsninger... m. mange sprog og
mange paragraffer kan man på et tidspunkt nemt miste overblikket
(imho).

I ordb-sammenhæng hvor vi pt. opererer m. 25 forsk. sprog og en
mulliard paragraffer har vi valgt at smide sprog i en database og så
dertil gnufle div. status-værktøjer m. dertilhørende webinterfaces..
Pr. cron bliver teksterne så smidt fra databasen ud i (semi)-statiske
sprogfiler.

(det er ikke det som er i produktion lige nu, men coming up)

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

Jonas Koch Bentzen <ingen.emailadresse@eksempel.dk> wrote in news:aakdte
$4s5$1@sunsite.dk:

> Jeg har skrevet et open source-program, der er
> blevet oversat til 19 forskellige sprog. Når man skriver den slags
> programmer, er man jo afhængig af frivillige oversættere fra
> forskellige steder i verden, og de oversættere følger ikke altid med -
> dvs., de er ikke altid villige til at oversætte nogle få ekstra linjer
> hver gang jeg forbedrer programmet og tilføjer nogle få ekstra
> tekststrenge.

Her er vi nok uenige behovet for frivillig indsats :) - jeg skal selv
have et site lavet på dansk eller engelsk og her gælder "alt-eller-
intet"-princippet... det går simpelthen ikke at der mangler en streng.
Derfor trigger_error og samtidig skrivning af script og sprogfil.

Men din løsning virker lækker, når man ikke skal aflevere hele "pakker"
ad gangen.

> Mht. det med at fange sine fejl: Jeg går ud fra, du dér mener, at man
> hurtigt finder ud af, hvis der er nogle strenge, man har glemt at
> oversætte. Det er ikke noget problem med mit system - for man kører jo
> et program, der genererer eller opdaterer sprogfilerne hver gang, man
> skal til at udgive en ny version af sit program. Så kan man jo direkte
> i sprogfilen se, om der er nogle strenge, der ikke er blevet oversat.

Dén feature kan jeg godt lide! Det kan være at jeg selv skal rode lidt
med det engang :) - det kan jo være lidt uoverskueligt at have teksten i
en anden fil...

Mvh.
/Thomas

---

On Sun, 28 Apr 2002 18:04:29 +0200, Chrsitian Bjerre wrote:

> Jeg er igang med at implementere flere sprog valg på vores hjemmeside og
> vil i den forbindelse høre hvad I mener er mest hensigtsmæssigt.
>
>
> Vi har flere sites med samme indhold, men med forskellige sprog. Pt er
> sprogene hardcodet i phpfilerne og det vil vi gerne væk fra, så vi på
> sigt kan ændre til et fælles template system og ende med flere sites
> baseret på samme filer, med flere sprog.
>
> Jeg havde forestillet mig en fælles database, hvor alle tekststrenge
> blev indtastet og hevet ud én gang om dagen og herefter lade php bruge
> gettext til at hente de relevante tekststrenge ud (for at minimere
> database opslag).
>
> Hvordan går I andre ?
>
> // chris
Jeg har valgt at implementerer det i et to-dimentionelt assosiativt
array.

f.eks.

$dk = array("headline" => "overskrift", ...);
$de = array("headline" => "überschrift", ...);
$uk = array("headline" => "headline", ...);

$text = array("dk" => $dk, "de" => $de, "uk" => $uk, ...);

En sessionsvariable indeholder det valgte sprog, og korrekt text hentes
sådan:

session_register("sprog");
if (!isset($sprog) {
   $sprog = _DEFAULT_LANGUAGE;
}

echo $text[$sprog]['headline'];

--
Hilsen/Sincerely
Michael Rasmussen

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-------------------------------------------------------------------
Fjern NOSPAM fra min adresse, for at sende mig en mail