Multijazyčný web – více překladových tabulek
- jozin
- Člen | 14
Zdravím,
řeším teď problém s vícejazyčností webu. Translator
používám, mám ovšem více tabulek s překlady například pro UI prvky,
podstránky, kategorie apod. Pokud bych vždy potřeboval překládat vždy
z jedné tabulky, není problém. Pokud bych měl v každé tabulce unikátní
data (tedy, že by se nemohli křížit názvy v různých překladových
tabulkách), tak by taktéž nebyl problém.
To co řeším je ovšem to, že bych potřeboval překlady ze všech tabulek najednou, ale zase, aby se nestalo, že překlad půjde ze špatné tabulky. Při překladu jsem schopen říct z jaké tabulky by měl jít překlad, ale nenašel jsem žádné řešení kontextem řízeného translatoru.
Moje otázka tedy zní: Jak by se dalo co možná nejelegantněji vyřešit překládání z více tabulek?
- Azathoth
- Člen | 495
Doporučuji Kdyby
Translation
Mám s tím výborné zkušenosti, jazykové mutace ukládáš do .neon
souborů a k jednomu jazyku můžeš mít kolik souborů chceš, takže
můžeš udržet jednotlivé soubory poměrně malé a přehledné.
Editoval Azathoth (17. 9. 2014 16:33)
- jozin
- Člen | 14
Zběžně jsem se na to koukl a to „doménování“, tedy cesta k překladu se mi docela líbí, co je ale problém, že je aplikace postavená tak, že v administraci dochází ke změnám v překladech a musel bych vytvářet neon soubory dynamicky, k tomu je lepší použít databázi, zkusím se ještě podívat, jestli uvedený překladač má možnost propojit se s databází, případně to doimplementuju do mého Translate, tak jako tak díky.
- David Matějka
- Moderator | 6445
@jozin melo by stacit implementovat
Symfony\Component\Translation\Loader\LoaderInterface viz NeonFileLoader
edit: nebo ne? TranslationLoader koukam jede dle filesystemu, zkusim to vykoumat :)
Editoval matej21 (17. 9. 2014 17:38)
- Filip Procházka
- Moderator | 4668
Určitě je dobrý nápad překládat obsah přes Kdyby/Translation? Já bych ani neřekl, imho by to mělo být někde v aplikační logice.
- jozin
- Člen | 14
Filip Procházka napsal(a):
Určitě je dobrý nápad překládat obsah přes Kdyby/Translation? Já bych ani neřekl, imho by to mělo být někde v aplikační logice.
Jak přesně to myslíš? Kdyby nepoužiji, ale chci odtamtud použít ten
doménový styl zápisu co chci použít, jako tabulka.klic či
alias_tabulky.klic. Třída Translator by u mě měla
prakticky dělat jen funkci service, kdy data jen získává z modelu, který
si už řeší odkud vezme data, jestli je případně nějak upraví a
následně vrátí požadovaný překlad. Přemýšlím správným směrem, nebo
jdu úplně blbě?
- akadlec
- Člen | 1326
Obsah překládat přes Translator? Neni to trochu špatná cesta? UI prvky, podstránky, kategori by imho měly být překládány obsahově přes DB pokud se ukládají do DB a to že se aktuálně načte správná jazyková verze už zajistí model. Např. bude tabulka kategorie, kde budou data o kategoriích a k tomu bude třeba druhá tabulka s překlady názvu či popisů kategorií. A model zajistí to že se načtou konkrétní jazykové mutace.
V doctrine se to dá řešit docela elegantně např. pomocí GEDMO či jiné dostupné ext.
- jozin
- Člen | 14
akadlec napsal(a):
Obsah překládat přes Translator? Neni to trochu špatná cesta? UI prvky, podstránky, kategori by imho měly být překládány obsahově přes DB pokud se ukládají do DB a to že se aktuálně načte správná jazyková verze už zajistí model. Např. bude tabulka kategorie, kde budou data o kategoriích a k tomu bude třeba druhá tabulka s překlady názvu či popisů kategorií. A model zajistí to že se načtou konkrétní jazykové mutace.
V doctrine se to dá řešit docela elegantně např. pomocí GEDMO či jiné dostupné ext.
Děkuji za objasnění, říkal jsem si, jak se to má dělat, když
Translator na to očividně není stavěný. Ještě jednou díky a
řekl bych, že téma je vyřešené.
- Jiří Nápravník
- Člen | 710
@akadlec jasně, ja jen dávám další možnost, jak to může řešit. Já třeba řeším překlady přímo po svém, protože to nejsou ani překlady, jako, prostě více jazykových mutací najednou…