Webkafeen

[Bolson]

@Sebba:

 

TYPO3 har en slik løsning med å kunne plukke språkvalg i en dropdown. I tillegg har de valg i artikkeloversikter der man kan klikke på valget "oversett denne (ikon)". Når en oversettelse lages vises også orginalteksten.

 

Særlig det at man kan klikke på et ikon/link i f.eks. listevisning og automatisk få opprettet en versjon som er merket med rett språk (nytt språk), og der originalen vises slik at man har referansen framfor seg når man oversetter er meget godt likt av brukere. Det er ellers ikke brukt et eget view, "skjemaene" ser helt like ut.

 

Erfaringene på nettsteder med flere språk er at det fungerer glimrende og gjør arbeidet effektivt og oversiktlig. Ikke minst det at man har oversikt over hvilke elementer som er oversatt og hvilke som ikke er.

 

Hvorfor trenger det å være et menyproblem.

[qualbeen]

Jeg driter i backendløsningen(og wtf? Xml på disk?)

 

Jeg er ute etter smarte løsninger, og dårlige løsninger på å representere dette for brukern

 

Hmm, Jacob Nielsen sier man skal ha tekstlinker og ikke flagg fordi det kan være diskriminerende og tvetydig

 

Men er jo egentlig backend jeg lurer på. Hvordan det skal vises i kontrollpanelet.

 

 

 

----

 

Men det er at bare å sørge for at samtlige deler av siden blir oversatt? Man har jo gjerne en språk-id som definerer hvilek spåk brukeren har valgt. Så er det bare å hente ut maler og menyer og lister og artikler etc, ut i fra det valget. Forstår overhodet ikke problemet. Eneste er at man må gidde å oversette alt da (men ser på det som en selvfølge at du har fallback-løsninger på elementer som ikke er oversatt)..

 

Tror egentlig ikke jeg har forstått problemstillingen helt.

[jorgis]

Tror egentlig ikke jeg har forstått problemstillingen helt.

 

Er ikke sikker på om Sebba har forstått problemstillingen heller. Eller om han kanskje lager et problem der det ikke er noen.

[Jesper Karsrud]

Holt crap, Arve tok noen kick ass bilder av meg i går som han MÅ legge ut!

 

Og Hein, Arve sendte den meldingen som lød: "Arve er awesome!!!!!!!" fra min mobil... Jeg lånte iPhonen min til han, og dermed skjedde det.. Beklager..

 

 

 

 

Fadderdag på skolen som resulterer i feilfri srkiving er ikke verst altsa" Bra kvled selv om jeg kom litt sent igang pga møter på dagen.. . r

[Arve Systad]

Kekk, Jesper tilbake og skriver på forumet alt? Tydeligvis kom han seg heim før meg, var tilbake på skulen og plukka opp T-skjorta mi og leita etter husnøkkelen til Jamie

 

Uansett, den meldinga var konge. Typisk fyllegreie, i guess. Bildene av Jesper blir sikkert kanskje muligens lagt ut i morra elns. Atm skal eg spise kebab og legge meg. Melk er forresten dritdigg etter en sterk kebab

[Steinmann]

Problemstillingen er at det er kunder som skal sitte og oversette denne driiten. Og da kan du banne på at de ikke oversetter alt etc.

Da må man ha fallbackløsning, hvis man ønsker. Vi kan ikke låse oss til en måte å håntere det på. Hehe.

 

Tror jeg har en relativt god ide inne i hodet mitt om hvordan dette skal løses nå da. Hehe.

[Lovskogen]

Fyllebilderposterlulz. Kan du ikke lage en norsk side, og en engelsk side?

[Steinmann]

Fyllebilderposterlulz. Kan du ikke lage en norsk side, og en engelsk side?

Man kan, men hvordan løser du fallback etc da?

[Lovskogen]

Fallback i tilfelle hva?

[Bolson]

@Sebba:

 

Fallback er en forutsetning for godt fungerende flerspråklige sider. I alle fall om man skal bruke "one tree - multiple language" innfallsvinkelen. Men fallback bør være noe som konfigureres i oppsettet og ikke noe som brukere i realiteten trenger å bry seg med (ikke engang ser) Fallback kan ellers ha flere ulike oppsett:

1. Finnes ikke side/artikkel i valgt språk vises original

2. Finnes ikke side/artikkel i valgt språk vises intet (heller ikke menyvalg)

3. Finnes ikke side/artikkel i valgt språk vises "No translation of this page"

 

Man har også alternativer der orginal/oversatt presenteres i 1:1 forhold, dvs at en artikkel har sin identiske oversatte partner. Men også der ikke forholdet er 1:1, dvs at innholdet faktisk kan avvike i språkversjoner.

 

Så hvordan grensesnittet for bruker er i backend kan være identisk uansett valgt fallback så lenge flere språk er aktivert.

 

Og at brukere ikke oversetter alt er en av livets realiteter.

[Steinmann]

@Sebba:

 

Fallback er en forutsetning for godt fungerende flerspråklige sider. I alle fall om man skal bruke "one tree - multiple language" innfallsvinkelen. Men fallback bør være noe som konfigureres i oppsettet og ikke noe som brukere i realiteten trenger å bry seg med (ikke engang ser) Fallback kan ellers ha flere ulike oppsett:

1. Finnes ikke side/artikkel i valgt språk vises original

2. Finnes ikke side/artikkel i valgt språk vises intet (heller ikke menyvalg)

3. Finnes ikke side/artikkel i valgt språk vises "No translation of this page"

 

Man har også alternativer der orginal/oversatt presenteres i 1:1 forhold, dvs at en artikkel har sin identiske oversatte partner. Men også der ikke forholdet er 1:1, dvs at innholdet faktisk kan avvike i språkversjoner.

 

Så hvordan grensesnittet for bruker er i backend kan være identisk uansett valgt fallback så lenge flere språk er aktivert.

 

Og at brukere ikke oversetter alt er en av livets realiteter.

Klar over det.

 

Men er fremdeles noe som må taes hensyn til.

 

Keyteq jobber gjerne med en og en site, og må ta hensyn til en kunde. Vi må ta hensyn til 1000+ kunder når vi lager noe.

[Bolson]

Blir egentlig realitetene så forskjellig. Mulighetene til å håndtere flerspråklige nettsider må tross alt bygges inn i systemet uansett om det er KeyPublisher, Drupal, TYPO3 eller Flexiweb. Det å lage en spesifikk modul/tillegg hver gang er jo lite hensiktsmessig. Forskjellen ser jeg først er på måten man aktiverer mulighetene på et nettsted. I f.eks. TYPO3 gjøres det vanligvis i oppsettet av det enkelte nettsted (implementering), selv om jeg kan sette opp en standard som gjør at kunde ved hjelp av avkryssingsbokser kan velge hvilke språk han skal ha tilgjengelig og hvilken fallback metode som skal brukes.

 

Så det burde ikke være noe problem å etablere en generisk flerspråkløsning, der kunden faktisk selv kan velge å aktivere flerspråk samt hvilken type fallback som skal brukes. At det programmeringsmessig ikke nødvendigvis er "piece of cake" er helt klar over.

[Haraldson]

I KP har vi ett standardspråk som brukes dersom ikke oversettelse eksisterer. I ordboka, i alle fall. I tillegg har vi jo språktester i malspråket etc. som eksempelvis lar oss veksle mellom hvilke attributter (fra den samme malen) som skal brukes i hvert tilfelle.

 

Ordboka fungerer for så vidt slik at bruker har et grensesnitt hvor oversettelser kan legges inn. En kan definere et nøkkelord, eksempelvis 'hjem', og la norsk standard være 'Hjem', nynorsk være 'Heim' og engelsk være 'Home'. Så bruker man nøkkelordet som argument i en metode/tag i malen. Nyttig for eksempel for kontaktskjemaer, så slipper man å lage flere forskjellige maler. Alle tagger som har med språk å gjøre, forholder seg til en verdi som er satt på sidenivå. Derfor er vi stort sett avhengig av flere strukturer/trær, men altså ikke alltid forskjellig innhold, nødvendigvis.

 

Produktene våre lar seg oversette, så her holder det å opprette ett produkt uansett språk. Tror ikke vi har tilsvarende for artikler, da jeg tror produktutviklerne våre mener at en artikkel på norsk og en artikkel på engelsk ikke er den samme artikkelen.

[Steinmann]

Mhm, vi skal selvfølgelig ha for produkter og artikler etterhvert også.

Når det kommer til menyer osv så har jeg forstått det som at det er noe dere koder i templaten. Altså at man ikke kan legge til en ny side også kommer den automagisk inn i menyen?

 

Tror det blir lenge til vi får implementert språk, mye annet som skal inn. Hehe.

Før produkter håper jeg.

[Haraldson]

At vi hva? Vi lager rekursive menymaler som skriver ut en gitt kategori, eventuelt barn av denne og barn av barna etc. Alt kan vi styre selv. Det er først når vi oppretter 'språktrær' at vi eventuelt må inn med egne menyer, dersom menyene er så spesifikke at vi angir kategori-ID for hva som skal skrives ut.

 

Trenger dog ikke, kan like gjerne bare angi nivå, så vil den skrive ut sider på andre nivå under det usynlige /en/-nivået, for eksempel, siden den isincurrentpath. Så nei, ingen dumme GX-begrensninger der.

[Steinmann]

Trenger dog ikke, kan like gjerne bare angi nivå, så vil den skrive ut sider på andre nivå under det usynlige /en/-nivået, for eksempel, siden den isincurrentpath. Så nei, ingen dumme GX-begrensninger der.

 

-

 

Vi skal også få inn sån. Denne menyen viser undermenyen til en annen meny. Tåpelig at vi ikke har det.

[Marvil]

Noen som husker om YSlow kommer by default sammen med Firebug, eller om det krever egen nedlastning ?

 

Edit; Det ser ikke slik ut, basert på info om YSlow.

Endret 22. august 2008 av Marvil

[Arve Systad]

Fyllebilderposterlulz.

 

 

[Steinmann]

Du er så sexy når du vil altså gJesper!

[Haraldson]

Først Fairy girl-Jesper, så Chicken-Jesper — kan det bli noe bedre?