Closed andersrebner closed 1 year ago
Nice, virker som en grei implementasjon. Det eneste jeg tenker på er at det hadde vært kult om man kunne ha hatt oversettelsene i databasen på backend på et vis. Da hadde man kunne laget en tabell i front-end for å endre på oversettelser, + det hadde muligens blitt mer oversiktlig 😅 Man hadde også sluppet å måtte gått inn i flere filer når man hadde en ny streng.
Det er bare en tanke jeg hadde, og det er absolutt ikke en nødvendighet. Sånn løsningen er nå fungerer veldig bra det også 👍
@krisstam Edit: mulig jeg har misforstått litt, det er kanskje slik at andre Knowit-selskaper skal bruke samme AWS-backend?
Jeg synes det høres ut som en kul idé! Tenker at det evt. kan gjøres i egen PR. Begynte å lage et issue, men sliter med å skissere et godt løsningsforslag. Her er de største utfordringene jeg ser:
Det er open-source og andre (f.eks. Knowit i Polen) skal bruke egen AWS-konto
Frontend-en må vel kunne fungere out of the box. Uten innsjekkede språk vil f.eks. i18n.t('menu.editAdmins')
displaye menu.editAdmins
. Vi kan jo lage et script som bruker innsjekkede språk-filer til å fylle databasen, men da får vi to sannhetskilder som vi må huske å oppdatere (språk i database og innsjekkede språk), spesielt hver gang ny oversettelse legges til.
Legge til ny oversettelse når språk ligger i database Dette vil nok fungere fint for Objectnet siden det er vi som utvikler, men hver gang frontend tar i bruk en ny oversettelse vil jo det på en måte bli en breaking change for alle andre som har egen AWS-konto, siden de mangler oversettelsen. Det kan ta lang tid å oppdage, og man forstår nødvendigvis ikke hva oversettelsen skal være basert på key-verdien som displayes på frontend-en. Jeg antar at vi bør ta hensyn til slikt?
@krisstam Edit: mulig jeg har misforstått litt, det er kanskje slik at andre Knowit-selskaper skal bruke samme AWS-backend?
Jeg synes det høres ut som en kul idé! Tenker at det evt. kan gjøres i egen PR. Begynte å lage et issue, men sliter med å skissere et godt løsningsforslag. Her er de største utfordringene jeg ser:
- Det er open-source og andre (f.eks. Knowit i Polen) skal bruke egen AWS-konto Frontend-en må vel kunne fungere out of the box. Uten innsjekkede språk vil f.eks.
i18n.t('menu.editAdmins')
displayemenu.editAdmins
. Vi kan jo lage et script som bruker innsjekkede språk-filer til å fylle databasen, men da får vi to sannhetskilder som vi må huske å oppdatere (språk i database og innsjekkede språk), spesielt hver gang ny oversettelse legges til.- Legge til ny oversettelse når språk ligger i database Dette vil nok fungere fint for Objectnet siden det er vi som utvikler, men hver gang frontend tar i bruk en ny oversettelse vil jo det på en måte bli en breaking change for alle andre som har egen AWS-konto, siden de mangler oversettelsen. Det kan ta lang tid å oppdage, og man forstår nødvendigvis ikke hva oversettelsen skal være basert på key-verdien som displayes på frontend-en. Jeg antar at vi bør ta hensyn til slikt?
Angående punkt 1, vi har flere organisasjoner inne i samme AWS konto i Prod. Løsningen er open-source, men per dags dato så er det multi-tenancy på samme konto som blir brukt (Se organisasjon tabellen i dynamodb + cognito gruppene.) Det er mulig å ha en seed-fil for databasen, slik at man får et utgangspunkt.
For punkt 2, så ville vi antageligvis ha måtte laget løsningen slik at antall språk (og hvilke språk) blir hentet fra databasen, slik at man har mulighet for å ha variable språk per deployment (for eksempel er det nok ikke nødvendig for Knowit Polen å ha norsk eller svensk, men engelsk er greit å ha.)
Per dags dato har vi et sted mellom 4-7 organisasjoner inne i applikasjonen, alle sammen knyttet opp mot samme AWS konto/cognito/dynamodb.
Det er greit at PR-en ble merget, som jeg sa i forrige kommentar, så er dette en grei løsning :+1:
Ting som er verdt å nevne:
frontend/src/i18n.ts
, som også beskriver hvordan nytt språk legges tilfrontend/src/i18n/schema.ts
slik at manglende oversettelser oppdagesEr i skrivende stund deployet til dev.kompetanse.knowit.no (ser du ikke språk-velgeren er det 'overskrevet')
closes #89