SE - překlady do ČJ #47
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#47
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
V plánu mám další kolo úpravy překladu, protože jsem pochopil komplikace synonym v SE.
Aby se v SE některé výrazy přeložily konzistentně, tak jsou pro exportní XLS sdruženy na jeden řádek. Tedy výraz patří k více různým výrazům na různých místech a modulech.
Paráda pro angličtinu, ale peklo pro češtinu.
Budu muset toto sdružení oddělit a důsledně překládat jednotlivé výrazy tak, jak mají mít význam v daném místě. Jinak se nedá dobrat kvalitního překladu.
Mým výstupem by tedy asi nebyl jeden přeložený dataset, ale více datasetů dělených na jednotlivé moduly ... a v součtu mnohem více přeložených řádek.
Máte k tomu nějakou další technickou poznámku, co bych měl udělat? Případně koincidence s něčím?
momentálně vypadá úprava textu takto v příloze a teprv zkoumáním termínů v konkrétních modulech jsem dokázal odhalit, že Zóny jsou v případě Hasičů Okrsky... :))
stále však nevím jak se importer vypořádá s duplicitními anglickými názvy, nebo změnami v souborech.
konkrétně např. v modulu Fire se dělaly opravy kódu.
tento překladový soubor vznikl exportem ještě před opravami
takže asi budu muset udělat ještě update.
všiml jsem si že tu je nějaká novinka, jako např.
0_překlad_cz4_translate.xls
Toto není možné. Překlad funguje jednoduše tak, že ve zdrojovém kódu je
A v překladové tabulce prostě
Žádná příslušnost k modulu nebo místu, kde se překlad vyskytuje zachována není. Ta existuje pouze v exportovaném CSV, aby překladatel mohl lokalizovat kontext, nicméně jak je jednou přeloženo, kontext nehraje roli.
tady si troufnu podnět k položení konkrétního dotazu na F+D..
Jen bych nerad, aby mi znovu zopakovali, že lokalizace je možná, ale že vědí že má mouchy.. To totiž už od nich vím cca od roku 2014, tím bychom se neposunuli :)
V Sahaně je možné aktualizovat překlad i bez asistence a vstupu do kódu modulů a to už víme..
A to pochopitelně i po jednotlivých modulech, které mají zhusta identické termity.
Proto je tam taky checkbox, že se stahuje konkrétní modul včetně "core" termínů, které jsou patrně společné a nejsou přesně v konkrétním modulu. Jenže tohle mi nikdo dlouho neřekl a já neobjevil, protože pro angličany to "není issue".
Vyvozuji, kdyby to bylo skutečně tak, že přeložením jednoho výrazu v jednom modulu se přeložený výraz zobrazí ve všech modulech (aniž by o to někdo stál) pak by vaše tvrzení byla pravda.
Pokud se takový výraz zpětným uploadem přeloží skutečně jen v modulu, z kterého pochází zdroj, pak opět vyvozuji, že se tím dá udělat přesnější překlad s rozlišením synonym.
Jenže tohle mi nešlo ověřit, importní formulář Sahany stále vyhazoval chybu a tím jsem v mém testu skončil. Proto tu diskutujeme pořád dokola jak to je v kódu, místo abych prostě pomalu ale jistě udělal zpřesňující překlad svými importy.
Dotaz na F+D by tedy zněl: **Jak nejspolehlivěji a technicky dobře zařídit oddělené překlady slov, které v angličtině jsou stejné, ale v jiném jazyku rozdílné? Jak si neničit vlastní překlad v konkrétním modulu, pokud importer ignoruje tento, angličanovi neviditelný, ale jinak zjevný rozdíl v pojmenování různých věcí? ** Bavíme se o uživatelském uploadu, který tam zjevně na to je.
Odpověď "tak jestli jde o jedno slovo, udělejte si to v kódu ručně" mi přijde sice řešením, ale jak vidno, zrovna toto je řešením nesystémovým a strašně zdlouhavým. trápím se s tím už několik dlouhých let, protože pořád toužím vidět, že import lokalizovatelných termínů funguje jak se dá čekat. Bez asistence. Priority jsou pochopitelně stále jiné.
(nepěkná představa, kdyby mi delegovaný uživatel navrhoval jazykovou modifikaci Sahany a touto změnou bychom si spíš zkomplikovali život, než vylepšili překlad.)
Nediskutuji, pouze konstatuji holá fakta :) Falešný dojem toho, že jednotlivé moduly je možno lokalizovat odděleně jste získal od mého předchůdce, který se Vám snažil tvrdit, že název souboru a číslo řádku v exportu má nějaký význam. Již jsme si v praxi ověřili, že nemá.
OK, věřím, že tohle je konstruktivní dotaz, nicméně by bylo vhodné jej podpořit nějakým konkrétním případem. Nejsme první, kdo se pokouší o lokalizaci, takže bych čekal, že se s tímto problémem již pracovalo i lépe než tak, jak uvádíte v prvním odstavci. Nicméně opět očekávám, že to celé stojí a padá na použitém frameworku. Oproti Djangu, které používají ostatní aplikace a které skutečně lokalizaci modulů umožňuje, mi Web2py připadá jako něčí bakalářská práce, kde je implementováno naprosté minimum, jen aby to prošlo obhajobou.
ok, ... souhlas. posunuli jsme se směrem k tomu dotazu. :) Na položení nespěchám, nechám na vás.
respektive, zkusím sem doplnit ten příklad...
mentioned in issue #65
mentioned in issue #198
mentioned in issue #53
dlší část překladu pod žlutou čarou.
sahana_translate_dodatky.xlsx
mentioned in commit
c9591ed649Překlady přidány. Co se týká míst, kde má být přeložen nějaký stav - tj. u pohřešovaných missing nebo u typů CAP zpráv update - tyhle hodnoty se berou z enumů natvrdo definovaných v kódu a nepoužívá se
T()funkce. Otevřu na to později issue.další část překladů v XLS tabulce, nejnovější jsou pod oranžovou dělící čarou.
určitě ještě někde něco zbývá, například některé kontextové nápovědy, které nejdou copy+paste
sahana_translate_dodatky.xlsx
další část překladů v tabulce, jsou to různá chybová hlášení, která se objevují na více místech.
jsou pod červenou dělící čarou v XLS sahana_translate_dodatky.xlsx
ještě jsem přidal další překlady, poslední jsou pod zelenou čarou.
teď počkám jestli se vám to podaří vnutit do rozhraní, :)
sahana_translate_dodatky.xlsx
komplet to asi nebude. Ale už se motám v kruhu.
Zkuste mi prosím naznačit co se bude dít v dalších dnech.
Pro mne by bylo fajn, kdybyste zareportoval vše, co se dá reportovat jako issue a pak už je relativně méně podstatné, jak, kdo nebo kdy to vyřeší.
Máte něco, co bych měl ohledně plánu vědět, nebo posoudit?
mentioned in commit
5f1b157f0bPřeklady upraveny nebo přidány, jak možnosti dovolovaly. Mám k tomu několik poznámek.
Pořád z toho vašeho vstupu nemám pocit, že došlo k porozumění, jak ty překlady (ne)fungují. Nic jako rozlišení na jednotlivé moduly tu neexistuje a i kdyby existovalo, problém to neřeší.
Nametedy prostě bude vždy přeloženo stejně nehledě na to v jakém modulu nebo souboru se nachází a nehledě na to, jak moc si přejete, aby bylo na některých místech přeloženo jinak. Totéž i překladatelské oříšky u kterých záleží na kontextu, třebaEnabled, které se dá přeložit jako Aktivní, Aktivováno, Zapnuto, Ano, Povoleno, Umožněno nebo dalšími slovy, které v daném kontextu zachovají smysl. Důvod, proč by ani rozdělení do modulů nic neřešilo, je třeba slovoOpen. V modulu úkrytů byste jej chtěl přeložit jako Otevřeno, protože v kontextu stavu úkrytu to má smysl. V úplně stejném modulu, ale máte totéž slovo i pro otevření záznamu k editaci, kde už by ale dávalo smysl jej přeložit jako Otevřít.Samozřejmě vám nebráním jakoukoliv diskusi na toto téma s F&B otevřít, ale očekávám, že budou chtít slyšet návrh, jak situaci řešit a tady vám bohužel nebudu schopen pomoci. Taková situace se v Sahaně řešit nedá, protože systém překladů závisí na Web2py. A i kdyby nezávisel, je extrémně těžké vytvořit takový systém, ve kterém by ke zmíněným konfliktům nedocházelo. Sám třeba skrze Transifex občas překládám do češtiny NextCloud, který to rozdělení do modulů má a dokonce v něm existuje i systém, který umí ohýbat řetězce v závislosti na hodnotě proměnné (Nemáte žádné zprávy, Máte 1 zprávu, Máte 2-3-4 zprávy, Máte 5+ zpráv) a ani tyhle super featury, o kterých si Web2py může nechat jen zdát, to neřeší.
K překladům samotným - Abychom předešli zbytečným kolečkům o tom, co není přeloženo a co přeloženo je, ale zobrazuje se bez překladu, máme v repozitáři soubor s českým překladem tak, jak jej žere Sahana. Můžete tedy do tohoto souboru vždy nakouknout, přes Ctrl+F vyhledat řetězec a pokud bude v souboru přítomen, tak pak zafňukat, že se nepřekládá. Velikosti písmen a počet mezer jsou signifikantní, takže pokud je v souboru přítomno jen
blabla, pakBlablav velkým B přeloženo nebude a je nutno jej přidat.Na závěr ještě má nemístná poznámka ke konkrétnímu překladu -
Descriptionbych překládal jako Popis, tedy tak, jak jsme to měli před posledním commitem. Poznámka by byla Note nebo tak něco. A pak jste tam měl pár řetězců, které byly úplně mimo (Opravdu chcete opustit tuto stranu? a dva následující), protože pocházely z javascriptových oken generovaných přímo vaším prohlížečem.A k vašemu dotazu o tom, co se bude dít v dalších dnech - návrh z post-Dockerového mailu stále platí. Proderu se kritickými issues, zkusím postavit ODK a pak jste na mě měl nějaké požadavky kolem dokumentace. V současnosti se mi zase rozjel projekt v mém skutečném zaměstnání, takže toho nebudu stíhat tolik jako v minulých týdnech. Včera jsem třeba měl mít dovolenou a místo toho jsem skončil s normální šichtou a dvěma hodinami přesčasu navrch. Nepředpokládám ale, že by se takto exponovaný stav měl udržet nějak dlouho. Snad to sfouknu během příštího týdne a pak už to bude lepší.
ok, díky za vysvětlení. Okolnost s češtinou jsem pochopil už jak jste to prvně vysvětlil.
Nerozuměl jsem do důsledku postupu, jakým budou změny kódu (tj. nemyslím změny překladu) promítnuty do Sahany.
Navrhl jste, ať překlady píšu do tabulky, že je tam přidáte. Tak jsem to začal psát do tabulky. Sloupce o místě a modulu byly spíš orientační. Předpokládal jsem, že dosud nepřeložitelný termín najdete na konkrétním místě. V kódu, kde je chybějící funkce T() ji doplníte a tím se stane přeložitelným. Později tyto soubory s doplněnými T() pošlete jako PR, kde je Dominic posoudí a schválí.
To byla moje představa o postupu. Nezávislá na tom, jak moc kvalitní bude můj překlad. Už asi vím, kde vznikl můj omyl. Představoval jsem si, že slovní řetězec k překladu je lokalizovatelný přesněji, ještě podle nějakého identifikátoru, nejen tím, co obsahuje. Snad podle toho, v jakém modulu je. Ale to tak zjevně není. Moje dedukce byla z dřívějšího info, týkajícího se stylování frontendu, kde prý každý objekt na straně je identifikovatelný. (a proto stylovatelný) No, ale tady jsem už mimo, protože nemám úplně dobrou znalost o tom, jak moc aplikační kód, lokalizace, různé frameworky a frontend spolu souvisejí. Víc se domnívám, než bych věděl.
Vy to upřesňujete, že aby byly vyloučeny výše zmíněné problémy, tak na to je potřeba udělat Issue. A ano, už dočítám, jak moc velký zásah by to byl. Což mi dochází, proč v jiných jazycích použitých v Sahaně jsou tak nedostatečné překlady. Dřív jsem si to vysvětloval, že vznikly v době, kdy nebyla aplikace tak rozsáhlá a později už to nikdo neudělal. Teď spíš soudím, že úplný překlad do jazyků vzdálených angličtině byl už dřív problém, právě z těchto důvodů. Změny kódu kvůli překladu musí být dvojí. Jak ty drobné, tak ty principiální.
Proto to ode mne ty kroky směřující k překladu působí poněkud nejapně.
Odpovědět F&D jak to řešit taky sám neumím. Jak píšete, tak to momentálně přesahuje možnosti Sahany. Takže při mých současných možnostech se budu muset spokojit jen s těmi kosmetickými změnami. S těmi principielními, které by zcela vyčešily problém to nechat na někoho jiného.
to ostatní... děkuji a pokusím se zlepšit svůj výstup. Orientace v repository je pro mne trochu potíž, když nevím co přesně mám hledat a zda to náhodou vlastně není na githubu ve zdroji.
Místo hlubokých zásahů do kódu by vyhovělo diverzifikované anglické pojmenování zpřesněním textu. Nebo tam kde to nejde, tak nějakým přidaným znakem (číslicí?). Imho číslice by mohla být reference na budoucí help v uživatelské dokumentaci. úprava by mohla vyřešit naprostou většinu jazykových konfliktů.
#zas_jeden_divny_napad
changed milestone to %2
closed