# Universal translations

## Założenia

- tłumaczenia umożliwiają zarówno tłumaczenie obiektów Ruby, jak i treści zupełnie nie związanych z obiektami Ruby (wtedy localizable: NULL)
- nie ma podziału: oryginalna treść vs. tłumaczenia. Wszystkie treści dla użytkownika są tłumaczeniem (jakimś) a języki są względem siebie równoważne
- umożliwiamy nadpisywanie tłumaczeń przez GraphQL (o ile user ma uprawnienia ofkorz)
- każdemu użytkownikowi graph wysyla treść w jego języku z bazy (user.locale)
- jeżeli user nie jest zalogowany to polegamy na x-language lub accept-language - propozycje? a może powinniśmy dodać domyślny język na poziomie festiwalu i na niego fallbackować? jednak wtedy wciąż trzeba jakoś obsłużyć zmianę języka z "wybieraka" na stronie

## Model

@startuml

note top of Translation : z obsługą PaperTraila dla najprostszego wersjonowania

class Translation {
    + id -> FK
    + localizable_type:string NULLABLE
    + localizable_id:bigint NULLABLE
    + key:string NOT NULL
    + value:string NOT NULL
    + lang:string NOT NULL /ISO 639-1 code/
}

package Localizables <<Node>> {
    .Translation <|-- Restaurant
    .Translation <|-- MenuPosition
    .Translation <|-- FestivalEditionRestaurant
    .Translation <|-- Menu
    
}

note top of Localizables : i inne modele

@enduml

| localizable_type | localizable_id | key | value | lang |
|------------------|----------------|-----------------------------|------------------------------------------------------|------|
| Tag | 1 | name | romantyczna | pl |
| Tag | 1 | name | romantic | en |
| Festival | 1 | slogan | Najlepsze autorskie restauracje w festiwalowej cenie | pl |
| <NULL> | <NULL> | festivals.rw.faq.question_1 | Czy tu się w ogóle można najeść? | pl |
| <NULL> | <NULL> | festivals.rw.faq.answer_1 | I to jeszcze jak! | pl |

## Jaki język użytkownika?

zasadniczo polegamy na jezyku z `user.locale` - więc nie bierzemy tego dynamicznie na każdym requeście z headera `x-language`...chyba że user nie jest zalogowany

Powód jest taki, że chcemy żeby na obcojęzycznej przeglądarce user wciąż widział treści w ustawionym przez siebie języku, nie w automatycznym języku przeglądarki.

## Flow

@startuml
actor Front as F
boundary Api as B

F->B : User chce danych o np. Restauracji przez GraphQL
B->B : Query Graphql deleguje pracę do modelu
B->B : Model deleguje gettery niektórych, \ntłumaczonych atrybutów do adaptera translacji
B->B : Adapter translacji wie w jakim języku user pyta \n i robi lookup odpowiednich translacji w tabeli Translation
B->F : API zwraca zlokalizowane dane


@enduml

## Query
Zwracamy teksty tylko/od razu w języku usera (lub z headerów) z fallbackiem na język z settingsów (domyślnie PL)

## Mutacje - admin
Zapis tłumaczeń z panelu admina możemy zaimplementować na dwa sposoby w zależności jak edycja miałaby wyglądać na adminie.
Dla przykładu użyty model `Tag` mający pole `name`:
- mutacja create/updateTag przyjmuje array tłumaczeń:

    mutation {
      updateTag(
        id: 1,
        name: [
                { locale: PL, value: 'romantyczna'},
                { locale: EN, value: 'romantic'},
        ]
      )
    } 

- mutacja przyjmuje kontekst tłumaczeń

    mutation {
      updateTag(
        id: 1,
        name: 'romantyczna',
        locale: PL
      )
    } 

## Todosy
0. Określenie listy pól tłumaczonych dla każdego modelu
1. Stworzenie tabeli i migracja
2. Stworzenie generalnego adaptera do modeli AR (najtrudniejsze)
3. Stworzenie generalnego wpinalnego w queriesy i mutacje adaptera do GraphQL
4. Migracja w celu dodania defaultowych PL tłumaczeń (z tego co mamy) do określonych modeli
5. Wycięcie w pień redundantnych pól z modeli (wszystkie tłumaczone pola będą przemapowane do tabelki `Translations`)

rspec ./spec/models/submission_spec.rb:14 # Submission#incoming_changes when provided invalid incoming changes is expected not to be valid
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:28 # V1::Restaurants::Updaters::Submission#call adds proper changes to submission
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:20 # V1::Restaurants::Updaters::Submission#call does not update restaurant
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:73 # V1::Restaurants::Updaters::Submission#call with billing data when restaurant does not have billing data adds proper changes to submission
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:106 # V1::Restaurants::Updaters::Submission#call with billing data when restaurant has billing_data adds proper changes to submission
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:133 # V1::Restaurants::Updaters::Submission#call with tables with attributes adds proper changes to submission
rspec ./spec/services/v1/restaurants/updaters/submission_spec.rb:177 # V1::Restaurants::Updaters::Submission#call with tables without attributes adds proper changes to submission

rspec './spec/models/restaurant_spec.rb[1:1:25:1:1:1]' # Restaurant behaves like a model behaves like attribute_limiting text length validation for name with text longer than limit is invalid
rspec ./spec/services/v1/submissions/changes_validator_spec.rb:33 # V1::Submissions::ChangesValidator#call when submissionable is restaurant when changes are invalid with submissionable has invalid submission