Giriş yapmadınız.

#26 11.07.2013 15:42:56

sineld
Yönetici
Yer: Bursa
Kayıtlı: 26.12.2012
Mesajlar: 1,439
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

@angelside, Mac ve Windows ortamlarında Github'ın kendi uygulamalarını kullanıyorum, yeni bir push yapmadan önce pull-sync yapmak gerekiyor. Benim başıma da gelen bir sorundu.

Dün ki çeviri düzenlemelerini push yaptığında hiçbir değişiklik yapmadığın dosyaları silmişti, ilave etmek zorunda kaldım; bu da ayrı bir sorun.

Git güzel ancak sıkıntıları yok değil.

Çevrimdışı

#27 11.07.2013 16:06:31

angelside
Üye
Kayıtlı: 26.12.2012
Mesajlar: 195
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Windows ortamında TortoiseGit, Git Extensions, SourceTree kurulu ancak gelişmiş izlemeye gerek olmadıkça TortoiseGit işimi görüyor, elbet komut satırı üzerinden git de çok iyi bir şekilde çalışmakta.

Gelelim konuya;

Senkronize etmek bence bu işin doğru yolu değil. Yol merge olmalı. Benim "pull request" gönderdiğim bilgileri merge etmeniz lazım ki github üzerinde de öyle gösteriyor. Sizin son değişiklik ile benim son değişiklik arasında aynı dosyalarda değişiklik olduysa "conflict" olayını yaşarız. Uzun zamandır hiç conflict yaşamadım ama onlar da diff biçiminde gelecek, el ile veya diff merge ile birleştirmemiz gerekecek. Ben el ile birleştiriyordum çünkü conflict olan satırları okuyup doğrusuna karar vermek gerekiyor.

Gelelim benim soruya, uzun uzun sormuştum, ama yine kendim bir yol izleyerek çözdüm.

Bazıları orijinal repoyu submodul olarak ekle dese de, "remote branch" olarak eklemek çok daha faydalı olacak, en azından fazladan dosyalara sahip olmayacağız.

---------------------------------------------------------------------------------------

Güncellenen fork edilen repo ile kendi repomuzu güncelleyelim/eşitleyelim

Öncesi
Öncesinde orijinal repoyu github üzerinden fork ettik ve fork ile oluşan kendi repomuzu "git clone" ile kendi bilgisayarımıza aldık.

Fork ettiğimiz repoyu remote olarak ekleyelim (sineld, local repomuzdaki adı olacak ki master vb ifadeler karışmadan kolayca bilelim remote hangisi)

git remote add sineld https://github.com/sineld/docs.git

Repoyu çekelim

git pull sineld

Böylece 3 adet repo olmuş oldu, 1. local repo, 2. github üzerindeki repo ve 3. önceden fork ettiğimiz repo (elbet bu repoya yazma iznimiz yok).

master
remotes/origin/master
remotes/sineld/master

Son olarak remotes/sineld/master ile master repolarını "merge" edelim.

git merge sineld/master

Tamam, şu anda orijinal repo ile benim fork ettiğim repo orjinal repo baz alınarak eşitlendi, sadece local repo da, github a göndermek için commit & push yapıyoruz. Github üzerinden tekrar "pull request" yaptım, sorun yok. Bir de bu "pull request" i de kendi bilgisayarımdan yapabiliyorum ama denemedim henüz.

Son düzenleyen angelside (11.07.2013 16:09:40)


http://urltara.com - Aynı ip üzerinde olan diğer siteler ?

Çevrimdışı

#28 11.07.2013 16:33:40

sineld
Yönetici
Yer: Bursa
Kayıtlı: 26.12.2012
Mesajlar: 1,439
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Ellerine sağlık, çözümü paylaşman ayrıca güzel bir sonuç oldu.

Çevrimdışı

#29 16.07.2013 21:50:19

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Rotaların çevirisini yapmaya çalıştım. Bir cümle kaldı, ona da biri el atarsa tamamdır. smile

Çevrimdışı

#30 16.07.2013 23:20:02

angelside
Üye
Kayıtlı: 26.12.2012
Mesajlar: 195
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Tercüme dışında basit hatalar var, parantezlerden önce boşluk yok, "Rota Filtresi Tanımlama" başlığı kaymış. Bir de fonksiyon ve değerler de Türkçeye uyarlanmış, şu ana kadarki çevirilerde bu yapılmamıştı, bu konuda karar verilebilir.

Ersin Kandemir yazdı:

Rotaların çevirisini yapmaya çalıştım. Bir cümle kaldı, ona da biri el atarsa tamamdır. smile


http://urltara.com - Aynı ip üzerinde olan diğer siteler ?

Çevrimdışı

#31 16.07.2013 23:50:11

MetalOxide
Üye
Yer: Kıbrıs/İskele
Kayıtlı: 13.02.2013
Mesajlar: 4

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

angelside yazdı:

Tercüme dışında basit hatalar var, parantezlerden önce boşluk yok, "Rota Filtresi Tanımlama" başlığı kaymış. Bir de fonksiyon ve değerler de Türkçeye uyarlanmış, şu ana kadarki çevirilerde bu yapılmamıştı, bu konuda karar verilebilir.

Çevirilerde kod kısımlarında gerekli görülen yerlerde Türkçe çevirilerin olmasını uygun görüyorum(şahsi fikrim).Böylece kodun yaptığı iş daha kolay anlaşılabilir ama çevrilmesi gerekmeyen kısımlarda olabilir.Örnek olarak kendi çevirim; http://dokuman.laravel.gen.tr/docs/templates

Ayrıca migration,controller gibi kavramların Türkçe'ye çevrilmesinde de bir mahsur görmüyorum.Ancak parantez şeklinde İngilizce şeklini de verip o kavram başka yerde görüldüğünde ne olduğu az çok anlaşılacaktır.Yine bu kavramların Türkçe'ye çevrildiğinde alakasız anlamlar çıkabileceği söyleniyor.Doğrudur ancak doğru şekilde tanımlamak için bilişim sözlük sitelerinden kontrol edip kendi aramızda tartışıp , kararlaştırabiliriz.Karşı fikirlere açığım.Hangisi daha doğru sonuç verecekse o uygulanmalıdır elbette.

Bilişim sözlük siteleri;

http://www.bilisimsozlugu.net/

http://www.tbd.org.tr/index.php?sayfa=sozluk

http://sozluk.cozumpark.com/

Çevrimdışı

#32 17.07.2013 00:34:00

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Terimlerin yarısını çevirip yarısını çevirmemek olmaz diye düşündüm. Kodlar içindeki değişkenler değiştirilebiliyorsa, Türkçe de yazılabilir. Bu şekilde bakmalıyız bence. Çapaları orjinal halleriyle bıraktım bu arada. Parantez kullanımındaki boşluk kuralını bilmiyordum, bana çirkin geliyordu. smile Boşlukları ve kayan başlığı düzelteyim.

Çevrimdışı

#33 17.07.2013 12:28:48

angelside
Üye
Kayıtlı: 26.12.2012
Mesajlar: 195
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

MetalOxide yazdı:

Çevirilerde kod kısımlarında gerekli görülen yerlerde Türkçe çevirilerin olmasını uygun görüyorum(şahsi fikrim).Böylece kodun yaptığı iş daha kolay anlaşılabilir ama çevrilmesi gerekmeyen kısımlarda olabilir.

Sizin dosyada bahsettiğim çeviri türü yok, şundan bahsediyorum:

KullaniciController extends TemelController
public function gosterProfil()

Bu şekilde bir kullanım denemesi yapmış ve evrensel olmadığına karar vermiştim.


http://urltara.com - Aynı ip üzerinde olan diğer siteler ?

Çevrimdışı

#34 17.07.2013 12:44:28

MetalOxide
Üye
Yer: Kıbrıs/İskele
Kayıtlı: 13.02.2013
Mesajlar: 4

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

angelside yazdı:
MetalOxide yazdı:

Çevirilerde kod kısımlarında gerekli görülen yerlerde Türkçe çevirilerin olmasını uygun görüyorum(şahsi fikrim).Böylece kodun yaptığı iş daha kolay anlaşılabilir ama çevrilmesi gerekmeyen kısımlarda olabilir.

Sizin dosyada bahsettiğim çeviri türü yok, şundan bahsediyorum:

KullaniciController extends TemelController
public function gosterProfil()

Bu şekilde bir kullanım denemesi yapmış ve evrensel olmadığına karar vermiştim.

"Gerekli" yerde Türkçe çeviri yapılmasından kastım buydu benimde.

Çevrimdışı

#35 17.07.2013 13:05:40

sineld
Yönetici
Yer: Bursa
Kayıtlı: 26.12.2012
Mesajlar: 1,439
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Birçok yazım hatası ve hatta kod hataları ile karşılaşılacak bu süreçte o kesin; ben çevirinin tamamlanmasının ardından tekrar bir üst ekip tarafından belirli kurallar çerçevesinde düzenlenmesi gerektiği kanaatindeyim. Bu konuda çeviri ekibinden @serginari arkadaşımızla github'da yaptığımız konuşmadan bir bölümünü yayınlıyorum:

@serginari: "...
Sinan bey hazır mesajlaşmışken bir iki şey daha söyleyeyim. Ben visual basic 1.0'dan itibaren onunla, delphi 1.0dan itibaren onunla, sonra bunların .net halleri ile uzun yıllar geçirdim. C#, ASP.net, derken php'ye bulaştım. (Daha önce hiçbir php framework'u ile çalışmadım; aslında Laraveli yüklemeyi de başarabilmiş değilim). Demem şu ki, nesne yönelimli programlama mantığı ile gözümü açtım. Bir yığın değişik (zaman geçtikçe değişen ve bir kısmından vazgeçilen) isimlendirmelerle karşılaştım. Bunun konumuzla alakası şu: Laravel belgelerini çevirirken gördüm ki, aslında birçok isimlendirme laravel'e özgü isimler. Artisan (zanaatkar) mesleklerine uyan isimlendirmelerle karşılaşıyoruz. Dolayısıyla bunların çevrilmesi çok mantıklı olmayacak. Mesela ben veritabanı kısmını bitirmek istiyorum. Migrasyon ve seeding diye bir bölüm var. Bu şimdi Yerleşimler ve Filizlendirme diye
çevrilmiş. Ama kelime anlamı olarak migrasyon göçme, seeding ise tohum ekme anlamına gelir. laraveldeki migrasyon programlama dillerindeki migrasyon anlamına da tam uymuyor. İşlevsel anlamına baktığımızda migrasyon kilometre taşları, hatta kervansaray anlamına daha yakın.Yani bir yolculuktaki önemli durak yerleri, dönüşüm yerleri. Seeding ise tam anlamıyla tohum ekmeye daha uygun. Ama bunlara bu isimleri versek ne olur vermesek ne olur. Öte yandan örneğin ORM'de ön tanımlı bir çok varsayım var. örneğin biz tablo ismine uyeler deriz. Ama uye adında bir model oluşturduğumuzda tablo isminin uyes (uyeler değil) olduğunu varsayıyor, ingilizce bazı alan isimleri olmasını varsayıyor. Controller yerine kontrol edici mi, denetleyici mi desek diye düşünürken bütün kontrollerlerin adlarının "Controller" ile bitmesi gerekiyor gibi daha bir sürü şey var. Bu itibarla tercümeler bittiğinde daha az sayıda
kişiyle son bir karar verilerek yeniden güncelleme yapılması iyi olacak diye düşünüyorum. Saygılarımla. "

@sineld: "...
Yorumunun sonunda yazdığın "daha az sayıda kişiyle son bir karar verilerek yeniden güncelleme yapılması" benim de başından beri düşündüğüm şeydir zaten.

Bu sebeple çevirilerin tamamlanmasını bekliyorum sonrasında gerek başlıklar, gerekse içerikte ciddi düzenlemeler yapılacak ve dokümantasyon son ve kararlı haline ulaşacak."

Çevrimdışı

#36 17.07.2013 13:23:52

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Gittiği yere kadar Türkçeleştirme taraftarıyım. BaseController'a TemelController diyemiyorsak BaseController kalsın. Ama Uye modelinin tablosu $table = 'uyeler'; şeklinde ayarlanabiliyorsa Uye adlı bir model oluşturmanın bir zararı olmayacaktır.
Seeding işlev olarak ilk veri kayıtlarını yapıyor veya genellikle bu yönde kullanılıyor. Filizlendirme de tohum ekme de bu olaya benzetilebilir. Çevirebildiğimiz kadar çevirelim, topluluk büyüdükçe bunlar standartlaşacak bugün durduğu gibi garip durmayacaktır. Tüm sayfalar bittikten sonra buraya bi' kelime listesi çıkarır tartışırız.

Çevrimdışı

#37 17.07.2013 14:43:47

import
Üye
Kayıtlı: 17.07.2013
Mesajlar: 2

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Selamlar

Cevirilerinizi bugun farkettim, tebrikler, cok guzel bir is yapiyorsunuz. Daha once bir cok teknik projede cevirmen olarak yeralmis biri olarak sizlere nacizane tavsiyelerim olacak.

Turkceye cevirdiginizde ingilizce hali ile ifade ettigi anlami kaybeden kavramlari / kelimeleri Turkce'ye cevirmeniz ortaya anlasilmasi guc bir dokuman cikariyor. Ornegin controller icin kullanilan denetci kelimesini, route icin kullanilan rota kelimesini yada callback method icin kullanilan geriçağrım fonksiyonu anlamak ilk basta benim icin zor oldu.

Bu asamada size su 4 metodu oneririm.

1.metod: Controller kelimesi cevrilmemeli, onun icin yine controller kelimesi kullanilmali ve (eger gerekli ise) bu kelimenin aciklamasi 'kavramlar' adinda bir sayfada aciklanmali. Denetci kelimesi bana hicbirsey cagristirmiyor.
2.metod: Callback function kelimesi cevrilmemeli, ancak parantez icerisinde aciklamasi yapilmali. Ornek 'bu kisim bir callback function (bir php fonksiyonu ya da sinif metodu) almalidir.'
3.metod: Rotalama kelimesi yerine 'Routing (Yönlendirme)' kullanimi. Ornek olarak 'Bir route (yönlendirme) controller’a işaret eden bir URL adresidir.'
4.metod: Oldugu gibi birakma. 'Bundle dan ne zaman bir dosyayı işaret etmek isterseniz @BUNDLE_NAME/path/to/file belirtme şeklini kullanabilirsiniz.'

Bu tarz durumlar icin birinin her pull request i review etmesi ve standardi kaybetmemesi saglikli olur kanaatindeyim.

Hepinize kolay gelsin!
Osman.

Son düzenleyen import (17.07.2013 14:46:16)

Çevrimdışı

#38 17.07.2013 14:45:09

import
Üye
Kayıtlı: 17.07.2013
Mesajlar: 2

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Bir tavsiyemde su olacaktir. Kod orneklerini Turkceye cevirmeyin. Zira hem orijinal dokumanlarla sync etmek guc oluyor, hem de bazen cok anlamsiz snippetlar ortaya cikabiliyor. Ancak kodun icerisinde ki commentler turkcelestirilebilir.

Çevrimdışı

#39 17.07.2013 17:20:24

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Routing için "yönlendirme" kullanamayız. "Redirect" isimli bir sınıf var.

Çevrimdışı

#40 17.07.2013 18:56:40

sineld
Yönetici
Yer: Bursa
Kayıtlı: 26.12.2012
Mesajlar: 1,439
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Yönlendirme değil belki ama "Yöneltme" olabilir sanki.

Çevrimdışı

#41 17.07.2013 23:07:15

KenMilabel
Üye
Kayıtlı: 15.06.2013
Mesajlar: 17

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Ufak 2 not:
1.)  Controller Siniflarinin Isimlerinin  "Controller" ile bitmesi gerekliligi yok. Controller'inizi "KullaniciDenetcisi seklinde isimlendirebilirsiniz:

Dayle Reeds, Code Bright, pg 86:
In honesty, you can call the Controller whatever you like. As long as your controller extends
either BaseController or Controller then Laravel will know what you are trying to do. However,
suffixing a controllers name with Controller, for example ArticleController is somewhat of a
standard that web developers employ. If you plan to be working with others, then standards can be
extremely useful.

2.)Eger Resourceful ve RESTfull Controller (avantajlarii) kullanilimayacaksa, Controller icindeki method'larin isimleri de ne isterseniz olabilir (getGosterKullanici gibi). Bunun icin routes.php' da Controller methodunu direkt route olarak tanimlayarak istediginiz her isimdeki methodu calistirabilirsiniz. Fakat bu durumda Resourceful Controller'larini kullanma, ve tek bir route tanimi ile Controller icindeki tum restful method verblerine uyan methodlarini kullanma avantajini kaybediyorsunuz. Bu konvansiyona uymadan isimlendirilecek methodlara ayrica bir route olusturmaniz gerekiyor.

Çevrimdışı

#42 17.07.2013 23:37:39

KenMilabel
Üye
Kayıtlı: 15.06.2013
Mesajlar: 17

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

@serginari:

Bence de, Ingilizce deki "migration" bile islevine cok uyan bir isim degil; "Goc" ise, bir yerden "goc etmek", (oradan ayrilmak) gibi geldigi icin cok uygun gelmiyor.

Halbuki "Migration", veritabaniniza tablolarinizi yerlestiriyor (Up). Yani bir yerden goc etmiyorsunuz, "bir yere" goc ediyor, yani (uygulamanizda tanimlanmis olan veri tabanina yerlesiyorsunuz). Onun icin, tercume ederken, "Yerlesim/Yerlesme" bence daha uygun bir terim gibi geldi.

"Seeding" ise, veritabanina yerlestirdiginiz tablolarin, tamamen bos olmasinin uygulamaniza getirecegi sakincalar olmasi durumunda, tablolariniza gerekli ilk kayitlari olusturmanizi sagliyor. Bu yuzden "Tohumlama" yerine, veri tabanina yerlestirilen tablolarin "filizlendirilmesi" demenin (yani tablolarin ilk kayitlarinin olusturulmasi) olarak, hem Ingilizcesine yakin, fakat "tohumlama" dan daha iyi anlasilir olabilecegini dusunuyorum.

Çevrimdışı

#43 18.07.2013 00:13:40

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?

Çevrimdışı

#44 18.07.2013 00:28:42

sergin
Üye
Kayıtlı: 17.07.2013
Mesajlar: 130
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

ben sergin, gitHub'da bu isim dolu olduğundan serginari adını aldım.
@KenMilabel Controller bilgisi için teşekkür ederim. Başka bir framework kuralı ile karıştırmış olmalıyım.
Migrasyon kelimesini şimdiye dek şöyle bilirdim. Programlama dilinin yeni bir sürümü çıkar, bazı şeyler değişir. Buna uyum sağlamak için şunu şunu yapmak lazım. Ya da siz VB.NET'ten C#'a gelmişsiniz, eski uygulamanızı ne yaparak yeni platforma uygun hale getirirsiniz.
Uygulamamızı bir süreç olarak düşündüğümüzde Laraveldeki migrasyon bir nevi sürüm kontrolü olarak tanımlanmış, Bu yüzden seyahatimizdeki önemli konaklama yerleri, dönüm noktaları olarak anlıyorum. Belki uygulamalar geliştirdikçe daha uygun bir türkçe karşılık bulabileceğiz.
Seeding için ise veritabanını test verileriyle doldurmak denmiş, ben sadece test verisi olarak algılıyorum. Seed tohum, çekirdek ya da ekin ekmek  diye biliyorum ve filiz olarak hiç rastlamadım. Tohumlama ve filizlendirme yerine "tohum ekme" nin daha uygun olduğunu düşünüyorum.

Çevrimdışı

#45 18.07.2013 00:32:39

sergin
Üye
Kayıtlı: 17.07.2013
Mesajlar: 130
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Ersin Kandemir yazdı:

"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?

callback yerine kullanılmış. Closure: kapatma, bitirme, son verme'den, ben "bitirme fonksiyonu" olarak çevirdim.

Çevrimdışı

#46 18.07.2013 00:34:14

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

@sergin, sizin kullandığınız durum için "port etmek" daha uygun gibi. Mesela Python 2.x betiklerinin Python 3.x'e port edilmesi gibi.

Migrasyon daha çok veritabanı eşleme(sync?) ile ilgili bir işlem sanki.

Son düzenleyen Ersin Kandemir (18.07.2013 00:35:12)

Çevrimdışı

#47 18.07.2013 00:37:25

Ersin Kandemir
Üye
Kayıtlı: 29.12.2012
Mesajlar: 17
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

sergin yazdı:
Ersin Kandemir yazdı:

"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?

callback yerine kullanılmış. Closure: kapatma, bitirme, son verme'den, ben "bitirme fonksiyonu" olarak çevirdim.

Bence bir kavram listesi çıkartıp hangilerinin çevrilip, hangilerinin olduğu gibi bırakılacağına karar vermeliyiz.

Closure olduğu gibi kalabilir mesela.

Çevrimdışı

#48 18.07.2013 00:43:14

KenMilabel
Üye
Kayıtlı: 15.06.2013
Mesajlar: 17

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

Bu arada, sayin angelside hakli,

- "BaseController"'i, "TemelController" olarak ceviremezsiniz. Cunku kullanilan (extend edilen) sinif, Laravel framework'a ait olan bir sinif ve ismi sabit "BaseController".  Fakat kendi Controller sinifiniza istediginiz ismi verebilirsiniz. Sonuna "Controller" eklenmesi de sart degil.

-  Method ismi showProfile() in,  gosterProfil() olarak tercume edilmesi ise bundan farkli birsey. Ayri bir route tanimlayarak Controller'daki  gosterProfil() methodunu rahatca kullanabilirsiniz. Method isminin basinda "get", "show", vb  olmasi da gerekmiyor. Fakat, bu sekilde isimlendirdiginizde, Ruby tarzi Resourceful Controller, yani tek bir route tanimlayarak, Controller'unuzdaki butun RESTful verbleri ile baslayan methodlariniza ulasma imkanini kaybediyorsunuz. Ayri bir route tanimlamaniz gerekiyor. Bunu kaybetmeden Turkcelestirme icin belki, showProfile() method ismi, ornegin showGosterProfil() olarak tercume edilebilinir.

Bunun yani sira, sayin MetalOxide ve Ersin Kandemir'e kesinlikle katiliyorum. Soyle ki:

Çevirilerde kod kısımlarında degisebilen (serbest olan) yerlerindede, ozellikle Türkçe isimlerin olmasını, yeni ogrenenler icin cok ama cok faydali goruyorum.

Ben Laravel'i kendim Ingilizce'sinden ogrenirken, verilen kod orneklerinde hangi terimin "Laravel'in" mecburi terimi, hangi kelimenin ise sadece o ornekte kullanilan bir Ingilizce terim oldugunu anlamak icin zorlanmistim, anlamak icin denemeler yapmam gerekmisti.

Kod orneklerinde, ornegin kullanmakta oldugumuz "UserController" da Controller'in mecburi olup olmadigini bile bilmiyoruz. Veya Resourceful bir Controller kullanildiginda showProfile() yonteminde, "show" mecburi, "Profile" mecburi degil. O zaman bunu, kod orneklerinde showGosterBilgilerini(), vb gibi tercume edersek, tercume edilmemis Ingilizce olan kisminin Laravel'e ait ve "mecburi" oldugunu, Turkce isimli kisminin ise "serbest" oldugunu Turkce'den ogrenenlere gosterme imkanimiz olur. Bunun, framework'u  Ingilizce'sinden ogrenmeye gore bile daha avantajli ve daha aydinlatici olacagina inaniyorum.

Çevrimdışı

#49 18.07.2013 00:46:30

sergin
Üye
Kayıtlı: 17.07.2013
Mesajlar: 130
Website

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

migrasyon programlama dillerinde genel olarak bu anlamda kullanılıyor. Örneğin son olarak jQuery son birkaç sürümünde önemli değişiklikler yaptığı için eski sürümlere göre yazılmış kodların yeni sürümlerle uyumlu çalışabilmesini sağlayan migrasyon eklentileri yayınladı. Laraveldeki başka anlamda tabi.

Çevrimdışı

#50 18.07.2013 03:38:56

KenMilabel
Üye
Kayıtlı: 15.06.2013
Mesajlar: 17

Yanıt: Laravel 4 Dokümantasyon Yerelleştirme Çalışmaları

@serginari:
Cok memnun oldum, benim ismim de Kenan. On bilgi olarak: Ben pek programci sayilmam herhalde, kendi islerimde kullanmak icin agirlikli olarak "database", SQL ve server uygulamalari uzerinde calisiyorum. Programlama olarak, sadece on yuz (front-end) olarak kullanmak icin, VB uygulamalari hazirlayip, kullandim. Son 2-3 senedir de,  database'lerimi internet uzerinden ve on yuzu (front-end) olarak, bir web-browser(ve HTML) kullanabilmek icin PHP ogrenmeye basladim, ve ilk framework tecrubem olarak Laravel 3'e  basladim.

Laravel'deki Migration ve Seeding ile ilgili olarak (nacizane) gordugum su:

1.) Evet, Migration, dokumantasyonda,  (uygulamanizin?) bir nevi surum yonetimi olarak soylenmis ve de "ayni uygulama gelistirmesi uzerinde calismakta olan bir ekibe kolaylik saglayacagi" belirtilmis.

Fakat, ozunde(!), Migration'in ve de Seeding'in de, (PHP de yazilmis olan) front-end uygulamanizdaki degisikliklerle veya "surumu"nun kontrolu ile hicbir alakasi(!) yok denilebilir.

Cunku, hic bir database kullanmaya ihtiyac duymadiginiz (ve gelistirmekte oldugunuz) bir Laravel uygulamaniz da rahatlikla olabilir. Migration'in da bunda size hicbir surum kontrolu veya ekip calismasi katkisi olmaz.

Veya, bir database kullanan uygulamanizi, lokal bilgisayarinizda gelistirirken, ayni database'i back-end olarak kullanmakta olan baska bir front-end yaziliminiz da olabilir.

Migrations ile yapacaginiz degisiklikler, sadece bu database'i etkiler. Uygulamanizi etkilemez, uygulamizin gercek bir surum kontrolunu de yapamaz.

Bu yuzden, "migrations" icin,  (PHP kullanan front-end uygulamanizin degil de),  uygulamanizin kullandigi back-end (SQL) database sisteminin "surum yonetimi" denilmesi herhalde daha dogru olurdu.

2.) Ayrica da, benim gordugum kadari ile, migrations'in ve seeding'in esas fonksiyonu  (dokumantasyonda belirtilenlerden) farkli olabilir.

Anladigim kadari ile, migrations'in esas fonksiyonunun, soyle olabilecegini dusunuyorum:

Database kullanan bir uygulamanizin gelistirmesini tamamladiniz, artik domain isminizi yonledirdiginiz web-hosting firmasinin server'ina yukleyeceksiniz.

Web hosting firmasi size hem PHP ortami, hem de "bos" bir SQL database sagliyor.

Database kullanan bir PHP uygulamanizi, web-hosting firmanizin server'ina "upload" ettiniz.

Fakat web-hosting'in size sagladigi (uygulaminizin kullanacagi) oradaki SQL database'iniz ise hala bos. (database'iniz, uygulamanizi gelistirdiginiz lokal bilgisayarinizda kaldi)

Bu upload ettiginiz PHP-Laravel uygulamanizin kullanacagi database semanizi da oraya tasimaniz (yerlestirmeniz), oraya migrate ettirmeniz gerekiyor.

Kabaca 2 alternatifiniz var:

a. Ya PHP uygulaminizi gelistirirken kullanmakta oldugunuz lokal SQL server database sema'sinin, bir "dump"ini alip,  web-hosting firmanizin size acmis oldugu database'e manuel olarak tasiyacaksiniz. (Ben bu sekilde yapiyorum)

b. Veya, upload etmis oldugunuz bu PHP uygulamaniz, yaratmis oldugunuz Migrations'lari kullanip, web-hosting firmasinin size saglamis oldugu database sisteminde, ayni bu sema ve tablolari oraya kendi "yerlestirecek". (Ben bu sekli denemedim)

Veya, yine ayni sekilde, mesela domain name'inizi yonlendirmis oldugunuz web-hosting firmanizi, bir baskasi ile degistirmek istediginizde, eski web-hosting firmanizin database'indeki  database semanizi, yeni web-hosting firmasinin server'indaki database'de de yaratmaniz ve oraya da yerlestirmeniz (oraya goc etmesi/migrate) de gerekebilir.

Bana, (bunu cok emin olarak soylemiyorum, ama) migrations'in esas fonksiyonu sanki buymus gibi geldi. (yukarida da dedigim gibi, migrations'lar web-hosting server'inda calistirilabilir mi, veya nasil calistirilir, hic denemedim, bilmiyorum. Ben database semalarimi simdiye kadar hep manuel olarak ve SQL dump olarak tasiyorum).

Seeding icin de, seedinglerin esas amacinin, test "data" si amaci oldugunu zannetmiyorum:

"Seeding"ler icin de, "migrations" lar gibi ayni sekilde:

Lokal bilgisayarinizda gelistirdiginiz uygulamanizi, (production) server'ina tasidiginizda, ve gelistirirken uygulamanizin lokal SQL server'inizde kullanmakta oldugu database semasini,  migrations'larini kullanarak, gerekli tablolarini oradaki database'e yerlestirdiginide, bu tablolari "bos" olarak yaratacak/yerlestirecek.

Fakat, ornegin menu basliklari bilgilerini bir database tablosunda depolayan ve oradan alan bir CMS uygulamanizda, "menuler" tablosunun "bos" olmasi durumunda, CMS uygulamaniz daha bastan calismayacagi icin, uygulamanizin menu basliklari bilgilerinin, (migrations ile bos tablolarinin yaratilmasi akabinde) bir menuler tablosuna "seed" edilmesi, "filizlendirilmesi" gerekiyor ki, uygulamaniz menuleri ile birlikte calissin ve bir CMS kullanicisi icin, icabinda bu menuler kullanilabilinip, baska yeni menuler de yaratma imkani olsun.

Bu sekilde dusundugumde, uygulamamizi, yeni bir database ortamina ve sistemine tasidigimizda, migrations (yerlesimler) ile yaratilacak bos tablolari, uygulamanin bastan calisabilmesi icin ihtiyac duyacagi kayitlari (ornegin uygulamadaki menu isimlerini) tablolarda yaratmaya (seedings) "filizlendirme" demek daha uygun olur diye dusunuyorum.

Cok selamlar,

Çevrimdışı

Forum alt kısmı