Fordítás hogyan - Gyakori hibák

Egy nagyon jó bejegyzés született a HupWiki-be, Fordítás HOGYAN/Gyakori hibák címmel. Szinte alig van benne mit kiegészíteni, noha azért akad:

  • Igaz, hogy pont után nem teszünk kettő szóközt. Ez alól kivétel a string vége, ugyanis ennek akár design okai is lehetnek. Akárhány szóköz van a string végén, azt tartsuk meg, mert... mert csak.
  • Gyorsbillentyűk (mnemonikok, accelerátorok...): Van egy fontos szabály: érdemes úgy megfogalmazni a fordítást, hogy a gyorsbillentyű-prefixummal ellátott betű szerepeljen benne. Ha erre nincs mód (és a legtöbb esetben sajnos nincs), akkor viszont oda kell figyelni, hogy az adott blokkon belül egységesek legyünk.
    Onnét lehet felismerni, hogy egy ilyen blokkon belül vagyunk, hogy vagy mindegyik, vagy minden második string ilyen.

( kelemengabor | 2009. 07. 20., h – 14:54 )

Hát igen, van úgy hogy a felület jobban néz ki akkor, ha tesz egy szóközt a végére a kedves programozó, és gyorsabban is megvan mint a megfelelő térköz beállításával. Máshol ezt a mentalitást úgy figyelték meg, hogy "Gizike, aki még mindig szóközökkel teszi sorkizárttá a dokumentumot Wordben". Szóval ez inkább kozmetikai jellegű bug, amit rövid távon így ki lehet kerülni.

A másikkal meg részben nem értek egyet, miért kéne ugyanazt a gyorsbillentyűt használni magyarul, mint angolul? Ebből remek hajánál fogva előrángatott fordításokat lehet generálni, csak azért mert "abban van v, ami angolul a gyorsbillentyű".
Másrészt, a blokkok figyelése hogy ne legyen ütközés, jó ötlet (sőt még: lehetőleg a nyelvben ritkábban használt betűk előnyben részesítése, pl c,d,v,o,u,z), csak itt-ott elég nehezen kivitelezhető, tudva hogy pl az intltool+glade fájl használatakor a glade fájl sztringjeit az intltool ábécérendbe rakja be a *.glade.h-ba és onnan a po-ba, aztán abból mondd meg hogy melyikek tartoznak egybe... szóval szerintem ezek kombinációja és a tesztelés a teljesen megbízható módszer :).

Megyek is és bővítem ezekkel, köszi hogy felhívtad a figyelmet.

Na most, en alapvetoen Qt fordito vagyok, ott kontextusok vannak. Igen, tudom, hogy a po az nem ts, de neha ott is vannak jobbfajta forditasok.

Ami az ugyanoda esest illeti: Egyreszt nem kotelezo ervenyu, nyilvan irtam is, hogy a legtobb esetben ez nem jon ossze. Am ha lehet, miert ne? En rengeteg dolgot hasznalok ugy, hogy pl. Alt-Space-X amitol maximalizalt lesz egy gnome ablak. Ertheto felhasznalokent az a kivansag, hogy amit egyszer megtanultam kombinacio, az ha lehet, ne valtozzon a forditassal. Persze abszolut igazad van, a legtobb esetben erre nincs mod, es amit irtam nem kotelezo ervenyu olyan ertelemben, hogy mindenkepp igy kellene a leforditott szot kivalasztani. Viszont, ha a _Save a leforditando, akkor a forditas ne az legyen mar, hogy M_entés, hanem hogy Menté_s mert igy nem veszik el az accelerator.

Sztringvegi szokoz: Nem csak ilyen ertelemben gondoltam a design resze kifejezesre. Peldaul, van egymasutan harom label, a kozepsoben valami akarmi szoveg van, a ket szelsoben fix; esetleg van ket label, kozte valami akarmicsoda elem. Tudom, hogy ki lehet ugy is alakitani, hogy label1 %s label3, de ha egyszer igy lett megoldva, annak lehet, hogy oka volt. Mindnesetre itt is ki kell rakni a szokozt, mert az elso ket label szovegszerusegi helyzete fugg ettol.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igen, ez engem is idegesít, hogy mondjuk nyomok egy ctrl-s-t, és ahelyett, hogy mentene, nyelvtől függő érdekes dolgok történnek, pl. portugál word-ben félkövér lesz a szöveg.

Tudom, hogy most nem erről volt szó, hanem a menün belül megjelenő szövegekről, csak azt akartam mondani, hogy bizony hasznos arra törekedni, hogy ha egy mód van rá, akkor az eredeti kombináció ne változzék

Hát nem tudom, hányan lehetnek akik egy program angol verziójáról váltanak a magyarra? Mondjuk ha először készül el a fordítás, akkor nyilván sokan, de amúgy?

A lehet hogy oka volt témára: igen, a programozó lustasága. Szerintem ha a fordítón múlik a program megjelenése, akár úgy hogy hány szóközt tesz, akár úgy hogy sikerül-e átmásolni a pango markupot (vagy úgy jár, mint én egy korai braseroval - úgy nézett ki a nyitóablak az elszúrt markup miatt, mint a goatse), az programhiba. Mondjuk mivel ópenszószban eléggé jellemző a "csak forduljon már le ez a szar" mentalitás, és ilyen apróságokra már nem figyelnek, így szerintem inkább trehányság, mint tudatos döntés. Nem hiszem, hogy a programozónak lehetővé kéne/szabad tennie hogy a fordító a szöveg jelentésén kívül a megjelenését is elronthassa.

Pontosan errol van szo. Ma meg nem tartunk ott, hogy addig nem released egy program, amig legalabb X nyelvre nincs leforditva. Ha tortenetesen epp oroszul van fejlesztve, akkor, amikor a program maga eleri a "mar mukodik" szintet, kiadattatik. Ezutan jelenik meg az angol forditas, majd joreszt az alapjan a tobbi. Es nem tolonganak a forditok, meg kell valljam. A Qt jelenleg nem is tudom, hanyadik szuletesnapjan unnepli, es mindezidaig csak en voltam oly meresz, es belevagtam a forditasba. Pedig igazan nem egy nagy wasistdas. Innentol szerintem at kell gondolnunk bizonyos dolgokat.

Nem gondolnam, hogy mindenki csak akkor kezd el hasznalni egy tool-t ha az megkapja a magyar lokalizaciot. Ugyanakkor, ettol meg hasznalhatja valaki az asztalat magyar nyelven, csak epp az az egynehany tool, amit epp hasznal, nincs meg magyarul. Ugyanakkor, ha kiadunk egy forditast, akkor o is valtani fog, mert az o asztalanak az alapertelmezett lokalizacioja magyar. Es most szegeny felhasznalot szivassuk meg csak azert, mert egy olyan korban kezdte el az adott program hasznaaltat, amikor meg senki nem forditotta le? Ez szerintem nem fair.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Replaced | 2009. 07. 21., k – 02:52 )

dupla szokoz az gepiro szabaly, sokan akik gepirni tanultak teljesen automatikusan nyomjak :)

--
When in doubt, use brute force.