i18n, bölgesel yönlendirme, veri kuralları ve içerik iş akışlarına pratik bir yaklaşım öğrenin—çevirileri hızlandırmak ve hataları azaltmak için yapay zekayı kullanma yollarını keşfedin.
Bir çok dilli uygulama esas olarak dil ile ilgilidir: UI metinleri, mesajlar, e-postalar, yardım içerikleri ve kullanıcı veya sistem tarafından oluşturulan herhangi bir metin birden fazla dilde doğal okunmalıdır.
Bir çok bölgeli uygulama ise deneyimin nerede ve hangi kurallar altında sunulduğu konusuyla ilgilidir. Bölge, yalnızca çeviriden çok daha fazlasını etkiler: para birimi ve vergiler, zaman dilimleri ve tarih formatları, ölçü birimleri, özelliklerin kullanılabilirliği, veri yerleşimi ve gizlilik gereksinimleri ve hatta hukuki ifadeler.
Dil'i “nasıl iletişim kurduğumuz” ve bölge'yi “hangi kurallar geçerli” olarak düşünün. Elinizde olabilir:
Takımlar genellikle "locale'a bağlı" olan şeylerin sayısını küçümser. Sadece string'ler değildir:
AI bir çok tekrarlayan işi ortadan kaldırabilir: çeviri taslakları hazırlama, tutarlı terminoloji önerme, çevrilmemiş stringleri tespit etme ve yerelleştirme iş akışındaki yinelemeyi hızlandırma. En güçlü olduğu alanlar otomasyon ve tutarlılık kontrolleridir.
Yine de bu sihir değildir. Kaynak metin net olmalı, hukuki/uyumluluk metinleri için sahiplik belirlenmeli ve yüksek riskli içerikler için insan incelemesi gereklidir.
Bu rehber pratik kalır: uygulayabileceğiniz kalıplar, dikkat edeceğiniz takaslar ve yönlendirme, veri yerleşimi, ödemeler ve ölçeklenebilir çeviri iş akışlarına geçerken yeniden kullanabileceğiniz kontrol listeleri.
Araçları (veya bir AI çeviriciyi) seçmeden önce ürününüz için “farklı” olanın gerçekten ne olduğunu netleştirin. Çok dilli ve çok bölge çalışmaları, takımların bunu yalnızca UI metni zannettiğinde en sık başarısız olur.
Hızlıca hangi şeylerin diller ve bölgeler arasında değiştiğini envanterleyin:
en-GB vs en-US gibi) ve hangi ülkelerde faaliyet göstereceksiniz.Bunları "zorunlular" ve "sonra" olarak yazın; kapsam büyümesi yayınları yavaşlatan en hızlı yoldur.
İlk günden takip edebileceğiniz birkaç metrik seçin:
Yüzeyleri açıkça belirtin, sadece “uygulama” demek yeterli değil:
UI string'leri, onboarding, işlem e-postaları, faturalar/fişler, push bildirimleri, yardım dokümanları, pazarlama sayfaları, hata mesajları ve hatta dokümanlardaki ekran görüntüleri.
Matris, herkesin gerçekten hangi kombinasyonları desteklediği konusunda aynı fikirde olmasını sağlar.
| Yerel | Bölge | Para birimi | Notlar |
|---|---|---|---|
| en-US | US | USD | Satış vergisi eyalete göre değişir |
| en-GB | GB | GBP | Fiyata KDV dahil gösteriliyor |
| fr-FR | FR | EUR | Resmi ton, yerelleştirilmiş hukuki sayfalar |
| es-MX | MX | MXN | Yerel ödeme yöntemleri gerekli |
Bu matris kapsam sözleşmeniz olur: yönlendirme, biçimlendirme, uyumluluk, ödemeler ve QA hepsi buna referans vermelidir.
i18n temeli "sıkıcı" kısım olabilir ama sonraki pahalı yeniden yazmaları önler. Bir tek string çeviriye başlamadan önce, ürününüz kullanıcıların dil ve bölge tercihini nasıl tanımlayacağını, bir şey eksik olduğunda nasıl davranacağını ve günlük bilgileri (para, tarih, isimler) nasıl tutarlı biçimlendireceğini karar verin.
Locale'lerinizin sadece dil (ör. fr) mi yoksa dil-bölge (ör. fr-CA) mi olacağına karar verin. Sadece dil daha basittir ama bölgesel farklılıklar önemliyse başarısız olur: yazım, hukuki metin, destek saatleri ve UI tonu bile değişebilir.
Pratik bir yaklaşım:
language-region kullanın (en-US, en-GB, pt-BR, pt-PT).\n- Farklılıkların önemsiz olduğundan ve yakında ayrı içerik gerekmeyeceğinden eminseniz yalnızca dil kullanın.Fallback'ler kullanıcılar ve ekibiniz için öngörülebilir olmalı. Belirleyin:
fr-CA bir anahtar eksikse fr'e, sonra en'e mi düşersiniz?\n- İçerik fallback: bir makale çevrilmemişse varsayılan dili gösterir misiniz, gizler misiniz veya "dilinizde mevcut değil" mesajı mı verirsiniz?\n- Biçimlendirme fallback: karışık gösterimlerden kaçının (ör. Fransızca metin ile US tarih formatı).Aşağıdaki için locale-dostu kütüphaneler kullanın:\n
Anahtarları İngilizce ifadeye bağlı kalmayacak şekilde, stabil ve açıklayıcı yapın. Örnek:
checkout.payment_method.title
errors.rate_limit.body
settings.notifications.email.label
Dosyaların nerede bulunduğunu belgeleyin (ör. /locales/{locale}.json) ve kod incelemede konvansiyonları uygulayın. Bu, sonradan AI destekli çeviri iş akışlarını daha güvenli ve otomatikleştirilebilir kılan temeldir.
İyi yönlendirme uygulamanızın "yerel" hissettirmesini sağlar; kullanıcıların bunu düşünmesine gerek kalmaz. İnce iş, dil (kullanıcının okuduğu metin) ile bölgeyi (hangi kurallar geçerli) ayırmaktır.
Bölge seçmek için üç yaygın yol vardır ve birçok ürün bunları birleştirir:
Pratik bir kural: son açık seçimi hatırlayın ve daha iyi bir sinyal yoksa yalnızca otomatik algılama yapın.
URL stratejisini erken seçin; çünkü daha sonra değiştirmek SEO ve paylaşılan linkleri etkiler.
/en-us/..., /fr-fr/... (barındırması basit, kullanıcı için net; CDN ile iyi çalışır)\n- Alt alan adları: us.example.com, fr.example.com (temiz ayrım; daha fazla DNS/sertifika ve analiz karmaşıklığı)\n- Sorgu parametreleri: ?lang=fr®ion=CA (uygulaması kolay ama SEO ve paylaşılabilirlik zayıf)Çoğu ekip için path prefixleri varsayılan olarak en iyisidir.
Yerelleştirilmiş sayfalar için planlayın:\n
x-defaultÖn uç yönlendirme kullanıcının ne göreceğine karar verir, ama bölge yönlendirmesi isteklerin nereye gideceğini belirler. Örnek: /en-au/ kullanıcısı AU fiyatlama servisini, AU vergi kurallarını ve (gerekliyse) AU veri depolamasını hedeflemeli—UI dili İngilizce olsa bile.
Tutarlı kalmak için isteklere tek bir “region” değeri geçirin (header, token claim veya oturum) ve bunu doğru arka uç uç noktalarını ve veritabanlarını seçmek için kullanın.
Veri yerleşimi, müşteri verilerinin nerede saklandığı ve işlendiği demektir. Çok bölgeli uygulamalarda bu önemlidir çünkü bazı kuruluşlar (ve bazı düzenlemeler) bir ülkedeki veya ekonomik bölgedeki kişilere ait verilerin belirli coğrafi sınırlar içinde kalmasını bekler.
Ayrıca güven meselesidir: müşteriler verilerinin beklenmedik şekilde sınır ötesine taşınmayacağını bilmek ister.
Topladıklarınızı ve nereye gittiğini listeleyin. Yaygın hassas kategoriler:
Sonra bu kategorileri depolama yerlerine eşleyin: ana veritabanı, analitik araçlar, günlükler, veri ambarı, arama indexi, yedeklemeler ve üçüncü taraf sağlayıcılar. Takımlar genellikle günlükler ve yedekler gibi merkezileştirilmiş alanların yerleşim beklentilerini ihlal edebileceğini unuturlar.
Doğru tek bir yaklaşım yok; açık bir politika ve buna uygun uygulama gerekir.
1) Bölgesel veritabanları (güçlü izolasyon)\n AB kullanıcılarını AB veri depolarında, ABD kullanıcılarını ABD depolarında tutun. Bu yerleşim için en net çözümdür ama operasyonel karmaşıklığı artırır.
2) Paylaşılan sistem içinde partition (kontrollü ayrım)\n Bölge bazlı partition'lar/schema'lar kullanın ve uygulama katmanında ve IAM kurallarıyla “bölge dışı okuma/yazma yok”u dayatın.
3) Şifreleme sınırları (maruziyeti azaltma)\n Verileri her yerde depolayın, ancak bölgeye özgü şifreleme anahtarları kullanarak yalnızca o bölgedeki servislerin hassas alanları çözebilmesini sağlayın. Bu riski azaltır ama tek başına sıkı yerleşim gereksinimlerini karşılamayabilir.
Uyumluluğu test edilebilir gereksinimler olarak ele alın:\n
Yayınladığınız her vaadi doğrulayabilmek için hukuki danışmanlık alın—bu bölüm, teknik temeli kurmaya odaklıdır, kesin sözler vermek için değil.
Ödemeler ve fiyatlama, "çok bölge"nin gerçeğe dönüştüğü yerdir. Aynı ürün sayfasını aynı dili okuyan iki kullanıcı görebilir ama farklı fiyatlar, vergiler, faturalar ve ödeme yöntemleri gerekir.
İnşa etmeden önce hangi öğelerin ülke/bölgeye göre değiştiğini listeleyin ve her kuralın sahibini belirleyin (ürün, finans, hukuk). Yaygın farklılıklar:
Bu envanter, arayüzde rastgele istisnaların çıkmasını engelleyen tek doğru kaynak olacaktır.
Bölgesel fiyat listeleri (tutarlı marjlar için önerilir) mi yoksa temel bir para biriminden dönüşüm mü yapacağınıza karar verin. Dönüşüm yaparsanız tanımlayın:
Bu kuralları checkout, e-postalar, makbuzlar ve iadelerde tutarlı uygulayın. Bir ekranda görülen toplamın başka bir ekranda değişmesi güven kaybettirir.
Ödeme UX'i formlar ve doğrulamada sıkça bozulur. Bölgeselleştirin:\n
Üçüncü taraf ödeme sayfaları kullanıyorsanız, locale'lerinizi ve bölgesel uyumluluk gereksinimlerini desteklediklerinden emin olun.
Bazı bölgeler özellikleri devre dışı bırakmanızı, ürünleri gizlemenizi veya farklı şartlar göstermenizi talep edebilir. Engellemeyi fatura ülkesine göre net bir iş kuralı olarak uygulayın, dil ile değil.
AI sağlayıcı gereksinimlerini özetlemekte ve kural tabloları taslaklamada yardımcı olabilir, ancak fiyatları, vergileri veya hukuki metni etkileyen her şeyi insanların onaylamasını sağlayın.
Yerelleştirmeyi ölçeklendirmek daha hızlı çeviri yapmak değil, içeriğin tahmin edilebilir kalmasını sağlamakla ilgilidir: ne çevrilecek, kim çevirecek ve değişiklikler taslaktan üretime nasıl geçecek.
UI mikro metinlerini (butonlar, hata mesajları, navigasyon) uygulamayla birlikte dağıtılan kod stringleri olarak, genelde repoda yönetilen çeviri dosyalarında tutun. Pazarlama sayfaları, yardım makaleleri ve uzun biçimli metinleri ise editörlerin dağıtım gerektirmeden çalışabileceği bir CMS'de tutun.
Bu ayrım, mühendislerin bir çeviriyi “düzeltmek” için CMS içeriğini değiştirmeye başlamasını veya editörlerin sürümle beraber versiyonlanması gereken UI metinlerini değiştirmesini önler.
Ölçeklenebilir bir yaşam döngüsü basit ve tekrarlanabilir olmalıdır:
Sahipliği açıkça belirtin:\n
Çeviri, ekipler değişiklikleri ayırt edemediğinde bozulur. Kaynak metinleri sürümlerle ilişkilendirin, düzenlenen kaynak metinler için bir değişiklik günlüğü tutun ve locale başına çeviri durumunu izleyin. Hafif bir kural—“kaynak metin değişiklikleri bir ticket olmadan yapılmaz”—beklenmedik regresyonları azaltır ve dillerin senkron kalmasını sağlar.
AI çok tekrar eden işi ortadan kaldırabilir ama sadece onu bir yardımcı olarak kullanırsanız faydalıdır; yetkili karar verici olarak değil. Hedef, diller ve bölgeler arasında kalite düşüşü olmadan daha hızlı yinelemektir.
Yeni yüzeyler hızla inşa ediyorsanız, bir "vibe-coding" iş akışı da fayda sağlayabilir: Koder.ai gibi platformlar ekiplerin sohbet üzerinden uygulama akışlarını prototipleyip lokalizasyon, yönlendirme ve bölge kurallarında hızlıca yineleme yapmasını sağlar. Önemli olan hâlâ aynı: locale/bölge kararlarını açıkça yapmak, sonra meşgul işleri otomatikleştirmektir.
Büyük ölçekli taslak çeviriler güçlü bir kullanım alanıdır. AI aracınıza glosary'inizi (onaylı terimler, ürün isimleri, hukuki ifadeler) ve ton rehberinizi verin (resmi vs samimi, "siz" vs "biz", noktalama kuralları). Bu kısıtlarla AI, hızlıca gözden geçirilmesi için yeterince tutarlı bir ilk-pass çeviri üretebilir.
AI ayrıca kullanıcıya ulaşmadan önce sorunları bulmakta iyidir:\n
{name} kaybolması, ekstra boşluklar, hatalı HTML)\n- UI düzenini bozabilecek şüpheli uzunluk değişimleriSon olarak, AI bölgeye uygun varyantlar önerebilir. Örneğin en-US vs en-GB farklarını önerirken anlamı sabit tutabilir. Bu önerileri otomatik değişiklikler olarak değil, öneri olarak kabul edin.
Bazı içerikler ürün, hukuki veya itibar riski taşır ve insan onayı olmadan yayınlanmamalıdır:\n
Pratik bir korunma: AI taslak hazırlar, kritik kullanıcı içeriği insan onayı ile yayınlanır. İş akışınıza her string veya sayfa için bir “inceleme” durumu ekleyin ki neyin güvenle yayınlanacağını açıkça bilin.
Tutarlılık çok dilli bir uygulamanın "yerel" hissettirmesini sağlar; sadece çevrilmiş değil, doğal görünür. Kullanıcı, aynı düğmenin bir ekranda "Checkout" diğerinde "Pay" olmasından veya destek makalelerinin birinde samimi diğerinde aşırı resmi olmasından rahatsız olur.
Ürün terimleri ("workspace", "seat", "invoice"), hukuki ifadeler ve destek metinlerini kapsayan bir sözlük başlatın. Tanımlar, izin verilen çeviriler ve marka isimleri veya teknik token'lar için "çevirme" notları ekleyin.
Sözlüğü ürün, pazarlama, hukuk ve destek dahil herkesin erişebileceği yerde tutun. Bir terim değiştiğinde ("Projects" → "Workspaces"), önce sözlüğü güncelleyin sonra çevirileri güncelleyin.
Ton evrensel değildir. Her dil için resmi vs gayri resmi hitap, cümle uzunluğu tercihleri, noktalama normları ve ödünç İngilizce kelimelere yaklaşımı belirleyin.
Her locale için kısa bir stil rehberi yazın (bir sayfa yeterli):\n
Çeviri hafızası, onaylanmış çevirileri saklar ve tekrar eden ifadelerin aynı çeviriyi vermesini sağlar. Özellikle değerli olduğu alanlar:\n
TM maliyeti ve inceleme süresini azaltır ve AI çıktılarını önceki kararlarla hizalı tutar.
"Close" bir fiil mi (modalı kapat) yoksa sıfat mı (yakın)? Ekran görüntüleri, karakter limitleri, UI konumu ve geliştirici notları ile bağlam sağlayın. Ham stringleri bir tabloya dökmek yerine yapılandırılmış anahtarlar ve metadata tercih edin—hem çevirmenler hem de AI niyeti bilince daha iyi ve tutarlı sonuç verir.
Yerelleştirme hataları genelde "küçük" görünür ta ki müşteriye değene kadar: checkout e-postası yanlış dilde, tarih yanlış ayrıştırılmış veya mobilde düğme metni kesiliyor. Amaç ilk günde mükemmel kapsam değil—en pahalı hataları otomatik yakalayan bir test yaklaşımı ve gerçekten bölgesel olanlar için manuel QA ayırmaktır.
Metin genişlemesi ve yazı sistemi farklılıkları düzenleri bozmanın en hızlı yoludur.\n
CI için hafif bir “pseudo-locale” (fazladan uzun string + aksanlı karakterler) harika bir gate’tir; gerçek çeviri olmadan sorunları bulur.
Yerelleştirme sadece metin değil—parsing ve sıralamayı değiştirir.\n
Her PR'de çalışacak hızlı kontroller ekleyin:\n
{count} bir dilde var ama diğerinde yok)Bunlar İngilizce dışı regresyonları engelleyen ucuz ama etkili güvenliklerdir.
Bölgesel kuralların en çok önemli olduğu akışlar için hedeflenmiş geçişler planlayın:\n
Her bölge için küçük, tekrarlanabilir bir kontrol listesi tutun ve lansman genişlemeden veya fiyat/uyumluluk ile ilgili kod değişiklikleri yapmadan önce çalıştırın.
Çok dilli, çok bölgeli bir uygulama toplu olarak "sağlıklı" görünebilir ama bir locale veya coğrafyada kötü çalışıyor olabilir. İzleme, locale (dil + biçimlendirme kuralları) ve bölge (trafik servis edilen yer, veri depolama ve ödeme işlemleri) kırılımına sahip olmalı ki sorunları kullanıcılar bildirmeden önce görebilesiniz.
Çekirdek ürün metriklerini locale/bölge etiketleriyle enstrümante edin: dönüşüm ve checkout tamamlanması, kayıt bırakma, arama başarısı ve ana özellik benimsemesi. Bunları hata oranları ve gecikme gibi teknik sinyallerle eşleştirin. Bir bölgedeki küçük bir gecikme artışı o pazarın dönüşümünü sessizce düşürebilir.
Panolar için bir “küresel görünüm” ve birkaç öncelikli segment (üst locale'ler, yeni bölge, en yüksek gelirli pazarlar) oluşturun; diğer her şey açılabilir detay olabilir.
Çeviri sorunları genellikle sessizdir. Günlükleyin ve trendini takip edin:\n
Bir sürüm sonrası fallback kullanımındaki ani artış, build'in locale paketleriyle birlikte gönderilmediğinin güçlü bir işaretidir.
Yönlendirme ve CDN anomalileri (yükselen 404/503, origin timeouts) için bölgeye özgü uyarılar ayarlayın; ayrıca ödeme sağlayıcılarına özgü hatalar gibi durumlar için de uyarılar oluşturun. Uyarıları eyleme geçirilebilir yapın: etkilenen bölge, locale ve son deploy/feature flag değişikliğini içersin.
Destek ticket'larını otomatik olarak locale ve bölge ile etiketleyin ve doğru kuyruğa yönlendirin. Pazara göre lokalize edilmiş küçük in-app geri bildirimler ekleyin ("Bu sayfa açık mıydı?") ki çeviri, terminoloji veya yerel beklentiler yüzünden oluşan kafa karışıklığını churn'e dönüşmeden önce yakalayın.
Çok dilli, çok bölgeli bir uygulama asla "tamamlanmış" değildir—öğrenmeye devam eden bir üründür. Yayının amacı riski azaltmaktır: küçük bir şeyi yayınlayın, gözlemleyin, sonra güvenle genişletin.
İnce bir dilim lansmanıyla başlayın: bir dil + bir ek bölge. Bu dilim, tam yolculuğu içermeli (kayıt, ana akışlar, destek dokunuşları ve faturalama eğer varsa). Gerçek dünya tarih formatları, adres alanları, hata mesajları ve uç vaka hukuki metinleri gibi ekran görüntülerinin kaçırdığı sorunları ortaya çıkaracaktır.
Her locale/bölge kombinasyonunu kontrollü bir sürüm birimi olarak düşünün. Locale/bölge bazlı feature flag'ler ile:\n
Zaten flag kullanıyorsanız, locale, country ve (gerekirse) currency hedefleme kuralları ekleyin.
Yerelleştirme sürüklenmesin diye hafif bir bakım döngüsü oluşturun:\n
Sonraki adımlar: bu kontrol listesini ekibinizin gerçekten kullandığı bir yayın oyun kitabına dönüştürün ve yol haritanızın yakınında tutun (veya dahili dokümanlarınıza ekleyin). Daha fazla iş akışı fikri isterseniz, blog'a bakın.
Bir çok dilli uygulama, metinlerin nasıl sunulduğunu değiştirir: UI metinleri, e-postalar, dokümanlar. Bir çok bölgeli uygulama ise hangi kuralların uygulandığını değiştirir: para birimi, vergiler, kullanılabilirlik, uyumluluk ve veri yerleşimi. Birçok ürün her ikisine de ihtiyaç duyar; zorluk dili bölgesel iş mantığından ayrı tutmaktır.
İlk olarak gerçekten destekleyeceğiniz kombinasyonları (ör. en-GB + GB + GBP) listeleyen basit bir matrisle başlayın. Vergi dahil mi yoksa checkout’ta mı ekleniyor, hukuki sayfa varyantları, gerekli ödeme yöntemleri gibi büyük kural değişiklikleri için notlar ekleyin. Bu matris yönlendirme, biçimlendirme, ödemeler ve QA tarafından başvuru olarak kullanılacak kapsam sözleşmesidir.
Bölgesel farklılıklar önemliyse language-region kullanmayı tercih edin (yazım, hukuki metin, destek davranışı, fiyat kuralları gibi). Örneğin en-US vs en-GB veya pt-BR vs pt-PT. Yalnızca language (ör. fr) kullanın ancak yakın zamanda bölge varyantlarına ihtiyacınız olmayacağından eminseniz; sonradan ayırmak zorlayıcı olabilir.
fr-CA → fr → enBu üçü açıkça tanımlanmalı ve belgelendirilmeli, böylece mühendisler, QA ve destek aynı davranışı bekler.
Yerelleştirilmesi gerekenler: tarih/saatler (zaman dilimleri dahil), sayılar/ondalıklar, çoğul ve dilbilgisel varyantlar, isimler/adresler/telefonlar. Ayrıca bölge değerinin nereden geldiğini (hesap ayarı, kullanıcı seçimi, GeoIP önerisi) belirleyin, böylece biçimlendirme arka uçta uygulanan bölgesel kurallarla tutarlı olur.
Varsayılan olarak yol önekleri (/en-us/...) önerilir; bunlar CDN dostu, paylaşılabilir ve kullanıcılar için açıktır. SEO için planlayın:
x-default'u bağlayan hreflang setiURL yapısını erken seçin—sonradan değiştirmek indeksleme, analiz ve paylaşılan linkler üzerinde etkili olur.
Frontend yönlendirme kullanıcıya ne gösterileceğine karar verir; bölge yönlendirme ise isteklerin nereye gideceğini ve hangi kuralların uygulanacağını belirler. Tek bir bölge tanımlayıcısı (header, token claim veya oturum) ile isteği geçirip bunu kullanarak:
Bölgeyi dilden türetmekten kaçının; bunlar ayrı boyutlardır.
Veri yerleşimi, müşteri verilerinin nerede saklandığı ve işlendiğiyle ilgilidir. Başlangıç için hassas veri kategorilerinizi ana DB, günlükler, yedekler, analitik, arama ve üçüncü taraf sağlayıcılar arasında haritalayın—günlükler ve yedekler genellikle gözden kaçan alanlardır. Mimari seçenekler:
Uyumluluk sözünü verdiğinizde test edilebilir gereksinimler olarak ele alın ve hukuki danışmanlık alın.
Bölgesel farklılıkları belgeleyin ve her kuralın sahibi olarak ürün, finans veya hukuku atayın. Para birimi/fiyatlama seçenekleri:
Bu envanter, arayüzde ortaya çıkan rastgele istisnaları önleyecek olan tek doğru kaynaktır.
AI'yi taslak çeviriler, terminoloji tutarlılığı önerileri, eksik anahtar tespiti ve iş akışında yinelemeyi hızlandırmak için kullanın. Ancak AI son karar verici olmamalıdır. Kritik içerikler (fiyatlandırma, vergi, hukuki metinler, geri dönüşü olmayan işlemler) insan onayı olmadan yayınlanmamalıdır.