Překlady s vloženou proměnnou

kamil_v napsal(a):

Napiš si vlastní Translator, který implementuje \Nette\Localization\ITranslator.

Dobře, díky, sice přesně tomu jsem se chtěl vyhnout, ale když to jinak nepůjde…

Ještě bych měl jeden dotaz, v normálním PHP projektu si připravím POT file, kde je v hlavičce i toto (viz. např. zde):

`
„X-Poedit-KeywordsList: "
“__;_e;esc_html_e;„
"esc_html_x:1,2c;“
„esc_html__;esc_attr_e;“
„esc_attr_x:1,2c;“
„esc_attr__;_ex:1,2c;“
„_nx:4c,1,2;“
„_nx_noop:4c,1,2;_x:1,2c;“
„_n:1,2;_n_noop:1,2;“
„__ngettext:1,2;“
„__ngettext_noop:1,2;_c,“
„_nc:4c,1,2\n“
`

Což mi označuje funkce, které pak gettext bere, jako ty, které nesou překlad (i s rozlišením plurálu, komentáři atp…) → nevíte, jak toto funguje pro Latte?

Editoval ondrejd (18. 2. 2019 15:37)

neznamy_uzivatel napsal(a):

Používám Kdyby/Translation (https://github.com/…/Translation)
překlady v neonech:
blbiny.neon:

prekladneceho: "Budeš vydělávat %masakry% Kč každej měsíc!"

latte:

<p>
  {_blbiny.prekladneceho,  ['masakry' => '1.50']}
</p>

Jak jsem psal v úvodním dotazu, velmi rád bych zachoval systém PO/MO souborů → pokud lokalizátorovi pošlu NEON, tak to skončí katastrofou, protože jsou všichni zvyklí na Poedit.

Nehledě na to, že Gettext toho umí prostě víc → v tom Poeditu mají i vizuálně krásně ukázány verze s plurály, mohu tam i do zdrojáků přidat poznámku, která se pak lokalizátorovi v Poeditu znovu objeví (např. Nepřekládat atp.)

Navíc je Gettext de facto průmyslový standard pro překlady ve světě open-source → nerad bych vymýšlel znovu kolo, obzvláště pokud bude mít místo gumy jen dřevěný ráfky…

Editoval ondrejd (18. 2. 2019 15:41)

neznamy_uzivatel napsal(a):

Ono to je založené na Symfony/Translation a .mo .po tam lze použít.
Já to používám s tím neonem, protože je generujeme je z administrace z blbuvzdorného prostředí pro překlady :)

V zásadě jde po/mo použít, to vím, ale u jiných projektů, prostě otevřu Poedit, nastavím nový projekt, nastavím jazyk, kódování a cestu ke zdrojákům. Dle keywords mi to ty zdrojáky projde a vytvoří základní POT soubor → při změně ve zdrojácích, to zase v Poeditu jen aktualizuju a hned vidím (a překladatelé) řetězce k přeložení. Nešlo by něco takto jednoduchého?

Editoval ondrejd (18. 2. 2019 16:15)

Rozumím, díky všem za odpovědi, holt s tím budu muset bojovat sám. Velká škoda, že někdo považoval za zlepšení narvat Nette/Latte do čistého Zend Framework projektu – ale s tím už nic nenadělám.

Martk napsal(a):

Máš několik možností:

1. Extrahovat přes svůj skript překlady do .php souboru

„Vytvořit“ si vlastní extrátor v po editu a

2. Vytvořit si makro a můžeš psát takhle

{_ 'Some translation with number %d', [15]}

3. Psát to takhle

<p>{ sprintf( _( "Some translation with number %d", "namespace" ), 15 ) ) }</p>

A asi nejlepší řešením je inspirovat se a napsat podle tohoto extrátor pro latte, imho to bude velmi podobné.

Díky za odpověď, nicméně:

add 1) přesně tohle dělal gettext sám o sobě, ne nutnost psát další PHP skript (protože už i tak mám práce dost)
add 2) tak toto by mě zajímalo, ale jen ze zvědavosti – znovu psát extraktor je vynalézání kola, které už fungovalo
add 3) takto to řeším teď, jen by mě zajímalo, na co mi vlastně to Latte je, když ho budu obcházet :( → ale zatím to tak nadále řešit budu, protože stále trvám na tom, že nechci vynalézat nové kolo (extraktor), ale použít normálně fungující Gettext, který PHP běžně zpracovává.

Bohužel toto je nevýhoda frameworků dělaných na koleni jedním člověkem – tam, kde existuje nějaký standard (gettext), by měl být použit, ovšem autor frameworku má pochopitelně právo si to „dělat po svém“… já pak musím prostě zatnout zuby. Jen nepochopím, proč někdo z neznalosti angličtiny a neschopnosti naučit se profesionální framework, který notabene dělá stejná firma, jako nejpoužívanější PHP interpret, tam našroubuje jiný, a když zjistí, že to nezvládne tak zdrhne a někdo jiný to pak musí řešit a nachází věci, které prostě dobré řešení nemají, protože každý asi chápe, že ve firmě mi nedají rok na to, abych to zase přepsal.

Každopádně, ať nevypadám tak mrzoutsky → děkuju za snahu mi odpovědět → tzn. díky.

Editoval ondrejd (19. 2. 2019 13:49)

Mimo téma

Není to vynalézání kola, protože žádný extrátor pro latte neexistuje.

Pleteš si to, latte není gettext extrátor, ale template engine, takže nevím o jakém obcházení tu je řeč. Když jsem se v rychlosti podíval na zend 3, tak to jsou php soubory, a dávají tam jen funkce navíc… Proto poedit to extrahuje bez problému, kdyby používal template engine, tak si taky musí (někdo z komunity) vytvořit vlastní extrátor.

Další důležitá věc, že zend framework nevede vývoj php.

K tématu

Potřebovat to, tak to klidně vytvořím, takhle nemám důvod. Funguje to na úplně jednoduchém principu, nástroj zkompiluje přes template engine soubory do *.php a pak to projede jen xgettextem.

proč v šablonovacím jazyce (a tím PHP de facto je) ještě vynalézat šablony, když vše zvládne PHP samotné

protože PHP je velmi špatný jazyk pro psaní šablon. proto skoro každý (člověk i fw) používá nějaký šablonovací systém – ať už latte, twig nebo blade.

včetně chybějícího/nevyhovujícího syntaxhiglightingu ve většině editorů/IDE

ve kterých?

takže běžnej frontenďák rozhodně bude radši za pěkně napsané HTML + PHP než za Latte (dle mé zkušenosti).

dle mé zkušenosti je to naopak. a označovat šablony napsané v čistém html + php za pěkné.. no..

Stejně tak i důvod bezpečnosti je passé → každá další vrstva přináší dle Murphyho zákonů další chyby…

tak tahle poznámka už je úplně mimo.

opravdu ti připadá následující kód přehlednější:

<?php if ($items): ?>
	<?php $counter = 1 ?>
	<ul>
	<?php foreach ($items as $item): ?>
		<li id="item-<?php echo $counter++ ?>"><?php
		echo htmlSpecialChars(mb_convert_case($item, MB_CASE_TITLE)) ?>
		</li>
	<?php endforeach ?>
	</ul>
<?php endif?>

než

<ul n:if="$items">
{foreach $items as $item}
	<li id="item-{$iterator->counter}">{$item|capitalize}</li>
{/foreach}
</ul>

A Murphyho zákony, že jsou mimo? V každém kusu kódu je chyba, tzn. více kusů kódů znamená více chyb.

skoro bych řekl, že jen tím, že šablony neobsahují milionkrát htmlSpecialChars, tak to ušetřilo víc kódu, než je v celém latte :)

že je lepší používat framework od firmy, která dělá i nejpoužívanější PHP interpret

role zendu ve vývoji php engine není (již) tak významná, doporučuji přečíst http://zsuraski.blogspot.com/…nd-zend.html … navíc je to úplně nerelevantní argument k nette vs zend fw

A pokud mi pak kolega v práci začne vykládat, že Laďenka je lepší než Zend Debugger, no tak to jdu do kolen

tim je myšlený ta php extension, co řeší debugging? to je ale docela jiný use case, než co řeší laděnka

Pokud si chceš něco přečíst o výhodách Latte, doporučuji https://latte.nette.org/. Má skvělou dokumentaci, stejně jako zbytek Nette. Během existence Nette v něm bylo objeveno naprosté jen minimum bezpečnostních chyb. Jak vidíš, i v malém týmu se dá dělat framework, který si nic nezadá se světovou konkurencí.

David Grudl napsal(a):

Pokud si chceš něco přečíst o výhodách Latte, doporučuji https://latte.nette.org/. Má skvělou dokumentaci, stejně jako zbytek Nette. Během existence Nette v něm bylo objeveno naprosté jen minimum bezpečnostních chyb. Jak vidíš, i v malém týmu se dá dělat framework, který si nic nezadá se světovou konkurencí.

V tomto vaše úsilí vůbec nezpochybňuji, mně samotné Nette problémy nedělá, jen mi vadí drobnosti na které nejsem zvyklý :) → jako je to Latte (např. stylování formulářů ve spojitosti s Bootstrapem, musím říci, že s láskou vzpomínám na stařičký Zend_Form_Decorator → to bylo jedno z nejfunkčnějších řešení tohoto problému), další věc jsou ty lokalizace, prostě nepochopím, proč vymýšlet kolo, když tu máme Gettext. A Neon? Schéma k tomu nepřipojím, čitelný je to stejně jako prostý PHP soubor s polem, takže nevidím žádný přínos.

Každopádně zrovna Vás bych si kritizovat nedovolil :)

Ještě bych dodal, že část z mých poznámek vznikla z frustrace, kdy na vás tlačí manager a před sebou máte kód, kdy předchozí programátor, řešil problémy novým frameworkem/knihovnou (např. tu byly tři adaptéry pro db – původní ZF, pak 2× použito Nette/Db a do toho ještě Illuminate …), to samé ve všech ostatních částech (nejen PHP, ale i JS či CSS) a vyčistit to, když tu službu používá tisíce lidí, aby mohl vývoj pokračovat je prostě opruz :) … nehledě na to, že z mého pohledu přiroubovat k ZF Nette nedává smysl, protože oba frameworky vyznávají jinou filozofii a není nic co by Nette přinášelo a ZF nezvládlo… to neznamená, že nevidím kolik kvalitní práce za Nette je… Znovu se omlouvám jestli jsem se Vás dotkl.

Editoval ondrejd (20. 2. 2019 9:48)

ondrejd napsal(a):

h4kuna napsal(a):

@ondrejd Aby jsi nezačínal se psaním na zelený louce mám tu vytvořený překladač pro gettext, ale už ho nepoužívám takže není udržovaný. Nicméně řeší spoustu věcí co jsi psal
Pokud chceš klidně ti repozitář přenechám nebo odbavím PR.

Osobně bych použil symfony/translator má výhody v tom že s těmy slovníky se lépe manipuluje.

A neposlal by jsi mi pls. odkaz na tu repozitory? Díky.

Máš ho v té jeho odpovědi, byť trochu nešťastně umístěný :D Zde je