Jak by jste resili preklady + verzovani textu? (+ administraci pro prekladatele)

LeonardoCA

Ceka mne pravdepodobne v prvni pulce pristiho roku toto implementovat pro jeden web a premyslim nad vhodnym resenim.

Rad bych pak hotovy zakladni moduly zverejnil jako samostatne nette addony a proto me napadlo zeptat se predem na nazor dalsich, kteri podobne veci resili nebo se taky chystaji resit.

Addony by byly minimalne dva, ktere by bylo mozne pouzivat samostatne ale mely by spolu spolupracovat Translations a Versioning – mozna uloziste dat by mela byt definovane samostatne

Pozadavky jsou zhruba tyto:

preklady vseho od ruznych textu v db, pres hlasky ve zdrojacich + mozna i podklady pro grafiku, ci videa, apod
verzovani minimalne vsech vetsich textu
administrace pro preklady s nejakou definovanou workflow – napriklad – preklad/korekce/schvaleni
prekladatel by mel mit k dispozici nejaky slovnik casto pouzivanych vyrazu, at se prekladaji v ramci webu konzistentne
moznost prirazovat priority co ma byt prelozeno drive a dalsi funkcnost, ale to neni pro zaklad podstatne

Ma predstava:

chci to postavit nad Kdyby\Translations
chci to resit pekne modularne, at je prace v admistraci prekladu se vsemi prekladanymi objekty priblizne stejna a da se kdykoli rozsirit pro libovolne nove pozadavky
pro preklad je casto dulezity kontext, v jakem je text pouzit a proto by mel mit kazdy prekladany text preview, pripadne odkaz primo na web (proste nejake provazani s frontendem pokud to bude realne)
mozna moznost inline prekladu primo na webu (ale to spada do kategorie „bylo by fajn“)
implementovat to jako samostatny modul, pouzitelny v libovolne aplikaci

Nad cim premyslim a co je v tuto chvili pro mne neznama je:

1. verzovani implementovat pomoci samostatnych tabulek v MySQL a nebo zkusit vyuzit Git?

Pouzit git me napadlo ve spojitosti s pozadavkem na verzovanim, proc vymyslet nejaky system jak verzovat vse v databazi, kdyz na verzovani je expert git. Chvili hledal na netu a zjistil narazil ze ho vyuziva napriklad VersionPress

To souvisi i s deploymentem – bylo by pekne mit nejak provazane push requesty na projektu s repozitarem prekladu – aby se pri deploymentu automaticky zmenily texty, ktere s upravou webu souvisi, pripadne, aby se automaticky kontrolovalo, zdali jsou vsechny texty pripravene.

A navic by tak pribyla snadna moznost jak vrati puvodni verzi vcetne textu, pokud by nahodou vznikl behem nasazeni na production nejaky problem.

Ale kdyz nad tim premyslim, tak samotne texty stejne nebudou v hlavnim repozitari, takze pak v pripade potreby provazani s pull requestem by se to stejne muselo resit jinak. Takze se spise priklanim k reseni s nejakymi tagy v databazi.

2. Preklady by mely mit zrejme svou samostatnou administraci, ale mohly by byt provazene i s hlavni administraci …

K tomu mam predstavu jak by se to dalo resit pomoci sikovnych komponent.

Co si myslite? (Ma vubec smysl snazit se udelat neco takoveho univerzalne?)

Pokud by nekdo neco takoveho vyuzil, uvitam jekekoli napady nebo pripominky, at vznikne neco pouzitelneho.

Editoval LeonardoCA (28. 12. 2014 17:11)

Filip Procházka

Tyjo, velké sousto :)

Myslím že by bylo fajn, udělat komponentu která bude umět překládat texty na web pomocí kdyby/translation, aby se dala vložit do libovolné administrace. Sám to chci dělat, ale není to teď priorita.

Obsah je problematika téměř až nesouvisející s kdyby/translation, protože má jiné požadavky a do slovníkových souborů se extrémně nehodí. Takže je dobře, že zvažuješ db/git. Kterou technologii použít ti ale neporadí, sám nevím :)

Nevím jak bych to dělal univerzálně já. To co popisuješ by bylo prakticky už kompletní malé CMS. A udělat hotovou aplikaci tak dobře, aby se dala vložit do jiné aplikace, není vůbec jednoduché.

akadlec

mno nevím co stavíš, ale v jiných app jsme to řešili tak že slovníky pro systémové hlášky, názvy form elementů, drobné texty layoutu (např. v patičce) byly vždy ukládány do db s tím že se pak rozpřekládavaly do ostatních jazykových verzích a samo s určením stavu schvaleno/neschváleno atd. Byl k dispozici admin panel pro překladatele kteří viděli jen své lokalizace a ty slova/věty co nebyly přeloženy a nebo neprošly korekturou atd a počítal se jim pak počet kolik toho přeložili. No a z odsouhlasených překladů se dělaly jednotlivé PO slovníky pro translator. Verzování se řeší v DB, neb. nějak netuším jak si verzovat jednotlivé překladatele aniž by neměli account na gitu což je dle mě pro ně opruz, takže se dělala klasicky verzovací tabulka kde bylo info o změně, kdo kdy atd.

Samo texty článků, produktů, kategorií atd se řešily mimo toto jako u většiny CMS na konkrétním místě, tj. když se vytvářel/editoval produkt tak měl kolonky pro jednotlivé překlady a tady se zas na jednom projektu využívala překladová služba, takže se nemusel překlad dodat, ale udělala jej služba a případné korekce pak překladatel.

Osobně si nedovedu představit jak to dělat univerzálně, každý projekt má svá specifika, snad jen nějakou kostru a pokud to bude na kdyby tak asi udělat nějakou službu co bude kdyby předávat slovníky. Nad tím jsem taky přemýšlel že se kouknu zda jde kdyby nějak jinak předat slovník než přes definice v neonu, ale zatím mě to nepálí tak sem nehledal.

LeonardoCA

Komponenta souhlasim, ta se bude hodit i pro jednodussi aplikace.

Obsah a texty ze zdrojaku – jasny, ze to jsou z hlediska systemu uplne jine veci, ale rikal jsem si, ze prekladatelum je to vlastne uplne jedno co to je za text a jak se dostane na web, takze pro mne by rozhrani mohlo byt uplne stejne…

Takze asi nakonec by vsechno muselo do db a pak texty pro kdyby\translations by se exportovaly („distribuovaly“) do souboru, nebo jineho uloziste

V databazi by veskere texty byly v jedne nebo dvou (varchar, text) tabulkach, pro kazdy jazyk vlastni tabulka, at funguje collation a kazdy text by mel sve jednoznacne id, a nejake id typu – co to je zac – pro jednoduche filtrovani, atp

V datovych tabulkach by zadne texty nebyly jen reference pres id na prekladovou tabulku, (mozna nesmysl), jinak me napada jedine, ze by se veskere texty s verzovanych tabulek propisovaly do tabulek hlavniho projektu ⇒ neco jak deployment pro preklady …

Ucel mych addonu by byl proste sjednotit preklady a verzovani textu hlavne z netechnickeho hlediska + programatorum usetrit reseni vlastni administrace pro preklady/verzovani/a souvisejici workflow – jen by se napojili na nejake api na urovni komponent (nebo REST)

Chvilkami si rikam ze to je dobry napad, chvilkami, ze nesmysl :) Dneska jsem se dozvedel, ze jinojazycne weby nemaji az tak velkou prioritu, takze na rozmysleni casu dost …

LeonardoCA

Dik za zkusenosti, ja se taky priklanim k db. Git by byl samozrejme pro uzivatele neviditelny, jen jako uloziste misto db, beru to jako jednu z moznosti, protoze v gitu by se jednoduseji resilo verzovani. Tomu reseni prekladu na konkretnim miste se prave chci vyhnout, respektive, mohlo by to byt na kokretnim miste, pomoci nejake unifikovane komponenty + minimalne dashboard s prehledem toho co ma byt prelozeno bez ohledu na to o co se jedna …

Filip Procházka

Pro kdyby/translation si můžeš snadno naimplementovat vlastní loader, který bude načítat překlady z databáze. A když je budeš chtít na produkci načíst/reloadnout, tak jenom zavoláš jednu metodu, která smaže cache v tempu :)

ondrs

Ja bych pouzil uz hotove reseni – http://www.oneskyapp.com/
Umi exporty/importy vsemoznych formatu, ma API a je zdarma.

LeonardoCA

Dik za link