Bir metni başka bir dile çevirmek kolay görünür: kelimeyi bul, karşılığını yaz, kahveni yudumla! Gerçekteyse dil; bağlam, sözcük sırası, çekim ve kültürel ifadelerle dolu karmaşık bir sistemdir. Açık kaynak dünyasında LibreTranslate, Argos Translate ve Apertium bu probleme farklı katmanlardan yaklaşır. Biri kullanışlı bir web API’si sunarken diğeri çevrimdışı sinir ağı modellerine, ötekiyse dilbilgisi kurallarına güvenir.

``

Makine çevirisinin temel mantığı

Makine çevirisi sistemleri genel olarak kural tabanlı, istatistiksel veya sinir ağı tabanlı çalışır. Kural tabanlı yöntemde kaynak cümle sözcük ve biçimbirimlerine ayrılır; ardından sözlükler ile dilbilgisi kuralları uygulanır. Sinir ağı tabanlı yöntemdeyse model, bütün cümlenin bağlamını sayısal vektörlerle temsil ederek hedef cümleyi üretir.

Bir sinir ağı modelinde en olası çeviri basitleştirilmiş biçimde şöyle aranır:

Burada $X$ kaynak cümleyi, $Y$ olası hedef cümleyi ve $\hat{Y}$ modelin seçtiği çeviriyi ifade eder. Model yalnızca kelime karşılıklarını değil, hedef dilde doğal görünme olasılığını da hesaba katar.

Üç araç arasındaki farklar

LibreTranslate

LibreTranslate, kendi sunucunuza kurabileceğiniz açık kaynaklı bir çeviri API’sidir. Tarayıcı arayüzü bulunsa da asıl yıldızı REST API desteğidir. Verilerin üçüncü taraf bir servise gönderilmemesi; şirket içi belgeler, kişisel notlar ve eğitim projeleri için önemli bir avantajdır.

Aşağıdaki Python kodu, çalışan bir LibreTranslate sunucusuna istek gönderir:

import requests

payload = {
    "q": "Açık kaynak yazılımlar özgürlük sağlar.",
    "source": "tr",
    "target": "en",
    "format": "text"
}

response = requests.post(
    "http://localhost:5000/translate",
    json=payload,
    timeout=30
)

response.raise_for_status()
print(response.json()["translatedText"])

Kod, kaynak metni ve dil kodlarını JSON olarak API’ye yollar; dönen sonuçtan çevrilmiş metni çıkarır. Üretim ortamında zaman aşımı, kimlik doğrulama ve hata yönetimi ayrıca planlanmalıdır.

Argos Translate

Argos Translate, indirilebilir dil paketleriyle tamamen yerel çalışabilir. İnternet bağlantısı olmadan çeviri yapması hem gizlilik hem de taşınabilirlik sağlar. Ancak bir dil çiftinin desteklenmesi için uygun model paketinin kurulması gerekir. Ayrıca doğrudan bir model yoksa Türkçeden belirli bir dile çeviri, İngilizce gibi ara bir dil üzerinden gerçekleştirilebilir. Bu zincirleme yaklaşım erişimi artırırken hataları da biriktirebilir.

Apertium

Apertium’un dünyası biraz daha “dilbilim laboratuvarı” gibidir. Sistem sözlükler, biçimbirimsel çözümleyiciler ve aktarım kuralları kullanır. Özellikle İspanyolca–Katalanca gibi yapısal olarak yakın dillerde güçlü sonuçlar verebilir. Kurallar incelenebilir ve düzeltilebilir; buna karşılık yeni bir dil çifti hazırlamak ciddi dilbilim emeği ister.

Kaliteyi nasıl değerlendirmeli?

Çeviri kalitesi yalnızca “doğru görünüyor” hissiyle ölçülmez. BLEU gibi metrikler, üretilen çevirideki sözcük dizilerini referans çevirilerle karşılaştırır. Yine de yüksek puan her zaman doğal veya anlamca kusursuz sonuç demek değildir. Deyimler, teknik terimler ve alan bilgisi için insan değerlendirmesi gereklidir.

Hızlı bir API ve kolay entegrasyon istiyorsanız LibreTranslate, gömülü ya da çevrimdışı bir çözüm arıyorsanız Argos Translate, kuralları denetlemek ve yakın diller üzerinde çalışmak istiyorsanız Apertium mantıklı seçimdir. Kısacası en iyi araç mutlak değildir; dil çiftine, donanıma, gizlilik beklentisine ve “bu cümle neden böyle çevrildi?” sorusuna ne kadar ayrıntılı cevap istediğinize bağlıdır.

``

Akış şemasının temel mantığı

Akış şeması, bir süreci düğümler ve bu düğümler arasındaki yönlendirilmiş bağlantılar ile temsil eder. Matematiksel olarak bir şemayı $G=(V,E)$ biçiminde düşünebiliriz. Burada $V$ işlem, karar veya başlangıç gibi düğümleri; $E$ ise düğümler arasındaki geçişleri ifade eder.

Örneğin kullanıcı girişini denetleyen bir süreçte düğümler; “bilgileri al”, “doğru mu?” ve “paneli aç” olabilir. Karar düğümünden iki farklı yol çıkması, algoritmadaki if/else yapısının görsel karşılığıdır.

Bir şemadaki olası yürütme yollarının sayısı karar noktalarıyla büyür. Her karar iki seçeneğe sahipse, kaba bir üst sınır olarak $P=2^d$ yazılabilir. Buradaki $d$, karar düğümü sayısıdır. Beş karar noktası teorik olarak $2^5=32$ farklı yol oluşturabilir. Şemalar tam da bu karmaşıklığı fark etmeyi kolaylaştırır.

Üç aracın kısa karşılaştırması

draw.io: Görsel özgürlük

draw.io, günümüzde diagrams.net adıyla da bilinen görsel bir diyagram aracıdır. Kutuları çalışma alanına bırakır, okları bağlar ve renkleri arayüz üzerinden ayarlarsınız. Teknik sözdizimi öğrenmek istemeyen ekipler için oldukça rahattır.

En büyük avantajı, karmaşık yerleşimleri elle hassas biçimde düzenleyebilmenizdir. Ağ topolojileri, organizasyon şemaları ve bulut mimarileri için geniş bir şekil kütüphanesi sunar. Buna karşılık XML tabanlı dosyalarında yapılan değişiklikleri Git karşılaştırmalarında okumak pek keyifli değildir. “Kutuyu üç piksel sola aldım” değişikliği, kod incelemesinde küçük bir destana dönüşebilir.

Mermaid: Markdown’ın diyagram arkadaşı

Mermaid, diyagramları kısa bir metinle tanımlamanızı sağlar. GitHub ve birçok dokümantasyon sistemi tarafından desteklenmesi önemli bir avantajdır.

flowchart TD
    A[Bilgileri al] --> B{Bilgiler doğru mu?}
    B -- Evet --> C[Paneli aç]
    B -- Hayır --> D[Hata göster]
    D --> A

Bu kod; giriş bilgilerini alan, doğrulama yapan ve sonuca göre yönlenen bir akış üretir. Metin tabanlı olduğu için değişiklikler Git üzerinde satır satır izlenebilir. Ancak çok büyük şemalarda otomatik yerleşim her zaman hayalinizdeki estetik sonucu vermeyebilir.

PlantUML: Diyagramların İsviçre çakısı

PlantUML; akışların yanında sınıf, sıra, durum ve bileşen diyagramları üretmekte güçlüdür. Sözdizimi Mermaid’e göre biraz daha ayrıntılıdır, fakat büyük yazılım sistemlerinde daha fazla kontrol sağlar.

@startuml
start
:Bilgileri al;
if (Bilgiler doğru mu?) then (Evet)
  :Paneli aç;
else (Hayır)
  :Hata göster;
endif
stop
@enduml

Burada start ve stop sürecin sınırlarını, if bloğu karar noktasını, iki nokta arasındaki ifadeler ise işlem adımlarını belirtir. Kod dokümantasyon deposunda saklanabilir ve otomatik derleme süreçlerinde PNG veya SVG çıktısına dönüştürülebilir.

Hangisini seçmeli?

Toplantıda hızlıca kutu çizmek, özel ikonlar kullanmak ve görsel kontrolü tamamen elinizde tutmak istiyorsanız draw.io iyi seçimdir. README veya teknik belgelerde küçük ve sürümlenebilir şemalar gerekiyorsa Mermaid daha pratiktir. UML ağırlıklı, kapsamlı ve otomatik üretilecek mimari dokümantasyon içinse PlantUML öne çıkar.

Kısacası en iyi araç mutlak değildir: Şemanız sunum odaklıysa fareyi, dokümantasyon odaklıysa kodu seçin. Hatta ekipler çoğu zaman ilk taslağı draw.io ile hazırlayıp kalıcı teknik belgeyi Mermaid veya PlantUML ile yeniden üreterek üç dünyanın da avantajından yararlanabilir.

``

Önce temel mantık: Bağış sistemi nasıl çalışır?

Tipik bir bağış akışı; bağışçı, form, ödeme sağlayıcısı, işlem kaydı ve raporlama katmanlarından oluşur. Kullanıcı formu doldurduğunda sistem ödeme sağlayıcısına bir istek gönderir. Başarılı işlem sonrasında bağış kaydedilir, makbuz oluşturulur ve gerekiyorsa bağışçıya otomatik e-posta gönderilir.

Bir kampanyanın net geliri basitçe şöyle modellenebilir:

Burada $o_{komisyon}$ ödeme sağlayıcısının oransal kesintisini, $M_{sabit}$ işlem başına sabit maliyetleri temsil eder. Dolayısıyla yalnızca yazılımın fiyatını değil, ödeme komisyonlarını ve operasyon yükünü de karşılaştırmak gerekir.

Üç sistemin karakteri

CiviCRM: Kurumsal hafıza isteyenlere

CiviCRM yalnızca ödeme almakla kalmaz; bağışçıları, üyelikleri, etkinlikleri, e-postaları ve geçmiş etkileşimleri tek profilde toplar. Drupal, Joomla veya WordPress ile çalışabilir. Özellikle aynı destekçiyle yıllar boyunca ilişki kuran kuruluşlar için güçlüdür.

Bunun karşılığında kurulum ve bakım daha zahmetlidir. Veri modeli, roller, izinler ve zamanlanmış görevler doğru yapılandırılmalıdır. Küçük bir kampanya için ağır gelebilir; fakat binlerce kişiyle çalışan bir STK için adeta dijital genel merkezdir.

GiveWP: WordPress içinde pratik çözüm

GiveWP, mevcut WordPress sitesini bağış platformuna dönüştürür. Kampanya formları, hedef göstergeleri, bağışçı panelleri ve tekrarlayan ödeme özellikleri sunar. İçerik ekibinin WordPress’e aşina olması önemli bir avantajdır.

Basit bir entegrasyon mantığı şu şekilde düşünülebilir:

add_action('give_insert_payment', function ($payment_id) {
    $amount = give_get_payment_total($payment_id);
    error_log('Yeni bağış tutarı: ' . $amount);
});

Bu örnek, yeni ödeme kaydedildiğinde bağış tutarını günlük dosyasına yazar. Gerçek projede aynı kanca CRM bildirimi göndermek veya özel bir teşekkür süreci başlatmak için kullanılabilir. Ancak ücretli eklentiler, ödeme ağ geçitleri ve WordPress güvenliği toplam maliyete eklenmelidir.

Open Collective: Şeffaflık varsayılan ayar

Open Collective özellikle açık kaynak projeleri, yerel topluluklar ve gayriresmî gruplar için dikkat çekicidir. Gelirler ve giderler herkese açık gösterilebilir. Bir mali sponsor kullanıldığında topluluk, ayrı bir tüzel kişilik kurmadan para kabul etme ve harcama olanağı bulabilir.

Platformun en güçlü tarafı şeffaflıktır; ancak klasik CRM özellikleri veya tamamen özelleştirilebilir bağış deneyimi bekleyen kuruluşlar için sınırlı kalabilir.

Hangisini seçmeli?

Karar verirken bağış hacmi, ekip kapasitesi, veri gizliliği ve raporlama gereksinimleri birlikte değerlendirilmelidir. Kısacası CiviCRM ilişkiyi, GiveWP dönüşümü, Open Collective ise güveni ve şeffaflığı merkeze koyar. En iyi sistem en fazla özelliğe sahip olan değil, kuruluşunuzun günlük iş akışına en az sürtünmeyle uyum sağlayandır.

Birim dönüştürme uygulamaları ilk bakışta yalnızca “metreyi kilometreye böl” seviyesinde görünür. Ancak sıcaklık, alan, hacim, hız ve türetilmiş bilimsel birimler işin içine girince küçük hesap makinemiz adeta laboratuvar önlüğü giymeye başlar. ConvertAll yaklaşımını örnek alan ve MathJS kullanan bir web sitesi; kullanıcıya esnek, güvenilir ve genişletilebilir bir dönüştürme deneyimi sunabilir. ``

Birim dönüşümünün temel mantığı

Aynı fiziksel büyüklüğü temsil eden birimler arasında genellikle bir ölçek katsayısı bulunur. Örneğin metre ile santimetre arasındaki ilişki şöyledir:

Dolayısıyla $x$ metreyi santimetreye dönüştürmek için $x \times 100$ hesaplanır. Genel doğrusal dönüşüm modeli şu şekilde ifade edilebilir:

Burada $a$ ölçek katsayısı, $b$ ise başlangıç noktası farkıdır. Uzunluk dönüşümlerinde çoğunlukla $b=0$ olur. Sıcaklıkta ise durum farklıdır. Celsius’tan Fahrenheit’a dönüşüm:

Bu ayrım önemlidir; her birimi yalnızca bir sayıyla çarpmak doğru sonuç üretmez.

ConvertAll yaklaşımı nedir?

ConvertAll, kullanıcının kaynak ve hedef birimleri özgürce seçebilmesini sağlayan masaüstü odaklı bir dönüştürme aracıdır. En güçlü fikri, yalnızca hazır dönüşüm düğmeleri sunmak yerine birim ifadelerini ayrıştırmasıdır. Böylece km/hour, meter/second veya kg*m/s^2 gibi bileşik ifadeler anlamlandırılabilir.

Bir web projesinde aynı yaklaşımı uygulamak için üç temel katman gerekir:

1. Kullanıcı ifadesini ayrıştıran giriş katmanı,
2. Birimlerin uyumluluğunu denetleyen hesaplama motoru,
3. Sonucu anlaşılır biçimde gösteren arayüz.

Kütle ile uzunluğu dönüştürmeye çalışmak matematiksel olarak anlamsızdır. Sistem, 5 kg → metre isteğine rastgele bir sayı vermek yerine boyut uyuşmazlığı hatası göstermelidir.

MathJS ile dönüşüm motoru

MathJS; JavaScript için ifadeler, matrisler, büyük sayılar ve birimler konusunda kapsamlı özellikler sunar. Tarayıcıda veya Node.js ortamında kullanılabilir. Temel bir dönüşüm oldukça kısa yazılır:

import { create, all } from "mathjs";

const math = create(all);

function donustur(deger, kaynak, hedef) {
  const miktar = math.unit(deger, kaynak);
  return miktar.toNumber(hedef);
}

console.log(donustur(10, "km", "m")); // 10000
console.log(donustur(25, "degC", "degF")); // 77

math.unit() sayıyı birimiyle birlikte temsil eder. toNumber() ise miktarı hedef birime çevirerek sayısal sonucu döndürür. Bu yöntem, dönüşüm katsayılarını elle yazmaktan daha güvenlidir.

Kullanıcı girişleri doğrudan işlenmemeli; hata yakalama mekanizması eklenmelidir:

function guvenliDonustur(deger, kaynak, hedef) {
  try {
    if (!Number.isFinite(deger)) {
      throw new Error("Geçerli bir sayı girilmedi.");
    }

    const sonuc = math.unit(deger, kaynak).toNumber(hedef);
    return { basarili: true, sonuc };
  } catch (hata) {
    return { basarili: false, mesaj: hata.message };
  }
}

Bu fonksiyon arayüzün çökmesini önler ve kullanıcıya açıklayıcı geri bildirim sağlar.

Arayüz ve geliştirme fikirleri

Başarılı bir dönüştürme sitesi; kategori seçimi, iki birim listesi, değer alanı ve birimleri ters çevirme düğmesi içermelidir. Son kullanılan dönüşümleri yerel depolamada saklamak da kullanıcı deneyimini iyileştirir.

Özel birimler math.createUnit() ile tanımlanabilir. Böylece uygulamaya yerel ölçüler veya projeye özgü teknik birimler eklenebilir. Son aşamada otomatik testlerle bilinen eşitlikler doğrulanmalıdır: $1\,inch=2.54\,cm$ ve $0\,^{\circ}C=32\,^{\circ}F$ gibi. Böylece siteniz yalnızca şık görünmez; hesap yaparken de cetveli ters tutmaz.

``

Üç platform, üç yaklaşım

Decidim, Barselona çıkışlı kapsamlı bir katılımcı demokrasi altyapısıdır. Teklif oluşturma, destek toplama, toplantı düzenleme, anket, bütçeleme ve sonuç takibi gibi süreçleri modüler biçimde sunar. Bir dilekçe sistemi kurmanın yanında tüm karar alma döngüsünü yönetmek isteyen kurumlara uygundur.

CONSUL DEMOCRACY, vatandaş önerileri, tartışmalar, oylamalar ve katılımcı bütçeleme üzerine yoğunlaşır. Teklif belirli bir destek eşiğine ulaştığında değerlendirme ya da oylama aşamasına geçirilebilir. Bu nedenle klasik “öneri ver, imza topla, gündeme taşı” modeliyle oldukça uyumludur.

FixMyStreet ise doğrudan bir dilekçe platformu değildir. Vatandaşların harita üzerinde çukur, kırık sokak lambası veya kaçak döküm gibi yerel sorunları bildirmesini sağlar. Bildirim, konuma göre sorumlu kuruma yönlendirilir ve çözüm durumu kamuya açık şekilde izlenebilir.

İmza sistemi nasıl düşünülmeli?

Basit modelde her dilekçenin bir destek sayısı ve hedefi bulunur. İlerleme oranı şöyle hesaplanabilir:

Burada $S$ doğrulanmış destek sayısını, $H$ hedeflenen desteği, $P$ ise yüzde ilerlemeyi ifade eder. Örneğin 2.000 destek hedefleyen bir öneri 1.250 doğrulanmış imzaya ulaştığında ilerleme oranı yüzde 62,5 olur.

Fakat yalnızca sayaç tutmak yeterli değildir. Aynı kişinin tekrar imza atması engellenmeli, e-posta veya kimlik doğrulaması yapılmalı ve kişisel veriler gereksiz yere yayımlanmamalıdır. İdeal süreç şu durum makinesini izleyebilir:

Taslak → Moderasyon → Yayında → Eşik Aşıldı → Kurumsal İnceleme → Sonuçlandı

Aşağıdaki basitleştirilmiş Python fonksiyonu, doğrulanmış ve benzersiz destekleri sayar:

def petition_progress(signatures, target):
    # Doğrulanmış kullanıcı kimliklerini kümeye alarak tekrarları eler.
    verified_users = {
        item["user_id"]
        for item in signatures
        if item["verified"] is True
    }

    support_count = len(verified_users)
    percentage = min((support_count / target) * 100, 100)

    return {
        "support_count": support_count,
        "percentage": round(percentage, 2),
        "threshold_reached": support_count >= target
    }

Gerçek sistemde user_id değerleri herkese açık gösterilmemeli; mümkünse tek yönlü özetler, yetkilendirme katmanları ve kayıt saklama politikaları kullanılmalıdır. Ayrıca kötüye kullanım önleme mekanizması erişilebilirliği bozmamalıdır: aşırı CAPTCHA kullanımı gerçek vatandaşları da kaçırabilir.

Hangisini seçmelisiniz?

Seçimde yalnızca özellik listesini değil; kurulum ekibinin Ruby/Rails deneyimini, barındırma bütçesini, moderasyon kapasitesini, çok dillilik ihtiyacını ve kurum içi süreçleri de değerlendirmek gerekir. En parlak arayüz bile arka tarafta dilekçeyi yanıtlayacak bir iş akışı yoksa dijital bir öneri kutusuna dönüşür.

Sonuç olarak Decidim geniş kapsamlı bir demokrasi laboratuvarı, CONSUL DEMOCRACY yapılandırılmış bir öneri ve oylama motoru, FixMyStreet ise konum tabanlı belediye sorunları için uzmanlaşmış bir araçtır. Başarılı seçim, “Hangisi daha güçlü?” sorusundan önce “Vatandaş hangi sürece katılacak?” sorusunu yanıtlamakla başlar.

``

Oylamanın teorik temeli

Basit çoğunluk oylamasında aday $i$ için kullanılan oy sayısını $v_i$ ile gösterirsek kazanan şöyle bulunur:

Ancak gerçek dünyadaki her karar “tek aday seç” biçiminde değildir. Seçmenler adayları sıralayabilir, birden fazla seçeneği destekleyebilir veya bütçe önerilerine oy verebilir. Ayrıca sistemin dört temel beklentiyi dengelemesi gerekir:

• Gizlilik: Bir oyun kime ait olduğu açıklanmamalıdır.
• Bütünlük: Oylar değiştirilememeli veya silinememelidir.
• Doğrulanabilirlik: Seçmen, oyunun sayıma katıldığını kontrol edebilmelidir.
• Uygunluk: Yalnızca yetkili kişiler ve izin verilen sayıda oy kullanabilmelidir.

Bu özellikler bazen çatışır. Kimlik doğrulamasını güçlendirmek gizlilik riskini artırabilir; tamamen anonim katılım ise mükerrer oyları engellemeyi zorlaştırabilir.

Üç platform, üç farklı karakter

Helios Voting: Matematik sandık başında

Helios, oyları açık anahtarlı şifreleme ile korur ve seçim sonucunun doğrulanabilmesi için kriptografik kanıtlar üretir. Homomorfik şifrelemenin sadeleştirilmiş fikri şudur:

Yani sistem, tek tek oyların içeriğini açmadan şifreli oyları birleştirip toplamı elde edebilir. Seçmen genellikle oyuna karşılık gelen bir takip değeri alır ve bu değerin yayımlanan sandık kayıtlarında bulunup bulunmadığını denetler. Böylece “oyum kayboldu mu?” sorusu teknik olarak kontrol edilebilir.

Bununla birlikte uçtan uca doğrulanabilirlik, seçmenin cihazında zararlı yazılım bulunmadığını otomatik olarak garanti etmez. Resmî ve yüksek riskli seçimlerde bağımsız güvenlik incelemesi şarttır.

Decidim: Oylamadan daha büyük bir sahne

Ruby on Rails tabanlı açık kaynak Decidim, yalnızca sandık kurmaz; karar alma sürecini baştan sona modellemeye çalışır. Katılımcılar öneri oluşturabilir, tartışabilir, toplantılara katılabilir ve bütçe projelerini destekleyebilir.

Bu nedenle Decidim’i “seçim uygulaması” yerine katılım altyapısı olarak düşünmek daha doğrudur. Bir belediyenin park önerilerini toplaması, projeleri tartışmaya açması ve ardından bütçe oylaması yapması için uygundur. Süreç şeffaflığı güçlüdür; fakat gizli oy gerektiren kritik seçimlerde kullanılacak özel bileşenler ayrıca incelenmelidir.

CIVS: Tercih sıralarının gücü

CIVS, seçmenlerin adayları sıralamasına dayanır. Condorcet yaklaşımında bir aday, diğer her adayı ikili karşılaştırmada yeniyorsa kazanan kabul edilir. $P(a,b)$, $a$ adayını $b$ adayına tercih edenlerin sayısı olsun:

Bu yöntem, yalnızca birinci tercihleri saymak yerine seçmenlerin genel eğilimini yakalar. Ancak döngüler oluşabilir: A, B’yi; B, C’yi; C de A’yı yenebilir. CIVS bu durumları çözmek için belirli Condorcet tamamlayıcı yöntemlerinden yararlanır.

Aşağıdaki Python kodu, iki aday arasındaki basit ikili üstünlüğü hesaplar:

def pairwise_winner(rankings, a, b):
    scores = {a: 0, b: 0}

    for ranking in rankings:
        if ranking.index(a) < ranking.index(b):
            scores[a] += 1
        else:
            scores[b] += 1

    if scores[a] == scores[b]:
        return 'berabere'
    return max(scores, key=scores.get)

Fonksiyon, her sıralamada hangi adayın daha yukarıda bulunduğunu kontrol eder. Gerçek bir Condorcet sistemi, bu işlemi bütün aday çiftleri için yaparak bir karşılaştırma matrisi oluşturur.

Hangisini seçmeli?

Kriptografik doğrulanabilirlik önceliğinizse Helios, kapsamlı katılımcı süreçler tasarlıyorsanız Decidim, seçenekleri adil biçimde sıralamak istiyorsanız CIVS güçlü adaylardır. Son karar; tehdit modeline, seçmen kitlesine, kimlik doğrulama ihtiyacına ve kullanılan seçim yönteminin anlaşılabilirliğine dayanmalıdır. Unutmayın: İyi bir dijital sandık yalnızca doğru sonucu üretmez, sonucun neden güvenilir olduğunu da gösterebilir.

``

Önce veri modelini anlayalım

En basit sözlük girdisini matematiksel olarak şöyle gösterebiliriz:

Burada $T$ terimi, $D$ tanımı, $C$ kategorileri, $R$ ilişkili girdileri ve $M$ kaynak, yazar, tarih gibi meta verileri temsil eder. Gerçek projelerde bir terimin birden fazla anlamı bulunabileceğinden ilişki çoğu zaman $T \rightarrow {D_1, D_2, \ldots, D_n}$ biçimindedir.

Arama başarısını ölçmek için de iki temel kavram kullanılır:

Yani kullanıcı doğru yazdığında sonuç göstermek yetmez; yazım hataları, çekim ekleri ve eş anlamlılar da düşünülmelidir.

Üç yaklaşımın karşılaştırması

WordPress Glossary

WordPress tabanlı çözümde terimler genellikle özel yazı türü, yani custom post type, olarak tutulur. Kategoriler için taxonomy, ek bilgiler için özel alanlar kullanılabilir. En büyük avantaj, yönetim panelinin tanıdık olması ve SEO, önbellek, kullanıcı rolü gibi ihtiyaçların eklentilerle çözülebilmesidir.

Aşağıdaki kod basit bir terim içerik türü oluşturur:

add_action('init', function () {
    register_post_type('terim', [
        'label' => 'Terimler',
        'public' => true,
        'has_archive' => true,
        'rewrite' => ['slug' => 'sozluk'],
        'supports' => ['title', 'editor', 'revisions']
    ]);
});

Bu yapı her sözlük maddesine ayrı URL verir ve WordPress revizyon sistemini etkinleştirir. Ancak binlerce özel alanla karmaşık dilbilimsel ilişkiler kurulacaksa veri tabanı sorguları dikkatle tasarlanmalıdır.

MediaWiki

MediaWiki, çok sayıda kullanıcının içerik üretmesi ve değişikliklerin şeffaf biçimde izlenmesi gereken projelerde parlar. Şablonlar sayesinde girdiler standartlaştırılabilir:

{{Terim
|ad=Özyineleme
|tanım=Bir işlevin kendisini çağırmasıdır.
|kategori=Programlama
|eşanlamlı=Rekürsiyon
}}

Bu şablon, editörlerin aynı alanları tutarlı biçimde doldurmasını sağlar. Tartışma sayfaları, değişiklik karşılaştırmaları ve geri alma mekanizması büyük avantajdır. Buna karşılık ziyaretçiye sade bir sözlük deneyimi sunmak için tema, şablon ve arama yapılandırması gerekebilir.

DictPress

DictPress yaklaşımı, genel amaçlı sayfalardan çok madde, anlam, örnek ve çapraz başvuru ilişkilerine odaklanır. Bu nedenle iki dilli sözlükler veya dilbilimsel projeler için daha doğal bir model sunabilir. Dezavantajı, WordPress ve MediaWiki kadar geniş eklenti ekosistemine sahip olmayabilmesi ve seçilen sürüme göre bakım durumunun mutlaka incelenmesidir.

Hangisini seçmeli?

Hızlı yayın, modern tema ve SEO istiyorsanız WordPress Glossary; açık katkı, güçlü geçmiş takibi ve topluluk yönetimi istiyorsanız MediaWiki daha uygundur. Anlam, köken, telaffuz ve çeviri gibi alanların birinci sınıf veri olarak saklanması gerekiyorsa DictPress değerlendirilebilir.

Son kararı yalnız özellik listesine göre vermeyin. Önce 50 örnek terim girin, arama senaryolarını deneyin ve dışa aktarma imkânını kontrol edin. Çünkü iyi bir sözlük yalnız kelimeleri saklamaz; kelimeler arasındaki görünmez köprüleri de korur.

``

Dosya arama sistemi nasıl çalışır?

Bir arama motoru dosyaları doğrudan sihirli biçimde anlamaz. Önce dosyanın metni çıkarılır, temizlenir ve indekslenebilir bir belgeye dönüştürülür. Tipik veri akışı şöyledir:

1. Dosya sisteme yüklenir.
2. Apache Tika, PDF.js veya benzeri bir araçla metin çıkarılır.
3. Başlık, dosya yolu, uzantı ve kullanıcı izinleri gibi metadata eklenir.
4. Belge arama motoruna gönderilir.
5. Kullanıcı sorgusu indeks üzerinde çalıştırılır.

Bu sistemlerin temelinde ters indeks bulunur. Geleneksel bir listede her belgenin içindeki kelimeler tutulurken ters indeks, her kelimenin hangi belgelerde geçtiğini saklar:

Böylece motor, bütün dosyaları tek tek okumak yerine ilgili kayıtları doğrudan bulur. Alaka sıralamasında sık kullanılan BM25 yaklaşımının basitleştirilmiş fikri şöyledir:

Burada $TF$, kelimenin belgede ne kadar sık geçtiğini; $IDF$ ise kelimenin tüm koleksiyon içindeki ayırt ediciliğini temsil eder. Örneğin “dosya” kelimesi sıradanken “Kubernetes” daha yüksek ayırt ediciliğe sahip olabilir.

Üç arama motorunun karşılaştırması

Elasticsearch, devasa veri kümeleri, dağıtık mimari ve ayrıntılı sorgu ihtiyacı olduğunda güçlüdür. Ancak shard, analyzer ve mapping gibi kavramları öğrenmek gerekir. Küçük bir proje için uzay mekiğiyle markete gitmek gibi hissedilebilir.

Meilisearch, geliştirici deneyimine odaklanır. Yazım hatalarını otomatik tolere eder ve iyi sonuçlara ulaşmak için uzun yapılandırmalar istemez. MVP, kurum içi doküman araması ve içerik siteleri için oldukça pratiktir.

Typesense ise sadelik ile kontrol arasında güzel bir denge kurar. Şema tanımı zorunludur; bu yaklaşım ilk aşamada ek iş çıkarsa da veri yapısının tutarlı kalmasını sağlar.

Örnek belge indeksleme

Aşağıdaki JavaScript kodu, metni çıkarılmış bir dosyayı Meilisearch indeksine ekler:

import { MeiliSearch } from 'meilisearch';

const client = new MeiliSearch({
  host: 'http://localhost:7700',
  apiKey: process.env.MEILI_MASTER_KEY
});

const documents = client.index('documents');

await documents.addDocuments([
  {
    id: 'rapor-2026',
    title: '2026 Güvenlik Raporu',
    path: '/raporlar/guvenlik.pdf',
    extension: 'pdf',
    content: 'Sunucu güvenliği, erişim kontrolü ve yedekleme...',
    allowedUsers: ['user-17', 'user-42']
  }
]);

const result = await documents.search('sunucu güvenligi', {
  filter: 'allowedUsers = user-17',
  limit: 10
});

console.log(result.hits);

Kod, belgeyi documents indeksine ekler ve yazım hatası içeren bir sorgu çalıştırır. Gerçek projede erişim filtresi kritik önemdedir: Kullanıcının göremediği bir dosya, arama sonucunda da görünmemelidir. Ayrıca API anahtarını istemci tarafına koymak yerine backend üzerinde saklamak gerekir.

Hangisini seçmeli?

Milyonlarca belge, karmaşık filtreler ve ayrıntılı analiz gerekiyorsa Elasticsearch doğru adaydır. Birkaç saatte çalışan, kullanıcı dostu bir arama deneyimi hedefleniyorsa Meilisearch öne çıkar. Düşük gecikme, güçlü yazım toleransı ve açık bir veri şeması isteniyorsa Typesense tercih edilebilir.

Motor seçiminden bağımsız olarak başarıyı belirleyen asıl unsurlar; kaliteli metin çıkarma, doğru metadata, Türkçe dil analizi, yetkilendirme ve düzenli indeks güncellemesidir. Motor arabanın kalbidir; fakat tekerlekler yoksa hiçbir yere gidemezsiniz.

Zihin haritasının teorik mantığı

İnsan zihni bilgileri yalnızca doğrusal listeler şeklinde saklamaz. Kavramlar arasında çağrışımlar, hiyerarşiler ve neden-sonuç bağlantıları kurar. Zihin haritası da bu yapıyı taklit eder: merkezde ana konu, çevresinde alt başlıklar ve onların altında ayrıntılar bulunur.

Bir haritanın kullanılabilirliğini basitçe şöyle düşünebiliriz:

Burada $V$ haritanın sağladığı zihinsel verim, $B$ görünür bağlantıların faydası, $K$ görsel karmaşıklık ve $G$ gereksiz ayrıntıdır. Daha fazla düğüm eklemek her zaman daha iyi değildir. Amaç, beynin yükünü başka bir yere taşırken yeni bir görsel canavar oluşturmamaktır.

İyi bir sistem üç katmandan oluşabilir:

1. Yakalama: Fikirleri sansürlemeden hızla kaydetmek.
2. Düzenleme: Benzer fikirleri gruplamak ve ilişkileri tanımlamak.
3. Sunma: Haritayı başkalarının anlayabileceği temiz bir çıktıya dönüştürmek.

Hangi araç ne zaman kullanılmalı?

Mindmaps türü araçlarda Tab ile alt dal, Enter ile kardeş dal açmak düşünce akışını hızlandırır. draw.io, ızgara ve bağlayıcıları sayesinde düzenli sonuç verir. Excalidraw’ın el çizimi görünümü ise taslağın henüz değişebilir olduğunu hissettirir; böylece ekip üyeleri kusursuz görünen bir diyagramı eleştirmekten çekinmez.

Tek araç yerine iş akışı kurmak

En verimli yöntem, araçları rakip değil aşama olarak görmektir. Örneğin yeni bir yazılım projesinde fikirleri önce Mindmaps veya Excalidraw üzerinde toplayabilir, ardından kalıcı mimariyi draw.io ile çizebilirsin.

Akışı kodla ifade etmek, sistemin tekrar kullanılmasını kolaylaştırır. Aşağıdaki Mermaid şeması fikirden dokümantasyona giden süreci tanımlar:

flowchart LR
    A[Ham fikirler] --> B[Mindmap ile dallandır]
    B --> C{Harita karmaşık mı?}
    C -- Hayır --> D[Excalidraw ile anlat]
    C -- Evet --> E[draw.io ile yapılandır]
    D --> F[Ekiple gözden geçir]
    E --> F
    F --> G[Dokümantasyona ekle]

Bu kod, desteklenen Markdown ortamlarında görsel diyagrama dönüşür. Ayrıca draw.io içindeki Mermaid ekleme özelliğiyle başlangıç şeması olarak kullanılabilir. Böylece kutuları tek tek oluşturmadan yapıyı kodla kurup daha sonra görsel olarak düzenlersin.

Sürdürülebilir haritalar için kurallar

Her düğümde mümkünse üç ila beş kelime kullan. Renkleri dekorasyon için değil, anlam taşımak için seç: kırmızı risk, yeşil tamamlanan iş, mavi bilgi gibi. Çapraz bağlantıları yalnızca gerçekten ilişki varsa ekle; aksi hâlde harita örümcek ağına döner.

Dosya adlarında da ortak bir düzen benimse:

proje-konu-asama-tarih.ext
odeme-sistemi-fikirler-2026-09.excalidraw
odeme-sistemi-mimari-v2.drawio

Son olarak her haritaya bir amaç sorusu yaz: “Bu harita hangi kararı vermeme yardım edecek?” Cevap yoksa muhtemelen düşünce üretmiyor, yalnızca renkli kutular biriktiriyorsundur. Doğru araç ve sade kurallarla zihin haritası, fikir mezarlığı değil yaşayan bir düşünme sistemi olur.

``

Aynı tablo, farklı düşünce biçimleri

Bu araçları karşılaştırmadan önce elektronik tablo ile veritabanı arasındaki temel farkı anlamalıyız. Elektronik tabloda hücreler merkezdedir; veritabanında ise kayıtlar, alanlar ve aralarındaki ilişkiler önemlidir.

Bir sipariş tablosunun toplam tutarı basitçe şöyle hesaplanabilir:

Burada $q_i$ ürün miktarını, $p_i$ birim fiyatı temsil eder. EtherCalc bu hesabı doğrudan hücre formülleriyle yapar. Baserow ve NocoDB ise miktar ile fiyatı yapılandırılmış alanlarda saklayıp hesaplanan alanlar veya sorgular üzerinden işler. Veri büyüdüğünde bu ayrım oldukça önemlidir.

EtherCalc: Hemen aç, birlikte yaz

EtherCalc, Google Sheets benzeri gerçek zamanlı bir çalışma deneyimi sunar. Hesap oluşturma zorunluluğu olmadan tablo paylaşabilmesi, toplantılar, geçici listeler ve ortak hesaplamalar için büyük kolaylıktır. Formül bilen biri araca neredeyse anında uyum sağlar.

Bununla birlikte EtherCalc bir veritabanı değildir. Karmaşık kayıt ilişkileri, ayrıntılı yetkilendirme veya gelişmiş otomasyon gerektiğinde sınırlarına çabuk ulaşır. Kısacası hızlıdır; fakat kurumsal veri mimarisinin omurgası olmaya çalışmaz.

Baserow: Tablodan uygulamaya geçiş

Baserow, elektronik tablo rahatlığını ilişkisel veritabanı disipliniyle birleştirir. Metin, sayı, seçim, dosya ve bağlantılı kayıt gibi alan türleri tanımlanabilir. Örneğin müşteriler ile siparişleri ayrı tablolarda tutup birbirine bağlayabilirsiniz. Böylece müşteri adı değiştiğinde yüzlerce satırı elle düzeltmeniz gerekmez.

Basit bir otomasyon istemcisi şu şekilde kayıt ekleyebilir:

import requests

url = "https://baserow.example/api/database/rows/table/42/"
headers = {"Authorization": "Token API_ANAHTARI"}
data = {"Musteri": "Ada Yazılım", "Tutar": 4800, "Durum": "Yeni"}

response = requests.post(url, headers=headers, json=data)
response.raise_for_status()
print(response.json())

Bu kod, Baserow API’sine yeni bir satış kaydı gönderir. Gerçek projelerde anahtarın kaynak kod yerine ortam değişkeninde saklanması gerekir.

NocoDB: SQL veritabanına kullanıcı dostu yüz

NocoDB’nin yıldızlaştığı nokta, mevcut SQL veritabanlarını anlaşılır bir tablo arayüzüne dönüştürmesidir. PostgreSQL veya MySQL kullanan bir ekip, teknik olmayan çalışanlara doğrudan SQL öğretmeden veriye erişim sağlayabilir. Görünümler, ilişkiler, API erişimi ve rol tabanlı izinler operasyon araçları geliştirmeyi kolaylaştırır.

Hangisini seçmelisiniz?

Karar formülünü basitleştirirsek, seçim puanı $S$; kullanım kolaylığı $K$, veri ilişkisi ihtiyacı $R$ ve mevcut altyapıyla uyum $U$ üzerinden düşünülebilir:

Sadece birlikte hücre düzenlemek istiyorsanız EtherCalc yeterlidir. Kod yazmadan düzenli bir iş uygulaması kuracaksanız Baserow daha dengeli bir seçimdir. Halihazırda SQL veritabanınız varsa NocoDB en doğal köprüdür. Üçü de kendi sunucunuza kurulabildiği için veri kontrolü sağlar; ancak yedekleme, güncelleme ve erişim güvenliği sorumluluğunu da size bırakır. Yani özgürlük ücretsizdir, fakat sistem yöneticisi kahvesi bütçeye dahildir!