Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
{
"name": {
"cs_CZ": "Název pluginu",
"en_GB": "Plugin name"
},
"found-msg": {
"cs_CZ": [
"Nalezena %d položka.",
"Nalezeny %d položky.",
"Nalezeno %d položek."
],
"en_GB": [
"Found %d item.",
"Found %d items."
]
}
"sql-table": "Items",
"entity-class": "\\Plugin\\Items",
"some-numbers": [ 123, 45, 67, 89, 10 ]
}
Přemýšlím, jak JSON konfiguráky provázat s gettextem a umožnit nějak kultivovaně hledat, co bylo přeloženo a co ještě nikoliv. Zádrhel je v tom, že něco přeloženo má být ("name", "found-msg"), ale spousta věcí být přeložena nesmí ("sql-table", "entity-class"). Přitom to jsou v podstatě uživatelská data editovaná z administračního rozhraní, takže to nesmí být provázané s gettextem příliš...
"translatable": { } a nad tím pracovat v nějakým „chytřejším“ jazyce, co umí (de)serializovat JSON text a pracovat s tím civilizovaně objektově – na straně klienta třeba JavaScript, na serveru si představím třeba Ruby. Samozřejmě to vůbec nemusí pasovat do tvé use-case, ale to by chtělo asi hlubší popis problému a prostředí.
config.json:
{
"name": "$name",
"found-msg": "$found-msg",
"sql-table": "Items",
"entity-class": "\\Plugin\\Items",
"some-numbers": [ 123, 45, 67, 89, 10 ]
}
config.en_GB.json:
{
"info": {
// metadata o prekladu
},
"strings": {
"$name": "Plugin name",
"$found-msg": [
"Found %d item.",
"Found %d items."
]
}
}
config.cs_CZ.json:
{
"info": {
},
"strings": {
"$name": "Název pluginu",
"$found-msg": [
"Nalezena %d položka.",
"Nalezeny %d položky.",
"Nalezeno %d položek."
]
}
}
{
"languages": [
"en_GB",
"cs_CZ"
],
"strings": {
"name": {
"cs_CZ": "Název pluginu",
"en_GB": "Plugin name"
},
"found-msg": {
"cs_CZ": [
"Nalezena %d položka.",
"Nalezeny %d položky.",
"Nalezeno %d položek."
],
"en_GB": [
"Found %d item.",
"Found %d items."
]
}
},
"sql-table": "Items",
"entity-class": "\\Plugin\\Items",
"some-numbers": [ 123, 45, 67, 89, 10 ]
}
Je to v podstatě tvůj původní formát, jen vede přeložitelné řetězce izolovaně v jednom objektu, kde je objektově dobře najdeš. Odtud je něčím, co rozumí JSON syntaxi, můžeš vytáhnout do objektů a zpracovávat po jednom jak je potřeba, aniž by ses dostal na atributy, na který se nešahá. Rozdělovat to na víc souborů ani práce s čistě find/replace toolem není asi na tohle moc ideální, ale jak jsem psal, využitelnost závisí na případu použití.
xml:lang. Třeba takhle, samozřejmě to jde strukturovat i více nebo méně:
<config> <name xml:lang="cs_CZ">Název pluginu</name> <name xml:lang="en_GB">Plugin name</name> <found-msg xml:lang="cs_CZ" lower-bound="1" upper-bound="1">Nalezena %d položka.</found-msg> <found-msg xml:lang="cs_CZ" lower-bound="2" upper-bound="4">Nalezeny %d položky.</found-msg> <found-msg xml:lang="cs_CZ" lower-bound="5">Nalezeno %d položek.</found-msg> <found-msg xml:lang="en_GB" lower-bound="1" upper-bound="1">Found %d item.</found-msg> <found-msg xml:lang="en_GB" lower-bound="2">Found %d items.</found-msg> <sql-table>Items</sql-table> <entity-class>\Plugin\Items</entity-class> <some-numbers>123</some-numbers> <some-numbers>45</some-numbers> <some-numbers>67</some-numbers> <some-numbers>89</some-numbers> <some-numbers>10</some-numbers> </config>
Tiskni
Sdílej: