updated Turkish translation for 12 factors

content/tr/admin-processes.md

@@ -1,14 +1,14 @@
 ## XII. Yönetici Süreci
 ### Yönetici/yönetim görevlerini tek seferlik işlem olarak çalıştırma
 
-[Süreç oluşumu](./concurrency) uygulama çalışırken uygulamanın sıradan işlerini (web isteklerini idare etmek gibi) yapmakta kullanılan süreçlerin bir dizisidir. Ayrı olarak, geliştiriciler çoğunlukla uygulamanın bir kereye mahsus yönetimsel veya bakım görevlerini yapmayı dileyecekler, şunun gibi:
+[İşlem formasyonu](./concurrency) uygulama çalışırken uygulamanın sıradan işlerini (web isteklerini idare etmek gibi) yapmakta kullanılan işlemlerin bir dizisidir. Ayrı olarak, geliştiriciler çoğunlukla uygulamanın bir kereye mahsus yönetimsel veya bakım görevlerini yapmayı dileyecekler. Örneğin:
 
-* Veri tabanı göçü çalıştırmak (Django'da `manage.py migrate`, Rails'de `rake db:migrate`).
-* Konsolu ([REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) kabuğu olarakta bilinir), rastgele kodu çalıştırmak veya canlı veritabanına karşılık uygulamanın modellerini denetlemek için çalıştırmak. Çoğu dil hiç bir arguman olmadan (`python` veya `perl`), yorumlayıcı veya bazı durumlarda ayrı komutlarla (Ruby için  `irb`, Rails için `rails console`) çalıştırarak bir REPL sağlar.
-* Uygulamanın deposuna commit'lenmiş betikleri çalıştırmak (`php scripts/fix_bad_records.php`).
+* Veritabanı değişikliklerini (İng. migrations) çalıştırmak (Django'da `manage.py migrate`, Rails'de `rake db:migrate`).
+* Herhangi bir kodu çalıştırmak veya canlı yayın veritabanındaki verileri denetlemek için konsolu ([REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) kabuğu olarak da bilinir) çalıştırmak. Çoğu dil hiçbir argüman olmadan (`python` veya `perl`), veya bazı durumlarda ayrı komutlarla (Ruby için `irb`, Rails için `rails console`) bir REPL sağlar.
+* Uygulamanın kod deposundaki betikleri çalıştırmak (`php scripts/fix_bad_records.php`).
 
-Bir kerelik yönetici süreçleri uygulamanın sıradan [uzun çalışan süreçleri](./processes)  gibi aynı ortamlarda çalışmalıdır. Onlar herhangi bir sürecin çalıştığı gibi [sürüme](./build-release-run) karşı aynı [kod tabanı](./codebase) ve [yapılandırmayı](./config) kullanarak çalışır. Yönetici uygulama kodunu senkronizasyon sorunundan kaçınmak için yüklemelidir.
+Bir kerelik yönetim işlemleri uygulamanın sıradan [işlemleri](./processes) ile aynı ortamlarda çalışmalıdır. Bu yönetim işlemleri de aynı [sürümdeki](./build-release-run) aynı [kod tabanı](./codebase) ve [yapılandırmayı](./config) kullanarak çalışır. Yönetim kodları da uygulama kodu ile aynı kod deposunda bulunmalıdır.
 
-Aynı [bağımlılık yalıtımı](./dependencies) teknikleri bütün süreç yönetiminde kullanılmalıdır. Örneğin, eğer Ruby web süreçleri `bundle exec thin start` komutunu kullanıyorsa, veri tabanı göçü `bundle exec rake db:migrate` komutu kullanmalıdır. Aynı durumda, Virtualenv kullanan bir Python programı, Tornado web sunucusu ve herhangi bir  `manage.py` yönetici süreçlerinin ikisini de çalıştırabilmek için `bin/python` kullanmalıdır. 
+Aynı [bağımlılık yalıtımı](./dependencies) teknikleri bütün işlem yönetiminde kullanılmalıdır. Örneğin, eğer Ruby web işlemleri `bundle exec thin start` komutunu kullanıyorsa, veritabanı göçü de `bundle exec rake db:migrate` komutu kullanmalıdır. Aynı durumda, Virtualenv kullanan bir Python programı, Tornado web sunucusu ve herhangi bir `manage.py` yönetici işlemlerinin ikisini de çalıştırabilmek için `bin/python` kullanmalıdır.
 
-On iki faktör, REPL kabuğunu kural dışı sağlayan ve tek seferlik betikleri çalıştırmayı kolaylaştıran dilleri fazlasıyla destekler. Yerel dağıtımda, geliştiriciler uygulamanın kontrol dizinindeki açık kabuk komutuyla tek seferlik yönetici süreçlerini çalıştırır. Ürün dağıtımında, geliştiriciler bu gibi bir süreci çalıştırmak için ssh veya dağıtımın çalışma ortamı tarafından sağlanan diğer uzak komut çalıştırma mekanizmasını kullanabilir.
+On iki faktör, REPL kabuğunu kendisi sağlayan ve tek seferlik betikleri çalıştırmayı kolaylaştıran dilleri fazlasıyla destekler. Yerel dağıtımda, geliştiriciler uygulamanın dizininde doğrudan komut satırında tek seferlik yönetici işlemlerini çalıştırır. Canlı yayın dağıtımında ise, geliştiriciler bu gibi bir işlemi çalıştırmak için ssh veya dağıtımın çalışma ortamı tarafından sağlanan diğer uzak komut çalıştırma mekanizmasını kullanabilir.

content/tr/backing-services.md

@@ -1,14 +1,14 @@
-## IV. Destek servisi
-### Destek servislerine ekli kaynak olarak davranma
+## IV. Yardımcı servisler
+### Yardımcı servislere iliştirilmiş kaynaklar olarak davranmak
 
-Bir *destek servisi* uygulamanın kendi normal işleminin bir parçası olarak ağ üzerinden tüketim yapan bir servistir. Örnekler veri deposu([MySQL](http:https://dev.mysql.com/) veya [CouchDB](http:https://couchdb.apache.org/) gibi), mesajlama/kuyruklama sistemleri( [RabbitMQ](http:https://www.rabbitmq.com/) veya [Beanstalkd](https://beanstalkd.github.io)), giden email için SMTP servisi([Postfix](http:https://www.postfix.org/) gibi) ve önbellekleme sistemleri([Memcached](http:https://memcached.org/) gibi) içerir.
+Bir *yardımcı servis* uygulamanın kendi işlevselliğinin bir parçası olarak ağ üzerinden tükettiği herhangi bir servistir. Örnekler veritabanları ([MySQL](http:https://dev.mysql.com/) veya [CouchDB](http:https://couchdb.apache.org/) gibi), mesajlaşma/kuyruk sistemleri ([RabbitMQ](http:https://www.rabbitmq.com/) veya [Beanstalkd](https://beanstalkd.github.io)), e-posta göndermek için SMTP servisi ([Postfix](http:https://www.postfix.org/) gibi) ve önbellekleme sistemlerini ([Memcached](http:https://memcached.org/) gibi) içerir.
 
-Destek servisleri, veri tabanı gibi, uygulamaların çalışma zamanlı dağıtımlarında olduğu gibi benzer sistem yöneticileri tarafından geleneksel olarak yönetilirler. Bu yerel yönetilen servislere ilave olarak, uygulama üçüncü parti uygulamalar tarafından onaylanmış ve yönetilmiş servislere sahip olabilirler. Örnekler SMTP servisleri([Postmark](http:https://postmarkapp.com/) gibi), Metrik toplama servisleri( [New Relic](http:https://newrelic.com/) veya [Loggly](http:https://www.loggly.com/) gibi), binary servisler([Amazon S3](http:https://aws.amazon.com/s3/) gibi) ve API-erişilebilir tüketici servisleri bile [Twitter](http:https://dev.twitter.com/), [Google Maps](http:https://code.google.com/apis/maps/index.html), ve [Last.fm](http:https://www.last.fm/api) gibi) içerir.
+Veritabanları gibi yardımcı servisler, geleneksel olarak uygulamayı da yöneten sistem yöneticileri tarafından yönetilirler. Ancak bu yerel servislere ilave olarak, uygulama üçüncü parti uygulamalar tarafından sağlanan ve yönetilen servislere de sahip olabilirler. Bunlardan bazıları; SMTP servisleri ([Postmark](http:https://postmarkapp.com/) gibi), metrik toplama servisleri ([New Relic](http:https://newrelic.com/) veya [Loggly](http:https://www.loggly.com/) gibi), statik içerik barındırma servisleri ([Amazon S3](http:https://aws.amazon.com/s3/) gibi) ve hatta API-erişilebilir tüketici servisleridir ([Twitter](http:https://dev.twitter.com/), [Google Maps](http:https://code.google.com/apis/maps/index.html), ve [Last.fm](http:https://www.last.fm/api) gibi).
 
-**On iki faktör uygulaması için bu kod, yerel ve üçüncü parti servisler arasında ayrım yapmaz.** Uygulamada, her ikiside ek kaynaktır, [yapılandırmada](./config) saklanmış yer belirleyici/kimlik bilgileri ve URL aracılığıyla erişilir. On iki faktör uygulamasının bir dağıtımı, uygulama kodunda hiçbir değişiklik olmadan üçüncü parti([Amazon RDS](http:https://aws.amazon.com/rds/) gibi) tarafından yönetilenle yerel MySQL veritabanı silebilmelidir. Aynı şekilde bir yerel SMTP servisi(Postmark gibi), kod değişikliksiz bir üçüncü parti SMTP servisiyle değiş tokuş yapılabilir. Her iki durumda da, kaynak sadece değişmesi gereken yapılandırmada ele alınır.
+**On iki faktör uygulamaları için bir servisin yerel veya üçüncü parti olmasının farkı yoktur.** Uygulama için, her ikisi de ek kaynaktır ve [yapılandırmada](./config) saklanmış URL'ler veya yer belirleyici ve kimlik bilgileri ikilisi aracılığıyla erişilir. On iki faktör uygulamasının bir dağıtımı, uygulama kodunda hiçbir değişiklik yapmak zorunda kalmadan yerel bir MySQL veritabanı kullanmaktan üçüncü parti bir veritabanı ([Amazon RDS](http:https://aws.amazon.com/rds/) gibi) kullanmaya geçebilmelidir. Aynı şekilde yerel bir SMTP servisinden (Postmark gibi), kod değişikliği olmaksızın bir üçüncü parti SMTP servisine geçiş yapılabilir. Her iki durumda da, değişmesi gereken şey sadece yapılandırma ayarlarındaki bağlantı bilgileridir.
 
-Her bir belirgin destek servisi bir *kaynaktır*. Örneğin, bir MySQL veritabanı(Uygulama katmanında parçalanma için kullanılmış) bir kaynaktır; iki MySQL veritabanı iki belirgin kaynak olarak nitelendirilir. On iki faktör uygulaması veritabanlarına, bağlı oldukları dağıtımlara gevşek bağlaşımlarını belirten *ek kaynak* olarak davranır.
+Her bir destek servisi bir *kaynaktır*. Örneğin, bir MySQL veritabanı bir kaynaktır; iki MySQL veritabanı (uygulama katmanında parçalanma [İng. sharding] için kullanılan) iki farklı kaynak olarak nitelendirilir. On iki faktör uygulaması bu veritabanlarına, bağlı oldukları dağıtımlara gevşek bağlaşımlarını belirten *ek kaynak* olarak davranır.
 
-<img src="/images/attached-resources.png" class="full" alt="A production deploy attached to four backing services." />
+<img src="/images/attached-resources.png" class="full" alt="Canlı yayın dağıtımı dört destek servisine bağlanmış." />
 
-Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanım sorununa göre yanlış davranıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veri tabanı sunucusunu döndürebilir. Şuanki veritabanı ekten çıkarılmış olabilir ve yeni veri tabanı eklenmiş olabilir, hiç bir kod değişikliği olmadan.
+Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanımsal sorunlar yaşıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veritabanı sunucusu oluşturabilir. Problemli veritabanının uygulamadan bağlantısı kesilip, yeni veritabanı bağlanabilir, hem de hiçbir kod değişikliği olmadan.

content/tr/build-release-run.md

@@ -1,18 +1,18 @@
-## V. Derleme, Sürüm, Çalıştırma
+## V. Derleme, yayınlama, çalıştırma
 ### Derleme ve çalıştırma aşamalarını tam olarak ayırma
 
-Bir [kod tabanı](./codebase) üç aşamada dağıtıma dönüşebilir:
+Bir [kod tabanı](./codebase) üç aşamada (geliştirme dağıtımı olmayan) dağıtıma dönüşür:
 
-* *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir pakette çeviren bir dönüşümdür.Dağıtım süreci tarafından belirlenen bir commit'deki kodun versiyonunu kullanırken, derleme aşaması sağlayıcı [bağımlılıkları](./dependencies)  getirir ve binary'leri derler.
-* *Sürüm aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı şu anki [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *sürüm* derleme ve yapılandırmanın ikisinide içerir ve çalışma ortamındaki doğrudan çalıştırma için hazırdır.
-* *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili sürümün karşılığındaki uygulamanın [süreçlerini](./processes) bazı setlerini başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır.
+* *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir bir pakete çevrilmesidir. Dağıtım evresi tarafından seçilen commit'teki kod kullanılır. Sistem, üçüncü parti [bağımlılıkları](./dependencies) toparlar ve çalıştırılabilirleri ve statik dosyaları derler.
+* *Yayınlama aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı güncel [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *yayın* derleme ve yapılandırmanın ikisini de içerir ve çalışma ortamında çalıştırmak için hazırdır.
+* *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili yayının karşılığındaki [işlemleri](./processes) başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır.
 
 ![Kod, sürüm oluşturmak için yapılandırmayla birleşmiş derlemeye dönüşür.](/images/release.png)
 
-**On iki faktör uygulamaları derleme,sürüm ve çalıştırma aşamaları arasında mutlak ayırmayı kullanır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır.
+**On iki faktör uygulamalarının derleme, yayınlama ve çalıştırma aşamaları tamamen birbirinden bağımsızdır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır.
 
-Dağıtım araçları genel olarak sürüm yönetim araçlarını önerir, en dikkat çekeni bir önceki sürüme geri dönme yeteneğidir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) dağıtım aracı sürümleri, şu anki sürümün şimdiki sürüm dizinine bir sembolik link olduğu, `releases` adlı alt dizinde depolar. `rollback` komutu, bir önceki sürüme hızlı geri dönüşü kolaylaştırır.
+Dağıtım araçları genelde yayın yönetim araçları da sunar. En dikkat çeken yetenekleri ise bir önceki yayına geri dönebilmeleridir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) farklı yayınları `releases` adındaki bir alt dizinde depolar. Çalışıyor olan yayın ise bu alt dizinlerden birine oluşturulmuş bir kısayol dosyasıdır. Capistrano'nun `rollback` komutu, kısayol dosyasının işaret ettiği dizini değiştirerek önceki bir yayına dönüş yapmayı kolaylaştırır.
 
-Her sürüm her zaman sürümlerin zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel sürüm ID'sine veya artış numarasına (`v100` gibi) sahip olmalıdır. Sürümler yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman dönüştürülemez. Herhangi bir değişiklik yeni bir sürüm oluşturmalıdır.
+Her yayın zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel bir ID'ye veya her yeni yayında artan bir numaraya (`v100` gibi) sahip olmalıdır. Yayınlar yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman değiştirilemez. Herhangi bir değişiklik yeni bir yayın oluşturmalıdır.
 
-Derlemeler, herhangi bir zamanda yeni kod dağıtıldığında uygulama geliştiricileri tarafından başlatılır. Çalışma zamanı yürütmesi, kontras tarafından, sunucu tekrar çalıştırılması veya çökmüş süreçlerin süreç yöneticisi tarafından tekrar başlatılması gibi durumlarda otomatik olarak olabilir. Bunun sonucunda, çalıştırma evresi, gecenin bir yarısında çalışan geliştiriciler yokken uygulamanın çalışmasını engelleyen problemler uygulamanın bozulmasına yol açabildiği için, olabildiği kadar az sayıda hareketli bölüm olarak tutulmalıdır. Derleme evresinde, hatalar  dağıtımı çalıştıran geliştiriciler için her zaman ön planda olduğu için daha fazla karış olabilir.
+Derlemeler, geliştiricilerin kod değişikliklerini kod depolarına yüklemesiyle başlatılır. Çalıştırma evresi ise, sunucuların yeniden başlatılması veya çökmüş işlemlerin tekrar ayağa kaldırılması gibi durumlarda otomatik olarak gerçekleştirilir. Bu yüzden çalıştırma evresi olabildiği kadar az sayıda hareketli parçaya sahip olmalıdır ki, gecenin bir yarısında, işinin başında olan hiçbir geliştirici yokken bozulmasın. Derleme evresi ise daha karmaşık olabilir, çünkü hatalar dağıtımı çalıştıran geliştiricilerin her zaman önündedir.

content/tr/codebase.md

@@ -12,6 +12,6 @@ Kod tabanı ve uygulama arasında her zaman birebir ilişki vardır:
 * Eğer birden fazla kod tabanı varsa bu bir uygulama değil, dağıtık sistemdir. Dağıtık sistemdeki her bileşen bir uygulamadır ve her biri on iki faktörle bireysel olarak uyumlu olmalıdır.
 * Aynı kodu paylaşan birden fazla uygulama, on iki faktörü ihlal eder. Burada çözüm, paylaşılan kodun [bağımlılık yöneticisi](./dependencies) aracılığıyla dahil edilebilecek kütüphanelere dönüştürülmesidir.
 
-Uygulamanın sadece bir kod tabanı vardır fakat birden fazla dağıtımı olacaktır. Bir *dağıtım*, uygulamanın çalışan bir örneğidir. Bu dağıtımlar genelde bir gerçek ortam (İng. production) ve bir veya birkaç test ortamıdır. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır ve bunların her biri aynı zamanda dağıtım olarak nitelendirilirler.
+Uygulamanın sadece bir kod tabanı vardır fakat birden fazla dağıtımı olacaktır. Bir *dağıtım*, uygulamanın çalışan bir örneğidir. Bu dağıtımlar genelde bir canlı yayın (İng. production) ve bir veya birkaç test ortamıdır. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır ve bunların her biri aynı zamanda dağıtım olarak nitelendirilirler.
 
-Dağıtımlarda anlık olarak farklı sürümler etkin olabilir fakat kod tabanı tüm dağıtımlarda aynıdır. Örneğin, bir geliştirici henüz commit'lemediği değişiklikleri çalıştırıyor olabilir, veya test ortamında henüz gerçek ortama dağıtılmamış bir sürüm çalışıyor olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod tabanı aynıdır.
+Dağıtımlarda anlık olarak farklı sürümler etkin olabilir fakat kod tabanı tüm dağıtımlarda aynıdır. Örneğin, bir geliştirici henüz commit'lemediği değişiklikleri çalıştırıyor olabilir, veya test ortamında henüz canlı yayına dağıtılmamış bir sürüm çalışıyor olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod tabanı aynıdır.