Closed robinsandborg closed 3 years ago
Vet ikke om det hjelper deg noe som en temp greie, men man ser i hvert fall I18n keys, med deres value i i18n-nettverkskallet.
Er bare så sykt mange og vanskelig å vite hva som er hvor. Spesielt i en app som er oversatt på et språk, men er tom på det andre forsvinner bare tekstene på språk 2, så det er litt komplisert
Super, super røff sketch av "holy grail"
Hva med å sette loglevel til 5 på provideren for å få ut en slik liste? Da får man vel et array med alle språkene til hele appen? Men vil vel gi akkurat samme utfordringen?
Ja, tingen er at jeg ikke nødvendigvis vet hva som burde vært der, det er bare en haug med manglende tekster over alt. Så det enkleste nå er å switche language på provideren frem og tilbake og se hva som endrer seg
Dette er åpenbart noe vi må få til bedre løsning på. Når det gjelder å kartlegge hva som mangler så har jeg noen tanker. Det finnes traversers
som kan gå gjennom jsx (acorn) og vi kan kjøre custom kode på det. Det er lett for oss å finne alle <Translate />
rundt omkring. Derfra er det ikke langt på å sjekke om verdien finnes i db. Vi har også et callback i dag på missing keys som kunne vært brukt til å faktisk lage disse keyen i Sanity. Jeg har derfor lenge bedt folk om å bruke Translate fra dag én med god fallback value. Den kan da lage key fra prop og value fra fallback.
Vi har også snakket om et "debub" panel som kan wrappes i appen. Da kunne vi kontekstuelt hentet ut verdier som rendres og håndtert der. Det ville vært en "holy grail -". fordi vi kunne listet opp i18n keys og gjort de editerbare der.
Dette er til syvende og sist et spørsmål om tid og ambisjon. Hadde jeg hatt mulighet hadde jeg bare jobbet med bento 😄
Se branch debugTranslate, lagde et lite alternativ for en løsning som lar deg tagge debug=true på i18nProvider og viser da alle verdier til key hvor den er i bruk.
Når man skal legge til et nytt språk i et eksisterende prosjekt kan det være vanskelig å finne alle i18nkeys som er brukt rundt om kring. Det beste hadde vært om vi kunne kommet frem til en løsning som gjorde kunden selv i bedre stand til å finne 18nkeys, men det er jo en ganske stor feature.
Holy grail hadde vel forsåvidt vært støtte for inline editering som vi kunne skrudd på i staging eller noe.
Et sted å begynne En idé som jeg ikke vet om er like enkel å implementere som jeg tenker: i18nProvider får en ny prop: wrappes i en span og få en ny attribut ala dette
debug
eller noe sånt. Hvisdebug.wrapAttributes
eller noe sånt er true vil alle<span data-i18nkey={i18n}>
Tanker?