Merhaba, Bu zamana kadar yuruttugumuz "gozden gecirme" (RFR) calismalarinda gozlemledigim bazi "sIk yapilan hatalar"i, bundan sonra aramiza katilacak yeni arkadaslara da faydali olmasi icin ozetlemeyi uygun gordum. Hakki Devrim sapkasiyla klavyeye aldigim bu iletinin oldukca eksik oldugunu hatirlatmaliyim. Daha ayrintili bir seyler yazmak icin maalesef yeterli zamana sahip degilim. Aslinda burada ifade ettigim hususlari daha da zenginlestirerek dort basi mamur bir belge haline getirmek ve proje sayfalarina eklemek guzel olurdu. Umarim bunu da bir baska zaman yapariz.
Tashihlerde gozden kacmasi en kolay hatalar "imla hatalari" oluyor.
Noktalama isaretlerine dikkat etmeliyiz; bu alanda yapilan hatalar
Debconf ekranlarinda oldukca kotu bir goruntu olusmasina ve dagitimin
bir butun olarak "amatorce" gorulmesine neden olabiliyor. Bu yuzden
once "imla hatalari" bahsiyle basliyorum.
* Aksini yapmak icin bir gerekce olmadigi muddetce, butun noktalama
isaretlerinden ([.,;?!:]) sonra _bir bosluk_ kullanalim. Bu hatalari
yakalamamiz zor oluyor. Lutfen bu kurala ozellikle riayet edelim.
Bazi yazarlar cumle bitislerini bildiren noktadan sonra cift bosluk
kullanirlar (mesela ben :-). Amerikan Ingilizcesinde de yaygin olarak
kullanilan bu gelenegin orijinleri Emacs'a dek uzanir ve kullandiginiz
metin duzenleyici ile cumleleri ayristirmaniza imkan verir.
* Bir onceki kuralin tamamlayicisi olarak: Gereksiz bosluk kullanimindan
da kacinalim. Bu alanda yaygin bir hata bazi noktalama isaretlerinden
(ozellikle [?:!]) _once_ kullanilan gereksiz bosluklar. Mesela su
yazimdan kacinalim:
... ister misiniz ?
^ gereksiz bosluk
* Tirnak isaretlerinde imla hatalari yapiliyor. En yaygini tirnak
isaretinden once kullanilan gereksiz bosluklar:
... falanca 'nin ...
^ gereksiz bosluk
Tirnak isaretleriyle ilgili olarak bilinmesi gereken onemli bir imla
kuralimiz var: Cift tirnak ('"') isaretini takiben tek tirnak ("'")
kullanilmaz.
... "falanca"'nin <-- yanlis
... "falanca"nin <-- dogru
* Orijinal iletinin sonunda kullanilan noktalari ('.') lutfen
atlamayalim. Or.
Please make a choice.
Lutfen bir secim yapin.
^ (gozden kacmasi cok kolay)
Ayrica devam etmekte olan bir islemi belirten "three dots in
ellipses"i (veya "poor man's progress bar" ;-), orijinal iletide nasil
geciyorsa aynen oyle kullanalim.
Configuring network ... --> Ag yapilandiriliyor ...
Dikkat! Su tip hatalardan lutfen kacinalim:
Ag yapilandiriliyor...
Ag yapilandiriliyor ..
* Cumle baslangiclari malum buyuk harfle baslar. Ilk sozcugun, hepsi
kucuk harfle yazilmasi gerekli bir paket adi vb. olmasi durumunda
bu kuralda bazen celiskiye dusebiliyoruz. Sayet cumle kurgusunu
degistirerek bundan kacinmak mumkun degilse, bu sozcugu cift
tirnakla cevrelemek yoluna gidilebilir:
[...]. \"falanca\" paket icin ...
* Turkce'de yeni neslin unuttugu bazi aksanli harfler var :-) Bunlardan
en onemlisi 'sapkali a' yani 'â'. Debian GNU/Linux'un guncel bir
surumunu kullanan hicbir arkadas "ama ben bu harfleri uretemiyorum"
seklinde bir gerekce one suremez :-) Mevcut tuseslemlerinde hem sanal
konsol, hem de X ortaminda bu karakterleri kolayca uretebiliyoruz.
'sapkali a' icin 'a'yi basitce Altgr ile tuslamaniz -cogu durumda-
yeterli olacaktir.
Peki sapkali harfler nerede gerekiyor? Telaffuzda inceltmeye yol acan
'sapkali a' icin basit bir kural su: [gkl] sessizlerinden sonra
telaffuz sirasinda bir inceltme hissediyorsaniz 'a'ya hemen sapka
koyun :-) Or.
plân imkân silâh kâr kâğıt hâlâ
Burada "hâlâ" ornegindeki ilk 'â' inceltme degil uzatma sapkasidir.
Sapka kuralini "kakafoni" olarak gorenlere cok da itiraz edemiyorum,
ben bile cogu zaman bu kurala uymuyorum. Bu hususta tek bir ricam
olacak; sapka kuralini genel olarak goz ardi edebilirsiniz, bir sozcuk
haric: Lutfen "still"in karsiligi olarak "hala" yazmayin, bu "aunt"a
karsilik gelir :-). Lutfen bu sozcugu "hâlâ" olarak yazin ve kalan
kurallari da, bir bucuk yillik askerligi K.K.K.liginda su an ki
Genelkurmay baskanina sapkali harflerle dolu arzlar yapmakla gecen
eski bir karargâh subayinin fikr-i sabitleri olarak hatirlayin :-)
* Imla bahsinde yukaridakilere ek olarak bazi iyi bilinen kurallari da
tekrar hatirlatmak isterim. Baglac olarak yazilan "da/de" ve "ki"
ayri yazilmalidir. Or.
Dogru Yanlis
----- ------
falancada boyledir --> falanca da boyledir
yeterki --> yeter ki
"Ya" ile birlikte kullanilan "da" da ayri yazilir:
yada --> ya da
Iyelik eki olan "ki"nin ayri _yazilmadigini_ unutmayalim. Or.
metinde ki --> metindeki
Soru ekleri "mi/mu" ayri yazilmalidir. Or.
Devam edilsinmi? --> Devam edilsin mi?
* Imla hatalarini azaltmak icin herseyden once TDK imla kilavuzunu
el altinda hazir bulundurmaliyiz. Eger hâlâ bir tane edinmediyseniz
en kisa surede bir imla kilavuzu almanizi tavsiye ederim. Dileyenler
ilgili TDK sayfalarina da basvurabilir:
http://www.tdk.org.tr/imla/
Kalan hatirlatmalar imla (pardon imlâ) kurallarinin disinda olacak...
* "exempli gratia"nin kisaltmasi olan "e.g." icin lutfen tutarli olarak
"or." ("ornek") karsiligini kullanalim. Cevirilerde bu kisaltma o
kadar cok yerde geciyor ki...
* "id est"in kisaltmasi olan "i.e." farkli bir yaratiktir, lutfen bunu
"e.g." ile karistirmayalim. Turkcede buna uygun karsilik "... gibi"
veya "... vb." olabilir.
* Debconf metinlerinde cok gecen "Note that ..." hatirlatma veya
uyarilarini tutarli olarak "... [oldugunu/yapmayi vb.] unutmayin"
sablonuyla karsilayalim.
* Su sozcukler icin kullandigimiz karsiliklar artik oturdu gibi:
configuration yapilandirma ("ayarlama" degil)
setting ayar
preference tercih ("secenek" degil)
option secenek ("tercih" veya "opsiyon" degil)
install kur ("yukle" degil)
load yukle ("kur" degil)
default ontanimli ("varsayilan" degil, "varsayilir"
karsiligi bazi yerlerde uygun olabilir.)
version surum ("versiyon" degil)
document belge ("dokuman" degil)
mode kip ("mod" degil)
enable etkinlestir
disable etkisizlestir, kaldir, iptal et
problem sorun ("problem" degil)
password parola (aman "sifre" demeyin!)
[digerleri icin sizden katki bekliyorum]
* Cok sIk karsilastigimiz bir sorun da Debconf iletilerinde bol bol
zamir kullanilmasindan kaynaklaniyor. Tam da uygun bir ornek
olmayabilir, ama derdimin anlasilmasi icin su cumleye bakalim:
You can fix this by blah blah ...
Bu cumleyi ilk gordugumuzde soyle bir ceviri kolayimiza gelebilir:
Bunu gidermek icin blah blah ...
Boyle yapmak yerine once "this" zamirinin neyi isaret ettigini
belirleyerek ceviride bu ozneyi acik halde yazmamizin bir cok
durumda _Turkce acisindan_ daha uygun olacagini dusunuyorum.
Bu sorunu gidermek icin blah blah
* Lutfen "motamot" ceviri yapmayalim. Ingilizcedeki yazilis sirasiyla
ceviri yaptigimizda sonuc berbat oluyor. Debconf iletilerini okuyan
Turk kullanicilarin "Ingilizcesi daha anlasilir bunun" yargisina
ulasmalari bizim icin felaket (veya felâket) olur :-) Ceviride
"aslina sadakat" degil "anlasilirlik" her zaman on planda olmali.
Gerekiyorsa orijinal metnin cok disina dahi cikabilirsiniz.
Unutmayalim ki bunlar "DEBian CONFiguration" metinleri. Kullaniciyi
yanlis bir yapilandirma eylemine sevketmemiz cok tehlikeli sonuclar
dogurabilir. Bu hususta pratik bir kural su olabilir: Cevirdiginiz
metinle paket kurulumu yaptiginizi dusunun, yaninizda da Ingilizceyi
yeterli olcude bilmeyen bir arkadasiniz var ve siz ona yardimci
oluyorsunuz.
* Ingilizce; "and", "or", "that", "which" vb. baglaclarla uzun cumleler
kurmaya elverisli bir dil. Yer darligindan oturu paket
gelistiricileri bu tip cumle kurgularina cok sIk basvuruyor. Lutfen
bu uzun cumleleri bolerek cevirelim, cevirinin kolay okunabilir ve
anlasilabilir olmasi icin bu sart. "ssh" cevirisinden bir ornek
vereyim:
This version of OpenSSH has a considerably changed configuration
file from the version shipped in Debian 'Potato', which you
appear to be upgrading from. [...]
Goruldugu gibi bu cok uzun bir cumle. Bolerek cevirecek olursak:
Debian 'Potato' dağıtımından yükseltme yaptığınız görünüyor.
OpenSSH'ın bu sürümü Debian 'Potato' ile birlikte gelen sürümden
çok farklı bir yapılandırma dosyası kullanmaktadır. [...]
Bu cevirinin en uygunu oldugunu iddia etmiyorum, fakat tek cumle
halinde yapilacak bir ceviriye gore daha anlasilir oldugunu
soyleyebilirim.
* Bazi durumlarda bir terim icin yaygin olmayan Turkce karsiliklar
kullanmak zorunda kaliyoruz. Bu tip durumlarda sozcugun Ingilizce
orijinalini de -en azindan bu karsilik yayginlasincaya kadar-
parantezler icinde vermemiz uygun oluyor: "yerlesil (firmware)",
"cerceve tamponu (framebuffer)" gibi. Fakat dikkat buyurun, bu serh
dusme islemini butun bir metinde degil, sadece bu sozcugun _ilk olarak
gectigi yerde_ uygulamaliyiz. Aksi halde ceviri faaliyeti anlamini
yitiriyor. Sozcugun ilk gectigi yeri belirlemek cogu zaman kolaydir.
Cevirdiginiz ileti civarina bakmaniz yeterli olacaktir.
* Iletilerde gecen hitaplari da tutarli sekilde cevirmeliyiz. Bu konuda
basindan beri takip ettigimiz kural "asiri kibarliktan kacinmak"
seklinde formule edilebilir. Or.
Please select [...]. --> Lutfen [...] secin. ["seciniz" degil]
Benim de zaman zaman yaptigim bu hatalari azaltmanin en etkili yolu
cevirileri listeye gondererek gozden gecirilmesini saglamak. Ama lutfen
gondermeden once biten ceviriyi bastan sona dikkatlice okuyarak bu
islemi once siz yapin.
Buraya kadar okuma sabrini gosterenlere tesekkur ederim.
--
roktas
signature.asc
Description: Digital signature
