Klient chce měnit jazykový soubor

Landsman napsal(a):

Ahoj,

mám tu takový požadavek, že by si klient (poměrně technicky zdatný) rád měnil hodnoty v jazykovém souboru. Přemýšlím jakým způsobem mu to umožnit. Ideální by samozřejmě bylo, aby je mohl měnit například bez nutnosti stahovat z FTP, otevírat soubory, ale přímo na webu například prostřednictvím Tracy baru a navázat to na aktivní session administrátora. I tak se mi tam ale kříží verzování celé app, tzn. hrozí že mu můžu při deployi z gitu přepsat jeho změny.

Používáme Kdyby/Translation, ale změnám se nebráním.
Docela se mi líbí řešení https://github.com/…veTranslator, ale zkušenost s ním nemám.

Napadá Vás nějaké řešení?

díky

Načítej ty data z DB. Kdyby/Translation má na to podporu.
Do Tracy bych to nedával, protože „zákazník“ nepotřebuju debug tool, je to bad practice.

Napsal bych si na to vlasní „komponentu“, která by se dala zapnout třeba z administrace jen pro konkrétního uživatele, kde by bylo umožněno upravovat ty data v DB.

Editoval Pavel Macháň (17. 7. 2016 17:33)

Hug0 napsal(a):

Ahoj,
taky bych šel cestou DB. Akorát bych místo Kdyby/Translation použil DoctrineBehaviors. Kdyby/Translation se hodí spíš na překlady hlášek aplikace, ne obsahu …ale jde to i s Kdyby/Translation.

Obsah jako takový překládat nebudu, ale mám ruzné věci v šablonách, které jsem dal právě do jazykových souborů (nadpisy, tlačítka, krátké popisky, …). Pokud budu řešit mutaci jako takovou, tak asi v rámci oddělených databází, protože to nebude 1:1.

Hug0 napsal(a):

Landsman napsal(a):

Hug0 napsal(a):

Ahoj,
taky bych šel cestou DB. Akorát bych místo Kdyby/Translation použil DoctrineBehaviors. Kdyby/Translation se hodí spíš na překlady hlášek aplikace, ne obsahu …ale jde to i s Kdyby/Translation.

Obsah jako takový překládat nebudu, ale mám ruzné věci v šablonách, které jsem dal právě do jazykových souborů (nadpisy, tlačítka, krátké popisky, …). Pokud budu řešit mutaci jako takovou, tak asi v rámci oddělených databází, protože to nebude 1:1.

Aha, tak potom to bude docela oříšek. Myslím, že pokud k tomu neuděláš nějaké rozhraní, tak bude dost těžké udržovat soubory aktuální – ať už z pohledu aktualizací (a deploye), tak z pohledu zákazníka, který ti to bude měnit pod rukama. Nehledě na to, že jestli je to v *.neon souborech, tak by to mohl rozbít nějakou špatnou syntaxí…nebo ne? :-)

Ano přesně tak, proto se mi líbila možnost typu toho debug baru. Vím, že to není nejlepší praktika, ale předpokládám, že ten formulář má validaci, escapuje zakázané znaky, syntaxi. Pokud by byl navázán na login administrátora, mělo by to být v pohodě.

Editoval Landsman (17. 7. 2016 19:27)

Překlady doporučuju outsourcovat a klienta ke kódu vůbec nepouštět.

Skvěle na to funguje služba Loco – https://localise.biz/. Ta taky usnaďnuje překlady do dalších jazyků bez nutnosti zaučovat překladatele do databáze, neon-syntaxe a podobných složitostí.

V praxi je vlastně o export (z applikace do Loca) nebo import (z Loca do aplikace) jednoho souboru.

K inspiraci je tu bundle Happyr/TranslationBundle:
Nebo jeho autora barvitější článek o cestě a důvodech k výběru Loca.

V neonu preklady key: value. vypisuji je vsechny najednou a klient si prelozi, prepisu neon soubor a smazu cache s kdyby/translator je tam nejaka podpora na invalidaci i

Mam myslim taky zanoreni – jen dvouruovnove a neni problem… Validaci nemyslim, myslim jen invalidaci, protoze ten neon se cachuje, tak aby se nacetl novy.