Språk på uno

Til UKA-21 ble det implementert støtte for flere språk på uno. Det er støtte for både engelsk og sør-samisk, men det er planlagt å fjerne sør-samisk til UKA-23.

Språk 101

Dersom du legger inn nytt tekstinnhold som skal vises til brukeren må du markere tekststrenger for oversetting. Dette gjøres på litt forskjellige måter avhengig av hvilke filer du endrer på. Det er viktig at du gjør deg kjent med hvordan man markerer tekststrenger for oversettelser før du utvikler på uno. Her er de mest vanlige:

Jinja2

Her bruker vi stort sett {{ _('ditt_ord_her') }} der _ er et alias for gettext. Det er også mulig å bruke blokker med {% trans %} og {% endtrans %}. Se Jinja sin dokumentasjon for ytterligere info som flertall og trimmed parameteret.

Språk-funksjonene get_language, get_locale_url og hard_translation er lagt til i Jinja sitt environment.

Django

Her bruker vi som regel gettext eller ugettext. Dersom du trenger at tekststrengen skal oversettes under template rendering må du bruke lazy-versjonen av disse. Merk at disse funksjonene ofte blir importertert med _() som alias. Siden Django har innebygd støtte for oversettelser finnes det mye funksjonalitet som kan brukes i python filer og dette kan du lese mer om i dokumentasjonen til Django.

Javascript

Oversettelser i Javascript filer støttes gjennom en liten work-around som Django har laget. Django har laget en slags kopi av gettext som du kan bruke i javascript filene. Dette fungerer ikke helt sømløst, så prøv å unngå oversettelser av tekststrenger i js om mulig. Dersom du absolutt må oversette en tekststreng i js må du sørge for at det fungerer også om man skrur av støtte for i18n. Når du skrur av støtte for i18n forsvinner gettext -funksjonen fra javascript og koden brekker om du ikke har tatt høyde for dette.

Flyt for oversettelse av statisk data og hvordan kompilere språkfiler

python manage.py extract_languages
Få en oversetter i uka til å oversette alle tekststrengene som ligger i de kompilerte .po filene
Legg inn nye oversettelser i .po filene
git commit
fab deploy
Gå i prod og gjør python manage.py compile_languages

Oversettelser av dynamisk data

Om man skal rendre tekst fra en modell i jinja2, bruk den tilhørende klassefunksjonen for dette. Eksempel: bruk {{ frontpage.get_frontpage_text() }} og ikke {{ frontpage.frontpage_text }}. Dette betyr også at man må lage en tilhørende klassemetode for å hente ut teksten om man legger til et nytt felt som skal oversettes på en modell.

URLer

Aldri skriv url-er under www.uka.no rett frem. Språket velges ut fra url-en (f.eks www.uka.no/en) og url-ene må derfor genereres ettersom hvilket språk som brukeren har valgt. Du kan bruke reverse funksjonen i Django for å oppnå dette. I Jinja har vi for en eller annen grunn valgt å endre navn på denne til url, men den skal fungere helt likt som reverse.

Dersom du ikke kan bruke reverse -funksjonen (f.eks. hvis url-en bestemmes av en bruker) kan du bruke funksjonen get_locale_url som ligger i utils/translation.py. Denne er også tilgjengelig i Jinja.

Eksempler:

Reverse (url i Jinja): reverse('view_page', args=['personvern'])

Relativ url med get_locale_url: get_locale_url('/personvern/', language_code)

Fullstendig url get_locale_url: get_locale_url('https://www.uka.no/personvern/', language_code)

For oversettere

Det er to typer oversettelser som gjøres på uno, statiske tekststrenger og dynamiske tekststrenger. Statiske tekststrenger er tekst som ikke endrer seg ofte. Dette vil for eksempel være navnet på lenkene i menybaren øverst på siden. For å oversette disse tekstene må en person i itk sende dere et skjema med tekststrenger som skal oversettes. Etter at disse er blitt oversatt må dere sende skjemaet tilbake til itk slik at vi kan legge det inn på siden.

Oversettelser av dynamiske tekststrenger kan gjøres på https://www.uka.no/admin/translations/. Om du ikke har tilgang til denne siden, men burde ha det, kontakt itk. Her kan man oversette alle tekststrengene som er tilgjengelige for oversettelser og brukergrensesnittet er ganske rett frem. Det er ett lite unntak for dynamiske strenger og det er pris- og billettgrupper. Det er ikke laget støtte for dynamisk oversettelse av disse, så dette gjøres rett i kodebasen til itk. Dersom det opprettes en prisgruppe med et nytt navn vil denne ikke bli oversatt. Ta derfor en kikk på prisgruppene som er lagt ut for å se om de blir oversatt korrekt.

Om det er noe som ikke fungerer som det skal eller dere er usikre på, ikke nøl med å ta kontakt med itk!

Teknisk oppsett

Django sin innebygde funksjonalitet for å eksportere oversettbare tekststrenger fungerer ikke for Jinja2 templater. Vi bruker derfor Babel til å kompilere språkfilene. Det er blitt laget to kommandoer i Django for å forenkle denne prosessen. Disse finnes som managementkommandoer i appen translations. Du kan lese mer om bruk under Kompilere språkfiler nedenfor.

Tekststrenger i modeller

Under implementasjonen av språkstøtte på uno ble det tatt noen uheldige valg og slik det er gjort nå er det lagt til et ekstra felt for hvert språk for hver tekststreng i en modell. Eksempelvis har en nyhetsartikkel en title og den har nå også title_en og title_sma for henholdsvis engelsk og sør-samisk tittel. Når tittelen skal hentes frem i et templat benyttes så get_title() metoden som bruker funksjonen get_translated_text() for å hente ut tittelen på korrekt språk. get_translated_text() er en funksjon som tar inn navnet på feltet som skal oversettes og returnerer så verdien av feltet på det språket som er aktivt. For at dette skal fungere må navnet på det oversatte feltet være på følgende format <navn-på-felt>_<språkkode>. Dersom navnet på feltet er title og engelsk er aktivt språk vil verdien til feltet title_en returneres. For norske tekstfelter trenger man ikke legge på _nb på slutten av navnet.

Dersom man lager et nytt felt som skal oversettes på en modell må man altså lage tilhørende klassemetode for å hente ut teksten. Denne funksjonen skal bruke utils funksjonen get_translated_text() for å gjøre dette. Se hvordan dette er implementert for andre felter om du er usikker.

Kompilere språkfiler

TODO: Kompileringen til .mo-filer burde legges in i fab-skriptet og filene burde fjernes fra git.

Det er blitt laget to kommandoer i Django for at kompileringen av språkfiler skal bli enkel. Etter at du har lagt til en tekststreng og markert at den skal oversettes må du eksportere denne tekststrengen til en språkfil. Dette gjør du ved å kjøre kommandoen python manage.py extract_languages. De eksporterte språkfilene vil ligge i uno/app/translations/static-translations/locale/{language_code}/LC_MESSAGES og de vil ha filendingen .po. Få så en oversetter i UKA til å oversette alle de nye endringene i språkfilene. Når oversettelsene er blitt lagt til i .po-filene kan du kjøre python manage.py compile_languages for å kompilere filene slik at Django får tak i de nye oversettelsene dine.

Legge til/Fjerne språk

Det er egentlig ikke laget god støtte for dette i dagens implementasjon ettersom språkfelter legges direkte på modellene. Om man vil legge til et nytt språk må man legge til et nytt felt for hver tekststreng som skal oversettes på alle modellene. Tilsvarende hvis man vil fjerne ett språk. Man må også legge til/fjerne språkkoden fra LANGUAGES i base.py og sørge for at alle funksjonene i uno/utils/translation.py håndterer endringene i tillatte språkkoder. Nye filer må eventuelt kompileres for de nye oversettelsene også.

Oversettelse av billettgrupper

TODO: Løs dette på en bedre måte.

Billett- og prisgrupper hentes fra billig og Django får tak i dataene gjennom et par views i databasen. Dette gjør at man ikke kan legge til ekstra felter for disse modellene. Per nå gjøres oversettelser av disse feltene manuelt i funksjonen hard_translations() som ligger i uno/utils/translation.py. Dette er en veldig dårlig måte å løse problemet på siden man må oppdatere disse oversettelsene manuelt i koden. Om en ny billettgruppe opprettes i billiggrensesnittet vil det ikke finnes en oversettelse på dette på uno.

Lenker: Start