Flerspråklighet

FS inneholder mange tilfeller av felter med språkvarianter, som brukes blant annet til lokalisering i applikasjoner. Typiske eksempler er varianter av navn, merknader, og URLer. Vi ser at det er behov for å tilgjengeliggjøre disse feltene på forskjellige måter, avhengig av om klienten er en applikasjon, eller en integrasjon.

For applikasjoner ønsker vi fallbackfunksjonalitet

Applikasjoner vil som regel være stilt inn til å vise tekster på ett bestemt språk. Samtidig er det ingen garanti for at den aktuelle teksten er tilgjengelig på brukerens ønskede språk. I slike tilfeller ønsker vi å kunne levere teksten på et språk der den finnes, etter visse fallback-regler. Samtidig trenger klienten informasjon dersom fallback-funksjonaliteten er brukt, og hvilket språk som faktisk vises.

Designet under er en illustrasjon på det vi ser for oss, og ikke et endelig design. For enkelhets skyld er har vi brukt et argument til sprak-feltet for å angi ønskede språk, men det løses antakelig bedre med en header eller lignende.

type Studentstatus {
    navn(
        """Ønskede språk i prioritert rekkefølge. APIet vil returnere feltet på det høyest prioriterte språket som har 
        verdi"""
        sprak: [TilgjengeligeSprak!]!
    ): StudentStatusNavn
}

type Studentstatusnavn {
    tekst: String!
    sprak: TilgjengeligeSprak!
}

enum TilgjengeligeSprak {
    NOB
    NNO
    SME
    ENG
}

Et slikt design vil være litt tungt å implementere med dagens funksjonalitet i Graphitron. Vi ser for oss at vi legger til funksjonalitet for å generere dette opplegget.

For integrasjoner ønsker vi å levere samme tekst på alle tilgjengelige språk

Vi tror at integrasjoner som henter flerspråklige felter, vil ha behov for å hente alle språkvariantene samtidig, og håndtere eventuell flerspråklighet i sitt eget system.

Siden applikasjonsdesignet skissert over leverer bare ett og ett språk, trenger vi et eget felt som returnerer alle de tilgjengelige språkene. Vi navngir dette feltet slik: <feltnavn>AlleSprak. Feltet peker på en egen type der hver språkvariant har sitt eget felt, navngitt med ISO-639-2-kode for det enkelte språket.

type Studentstatus {
    navnAlleSprak: StudenttatusnavnAlleSprak
}

type StudentstatusnavnAlleSprak {
    nob: String!
    nno: String
    eng: String
}

Felter som kan få språkvarianter i fremtiden

Vi bruker samme struktur for felter som ikke har språkvarianter i dag, men som kan få det i fremtiden. I slike tilfeller bruker vi språkkoden for ukjent språk, fordi vi ikke kan garantere at vi kjenner til språket på dataene som kommer tilbake:

Eksempel:

type Klasse {
    navnAlleSprak: KlassenavnAlleSprak
}

type KlassenavnAlleSprak {
    und: String!
}

Vi unngår å gjenbruke disse typene på tvers av noder/ressurser. Det vil si at selv om Emne og Studieprogram har navn med samme flerspråklige struktur, foretrekker vi å lage én type for Emnenavn og én for Studieprogramnavn. Dette er for å sikre at vi kan legge til nye språkvarianter uten at det blir en bakover-inkompatibel endring.

Behov for rydding i FS-tabeller

I FS er et veldig varierende hvilke tabeller som har språkvarianter der det er naturlig å ha dem. Det varierer også hvilke språkvarianter som er tilgjengelig. Vi vet i hvert fall om følgende varianter:

• Kun norsk (vi returnerer denne som und)
• Bokmål, nynorsk og engelsk (bmo, nno og eng)
• Bokmål, nynorsk, engelsk og nordsamisk (bmo, nno, eng og sme)
• norsk og engelsk (nor og eng)

Det finnes også en del felter der særlig bokmålsfeltet har tekst på et annet språk. Det skyldes som regel at bokmål gjerne er et obligatorisk felt, også for tabeller der det ikke nødvendigvis finnes et navn på bokmål. Ett eksempel er rent engelskspråklige emner, et annet er utenlandske institusjoner, der bokmålsfeltet gjerne inneholder navn på originalspråket.

ISO-639-1 eller ISO-639-2?

Vi har til nå brukt ISO-639-2 (tresifrede koder) for språkkoder, selv om ISO-639-1 i mange tilfeller er mer brukt. Årsaken til at vi valgte ISO-639-2 var at vi hadde behov for en kode for ukjent språk, noe som mangler i 639-1-kodesettet. Det betyr ikke at 639-1 ikke kan brukes, for eksempel til fallback-løsningen for applikasjoner skissert ovenfor dersom det viser seg å være mer brukervennlig.