Webside i flere sprog - hvordan gøres det smartest
Jeg overvejer at lave en ny side, der måske en dag skal oversættes til flere sprog. Så er det vel lettest at tænke det ind her fra starten - håber på noget feedback fra jer kloge hoveder derude.
Jeg har overvejet at placerer alle text-filerne i mapper som med navnene da,de,en og lignende. Så inkluderer jeg på hver side /dynamisk-indsat-sprog/forside_top.txt hvor de skal være.
Er det smartere med en database i stedet? Et databasekald eller inklude af fil er vel ikke den store forskel ressourcemæssigt?
Så er jeg bare lidt i tvivl om hvorvidt jeg bør lave én tabel for hver sprog som så indeholder alle felterne med tekst? Her er jeg lidt bange for at det bliver noget rod når jeg så skal indsætte et nyt tekstfelt og så skal oprette det i 5 tabeller?
Jeg forventer at teksten først bliver udfyldt på dansk, hvorefter oversætterne så løbende kan udfylde tomme felter gennem et lille interface der viser den danske version og et felt hvor de kan skrive deres oversættelse.
Nogle tanker for best practise på området? (Det vil blive lavet i PHP, men jeg mener ikke at sproget er afgørende for denne diskussion)
sproget kan i den grad være afgørende - for fx i .NET er sprogstyring indbygget og så slipper man helt for at undersøge det nærmere.
En tabel for hvert sprog vil i hvert fald være en dårlig idé - så skal du tilføje en ny tabel den dag der kommer et nyt sprog til og det er en klar forkert tilgang, det ville derimod handle om at lave én tabel hvori man udover en tekst-værdi gemmer et sprogid. Samme tilgang ville skulle bruges til indhold på siden - skal du fx have artikler ind skal du ikke have en artikel-tabel til hvert sprog men bare én tabel hvor artiklen gemmes sammen med et sprogid.
txt-filer lyder heller ikke så logisk - strukturen i en txt-fil kan aldrig blive lige så logisk som struktureret data i fx en database.
Når det er så statiske data som sprog-tekster ville mit umiddelbart valg være xml-filer. Lidt afhængig af hvor mange ord/sætninger det drejer sig om så enten én fil per sprog - eller én fil per sprog til overordnede ord (fx til menuen) og så en fil pr sprog pr side.
Arne_v: Når man ved at det hedder internationalization er det lidt lettere at finde noget :)
Tak for det, jeg er i fuld gang med læsningen. Jeg synes dog ikke at brugen af arrays i det første eksempel virker helt logisk, men skal nok bare lige læse det igen.
keysersoze: Så tabellen skulle bare indehold felterne id, sprog, text? Formegentlig også noget der identificerer hvor teksten hører til ala 'tekstplacering'.
id, sprog, tekst, tekstplacering (felterne) 1,da,Velkommen til forsiden,Front 2,en,Welcome to our frontpage,Front 3,da,Beklager men der er ikke adgang til databasen, error1 4,en,Sorry but the database is unavailable, error1
Og hver gang der skulle bruges en sætning hiver jeg så noget ud med SELECT tekst WHERE sprog = $sprog AND tekstplacering = $placering (kan jo selvf. ret let laves en funktion der lige retunerer det stykke tekst udfra to variabler hver gang). Den tilgang virker jo umiddelbart lige til at gå til.
Jeg vil lige læse nærmere på brugen af xml-filer, da jeg ikke rigtig har beskæftiget mig med dem før. Tak for dit indspark - håber jeg forstod det rigtigt :)
Jeg tænkte på om det ikke var lettere at lave det så hver række havde samtlige oversættelser og jeg så bare lavede noget ala "SELECT $language WHERE id = $id" hver gang der skal trækkes en tekst-streng.
id, da, en 1, Fejl, Error 2, Velkommen, Welcome
Fordelen, som jeg ser den er at det er meget let at se hvilke tekststrenge, der mangler at blive oversat og at jeg ikke behøver at oprette en helt masse nye rækker hver gang der skal et nyt sprog til men bare en ny række.
Er der en ulempe som jeg har overset?
arne_v: Det ser rigtig smart ud, at de også tager højde for dato og al andet. Det virker dog så kompliceret at jeg er bange for at jeg ikke kommer i gang.
det ser da let ud ved første øjekast - men hverken særlig optimalt eller særlig korrekt; fx vil du den dag du skal have et nyt sprog på være nødt til at ændre i din database og det er en forkert tilgang til det at arbejde med databaser - og hvis du vil lave et opslag til databasen hver eneste gang du skal bruge et enkelt ord kan det blive til riiigtig mange opslag pr side og det er ikke så holdbart hvis der er mange pagerequest.
Lavet rigtigt vil det kun handle om at lave et brugerinterface der gør det let at overskue hvad der er oversat og hvad der ikke er.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Det er blevet kaldt ”det største it-nedbrud i historien” og omkostningerne kan nemt løbe op i syv milliarder kroner: Men hvem skal betale for Crowdstrikes fejl?
