01. Operasyonel olarak ne yapıyoruz?
Dokümantasyon yerelleştirme, bir UI metni yerelleştirmesinden farklı işler. Burada uzun metin var; kod blokları, parametre tabloları, ekran görüntüleri, çapraz referanslar ve sürüm etiketleri var. Tek kelimelik string'ler değil, bağlamı korunması gereken teknik içerik söz konusu.
Pratikte şunu yapıyoruz: Kaynak dosyalarınızı (Markdown, MDX, reST, AsciiDoc, DITA XML, HTML veya doc CMS export'u) olduğu gibi alıyoruz, çevrilecek metni segmentlere ayırıyoruz, kod blokları ile inline `code` parçalarını dokunulmaz işaretliyoruz. Çeviri sonrası dosya yine aynı formatta dönüyor — Docusaurus, MkDocs, Sphinx, GitBook, Mintlify veya kendi statik üreticiniz fark etmez, build script'inize doğrudan girer.
`{variable}`, `${param}`, `:placeholder:` gibi yer tutucular; `Bağlantı` referansları; admonition blokları; front matter alanları — hepsinin kuralları farklı. Yerelleştirme ekibi bunları manuel ayırmaz; segmentleme aşamasında otomatik korunur, çevirmen yalnızca doğal dil metniyle uğraşır.
02. Tipik bir dokümantasyon projesi nasıl ilerliyor?
İlk adım kaynak inceleme. Repo erişimi verirseniz `docs/` klasörünü tarıyoruz; vermezseniz örnek bir sayfa seti yeterli. Burada üç şeyi netleştiriyoruz: kelime/segment hacmi, tekrar oranı (translation memory kazancı için), teknik terim yoğunluğu.
İkinci adımda terminoloji çıkarıyoruz. Ürününüze özgü kavramlar — endpoint isimleri, ürün modülleri, hata kodları, SDK fonksiyon adları — bir glossary'de toplanıyor. Hangi terimlerin çevrilmeyeceği (genelde marka adı, fonksiyon adı, CLI komutu) sizinle birlikte kararlaştırılıyor.
Çeviri aşamasında segmentler bir CAT aracında (Trados, memoQ veya Crowdin/Lokalise gibi bulut TMS) işleniyor. Tekrar eden cümleler TM'den geliyor; yeni metin çevrilip TM'ye yazılıyor. İkinci bir editör revize ediyor.
Son adım LQA: çevrilmiş dosyaları sizin build ortamınıza koyup gerçek render'da kontrol ediyoruz. Bozulan link, taşan kutu, yanlış formatlanmış code block varsa düzeltiyoruz. Teslim, sizin kabul ettiğiniz format — pull request, ZIP, doğrudan CMS push.
03. Hangi dosya formatlarıyla çalışıyoruz?
Doc-as-code akışında en sık karşılaşılanlar Markdown ailesi: `.md`, `.mdx`, `.markdown`. MDX'te JSX bileşenleri var — `<Tabs>`, `<Callout>`, `<CodeBlock>` gibi etiketler; bunları korur, sadece içerik prop'larını çeviririz.
Sphinx ve Read the Docs ekosisteminde reStructuredText (`.rst`) işliyoruz; directive ve role'ler (`.. note::`, `:ref:`) çevrilmeden kalır. Asciidoctor projeleri için `.adoc`; enterprise teknik yayıncılıkta DITA XML (`.dita`, `.ditamap`) ve DocBook. Bunlarda conref ve conditional processing referanslarını koruyoruz.
API referansı tarafında OpenAPI/Swagger YAML ve JSON dosyalarını destekliyoruz — `summary`, `description`, `example` alanları çevrilir; schema isimleri ve enum değerleri dokunulmaz kalır. Postman koleksiyonlarındaki açıklama alanları, GraphQL SDL içindeki `"""..."""` bloklarındaki doc string'ler de aynı mantıkla.
Yardım merkezi tarafında Zendesk, Intercom, Freshdesk ve HelpScout export formatlarını doğrudan alıyoruz; HubSpot ve Salesforce Knowledge için HTML/JSON export yeterli. Notion, Confluence ve GitBook'tan da export ile çalışıyoruz.
04. Glossary ve translation memory ne işe yarıyor?
Dokümantasyon projelerinde en büyük kalite problemi tutarsızlık. Aynı terim üç farklı sayfada üç farklı çevrilirse, kullanıcı doğru özelliği bulamaz; arama sonuçları bölünür; destek bileti artar. Glossary ve TM bu sorunu çözmek için kullanılır.
Glossary, ürününüze özgü terimlerin onaylanmış çevirilerini tutar. Örneğin İngilizce "workspace" Türkçe'de "çalışma alanı" mı, "workspace" olarak mı kalacak — bir kez kararlaştırılır, projedeki her sayfada aynı kullanılır. CAT aracı, çevirmen o terime geldiğinde uyarı verir.
Translation memory daha geniş çalışır: çevrilmiş her cümle saklanır. Sürüm 1.4'te değişmeyen 800 cümle, sürüm 1.5 geldiğinde otomatik gelir; sadece değişen ve yeni metin için iş yapılır. Pratikte ikinci sürümden itibaren maliyet ve süre belirgin düşer — bu en önemli ekonomik avantajdır.
Glossary ve TM, projenin sonunda size de teslim edilir. İsterseniz başka bir tedarikçiye geçirebilir, isterseniz iç ekibinizle kullanabilirsiniz.
05. Çevrilen dokümantasyonu nasıl test ediyoruz?
Çeviri dosyada doğru görünebilir ama render edildiğinde sorun çıkabilir. Uzun Almanca cümleler tablo hücresini taşırabilir; Arapça RTL'de kod blokları yanlış hizalanabilir; Çince karakterler font fallback'e düşebilir; bir Markdown link sentaksında kapanmayan parantez tüm sayfayı bozabilir.
LQA, çevrilmiş dokümantasyonu sizin gerçek build ortamınızda kontrol etmemiz demek. Staging URL'iniz varsa oradan sayfa sayfa geçiyoruz; yoksa local build'inizi sizden alıp render ediyoruz. Kontrol ettiklerimiz: kırık iç linkler, render edilmemiş Markdown sentaksı, taşan kutular ve tablolar, eksik veya bozulmuş kod blokları, anchor link tutarlılığı, ekran görüntüsü altyazılarının doğru sayfaya denk gelmesi.
Bulduğumuz sorunları kategorize edip raporluyoruz: kaynak hataları (orijinalde de vardı), çeviri hataları, render hataları ayrı listelerde. Her birinin düzeltme önerisiyle birlikte teslim ediyoruz. İsterseniz düzeltmeleri biz pull request olarak gönderiyoruz; isterseniz sizin ekibiniz uyguluyor.
06. Sürekli güncellenen dokümantasyonda nasıl çalışıyoruz?
Bir API dokümantasyonu veya yardım merkezi haftada birkaç kez güncellenir. Her güncellemede tüm dosyaları yeniden çevirmek mantıksız. Doğru akış, fark bazlı yerelleştirme.
Git tabanlı bir repo'nuz varsa şu modeli kuruyoruz: belirli bir branch veya tag yeni sürümü işaretliyor; biz önceki çevrilmiş sürümle diff alıyoruz; sadece değişen segmentleri TM destekli çeviriyoruz. Bu çoğunlukla sürüm başına %5-15 yeni metin demek — bir günde dönülebiliyor.
TMS kullanan ekipler için (Crowdin, Lokalise, Phrase, Smartling) doğrudan bağlanıyoruz. Yeni metin TMS'e düştüğünde otomatik bildirim alıyoruz, çeviriyoruz, onayınızdan sonra TMS push ediyor. Aradaki manuel dosya alışverişi sıfırlanıyor.
Tempo değişkense iki model var: aylık sabit kapasite (örneğin ayda 8.000 kelime havuzu) veya iş bazlı (her sürüm için ayrı teklif). Hangi modelin sizin için ekonomik olduğunu, son üç ay sürüm geçmişinize bakarak birlikte değerlendiriyoruz.
07. Ücretlendirme nasıl çalışıyor?
Dokümantasyon yerelleştirme fiyatı dört değişkene bağlı: kaynak kelime sayısı, TM eşleşme oranı, hedef dil sayısı ve LQA kapsamı.
Yeni metin (TM eşleşmesi olmayan) tam kelime fiyatından işlenir. %75-99 arası bulanık eşleşmeler indirimli; %100 eşleşme ve tekrar eden segmentler daha düşük orandan. İlk projede TM yok, fiyat tamamen yeni metin üzerinden çıkar; ikinci projeden itibaren TM kazancı görünür hale gelir.
Dil bazlı fark var. İngilizce-Türkçe ve Avrupa dilleri standart bant; Arapça, Çince, Japonca, Korece gibi diller (alfabe ve teknik altyapı zorluğu nedeniyle) bir üst banttan. Hedef dil sayısı arttıkça proje yönetim payı tek seferlik kalır, dil başına marjinal maliyet düşer.
LQA bedeli ayrı kalemdir; kelime başına değil, sayfa/saat bazlı. Küçük projelerde "LQA dahil" paket öneriyoruz; büyük projelerde ayırıyoruz çünkü kapsam ve raporlama derinliği müşteriye göre değişiyor. Glossary ve style guide hazırlığı projenin başında bir kerelik kalem; sonraki sürümlerde tekrar etmez.