"Jørn Andersen" <jorn@jorna.dk> skrev i en meddelelse
news:hpd5g3588usr8vohqhmda7rtuqi4ihukq4@4ax.com...
Først
Tak for et godt svar.
> Hvis vi snakker om "registrering af forskellige ting. Navne, typer,
> egenskaber, lokationer osv.", som du skriver - dvs. strukturerede data -
> så ville jeg umiddelbart gå efter en database-løsning, som trækker
> teksten direkte ud af databasen. Jeg kan ikke se mogen grund til at gå
> omkring session-variable.
Det er ikke så meget indtastede data jeg er ude efter at få på flere sprog.
Jeg forventer faktisk ikke det vil blive interressant for brugerne.
Hvad jeg derimod gerne vil have på flere sprog er forklaringstekster på
Frontend'en.
Altså f.eks. labels på input felter.
Når jeg overvejer session variabler, er det mest fordi jeg tror det piner
serveren mindre at lave ét stort databasetræk, og lægge hele sproget i
session variabler, end det vil gøre at lave flere mindre træk hver gang en
side skal loades.
For slet ikke at tale om at lave et træk hver gang et ord eller en sætning
skal bruges.
Dette har jeg dog intet belæg for at mene. Det er kun en fornemmelse udfra
erfaringer med hvor lang tid database connect faktisk tager.
> Hvis der er hele "intro-sider" (sider med generelle oplysninger etc.),
> kan man evt. lægge dem i separate filer frem for i en database.
Hmm. Jens Gyldenkærne Clausen foreslår noget lignende tidligere i tråden,
godt nok til asp.net.
Jeg er bare lidt i tvivl om hvorvidt dette er den mest dynamiske løsning.
Det er jo netop disse tekster jeg gerne vil give brugerne mulighed for at
lave i deres egen oversættelse.
Årsagen er selvfølgelig at jeg gerne ser systemet brugt mange forskellige
steder.
Og jeg er altså ikke lige en ørn til Kuala Lumpursk :)
Om der så er nogen der gider have et system som man selv skal oversætte?
Tjae, hvis systemet ellers er godt nok , gør man vel.
> Jeg har aldrig selv lavet applikationer med sprog-styring, men der er i
> hvert fald to problemer, jeg har set på sites, der bruger det:
>
> Det ene er, hvordan det besluttes hvilket sprog der skal benyttes. Her
> er det efter min mening vigtigt, at brugerens eget valg ikke kan
> "over-ride's" af andre inputs. Det kan være fint nok at læse
> accept-language o.l., men hvis først brugeren har foretaget et valg, så
> skal det kun kunne ændres af brugeren.
Helt enig.
Accept-language havde jeg kun tænkt mig at bruge indtil brugeren enten er
identificeret eller har foretaget et valg.
Jeg regner med at registrere brugerens sprogval i DB, og linke det til Login
navnet.
En yderligere mulighed er jo at placere en cookie på klienten, som husker
tidligere valg.
> Jeg synes generelt, at det mindst problematiske er at brugeren starter
> med at vælge sprog på den første side - automatik, som er
> uigennemskuelig for brugeren er generelt af det onde.
God pointe. Den vil jeg forsøge at huske.
> Det andet er: Hvordan håndterer man, at ikke alle oplysninger findes på
> alle sprog? Hvis fx der er mulighed for at vælge dansk, engelsk og tysk,
> så er nogle af "registreringerne" måske kun tilgængelige på ét eller to
> af sprogene. I så fald skal der tages stilling til, om det skal vises på
> et alternativt sprog eller helt udelades.
Du har sådan set ret. Halve oversættelser er noget frygtelig rod.
Som beskrevet tidligere er det dog ikke data/registreringer jeg gerne vil
give mulighed for at oversætte, men kun frontend tekster.
Hvis brugeren så vælger at bruge et sprog som han eller hun kun har oversat
noget af, tillader jeg mig at se som hans eget problem.
Denne halve oversættelse vil kun være tilgængelig for brugeren selv,
eventuelt dennes gruppe eller afdeling hvis der er tale om en superbruger.
I disse tilfælde har jeg regnet med at vise de ikke oversatte tekster på
systemets default sprog.
> Endelig: Jeg tror nogle ting vil være lettere at styre, hvis du skiller
> sprogene synligt ad. I stedet for at styre sprog (usynligt) via en
> session-variabel, så kunne man lægge de forskellige sprog i hvert sin
> mappe (fx. da/, en/, de/ [1]).
Måske. Men så skulle der jo oprettes en helt ny mappe struktur hver gang en
bruger skaber sin egen oversættelse.
Lad os nu antage at jeg er så ufattelig heldig at afsætte 1000 adgange til
systemet, hver med deres egen personlige oversættelse.
I øvrigt vil næsten alt være afhængig af at sessionen ikke timer ud. Der vil
stort set ikke være andet end en login side uden sessionen er i live.
> Det vil fx gøre det muligt at linke separat til registreringer på forsk.
> sprog. Det gør det enklere at adskille "intro-sider". Sprog-valget er
> uafhængigt af session-timeouts osv.
Session timeout har jeg også tænkt mig at gøre brugerspecifik/brugervalgt.
Dog sikkert max 24 timer.
Og som du sikkert kan se af en anden tråd i gruppen, arbejder jeg også lidt
med muligheden for at genoprette tabte sessioner.
> Du kan selvfølgelig stadig bruge den samme database og have det meste af
> din kode i samme (include-) filer, men så have sprog-specifikke ting i
> egne filer og konstanter. Fx kan valuta, faste vendinger etc. gemmes i
> konstanter på de sprog-specifikke sider.
Valuta.
Du godeste. Det havde jeg slet ikke haft i tankerne endnu.
Jeg skal vist til at lede efter nogle webservices som tilbyder valutakurser.
Tak for den reminder.
> [1] Brug fx 2- eller 3-bogstavs ISO-betegnelser:
> <url:
http://www.w3.org/WAI/ER/IG/ert/iso639.htm>
Det har jeg tænk mig at gøre til de pre-installerede oversættelser.
/Erling