Po pěti letech vývoje vyšla česká počítačová hra Scarlet Deer Inn (ProtonDB). Scarlet Deer Inn je vyšívaná temná středověká pohádka. Zatímco život ve zdánlivě obyčejné vesnici se točí kolem běžných povinností a sousedských drbů, v podzemí se skrývají zlověstná tajemství.
Představen byl Raspberry Pi Touch Display 2 s uhlopříčkou 10 palců a rozlišením 1200 × 1920 pixelů. Cena je 80 dolarů.
RPCS3 (Wikipedie), tj. open source emulátor Sony PlayStation 3, snížil minimální požadavky. Nově jsou podporovány starší grafické karty ATI Radeon řady HD 2000, 3000 a 4000 z let 2007 až 2009. Na PC běží už 75 % všech her pro PlayStation 3. V budoucnu bude RPCS3 fungovat bez firmwaru z PS3. V RPCS3 byl implementován systémový modul cellSysmodule (𝕏).
Vyšel open-source nástroj winetop (MIT) — nativní CLI/TUI pro sledování a ukončování Wine, Proton, Lutris, Heroic a Bottles sezení. Seskupuje procesy podle WINEPREFIX / Steam AppId, umí bezpečně zabít jen hru (včetně Steam reaperu) a nabízí i skriptovatelné příkazy (list, kill, orphans, …). Balíčky jsou mimo jiné na crates.io, Copru (dnf copr enable kovariadam/winetop), PPA ppa:kovariadam/winetop a AUR (winetop-bin).
Ve spolupráci společností OpenAI a Work Louder byla představena (𝕏) hardwarová klávesnice Codex Micro pro práci s AI agenty. Cena klávesnice je 230 dolarů.
Byl vydán Mozilla Firefox 153.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 153 bude brzy k dispozici také na Flathubu a Snapcraftu.
V linux-cve-announce bylo oznámeno 433 zranitelností za jediný den (19. července).
Byla vydána nová verze 5.44 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 71 vývojářů. Změněno bylo přibližně 270 tisíc řádků v 1 300 souborech. Přehled novinek a změn v podrobném seznamu.
Na 23. září 2026 je do bratislavské Nové Cvernovky naplánovaná jednodenní konference #nobullshit.camp pro tech leadery, DevOps a platform inženýry. Mají tu zaznít upřímné příběhy z praxe o tom, co v produkčních systémech reálně fungovalo, co se pokazilo a co si z toho lidé odnesli. Témata pokrývají tři oblasti – DevOps a platformy (Kubernetes, cloud, provoz systémů), firemní kulturu a leadership. Program běží ve dvou formátech: hlavní
… více »Byla vydána nová verze 1.58 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Josephine Pfeiffer. Vypíchnout lze možnost nmtui zobrazit nastavení Wi-Fi jako QR kód nebo podporu CLAT (464XLAT) a tunelů GENEVE (Generic Network Virtualization Encapsulation).
{
"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: