- Tibetçe metinler, genel kelime işlemcilerin kısa paragraf varsayımıyla uyuşmadığı için dijital düzenleme ve yayıncılık araçlarında uzun süredir pratik kısıtlamalar yaşıyordu
- BDRC, Tibetçenin dijital ortamlarda doğru şekilde ele alınması için teknik iyileştirmeler yürütüyordu; bu kez LibreOffice’in çok uzun paragraf desteği temel bir ilerleme oldu
- Zorunlu satır sonu olmadan akan uzun metinler ve az sayıda boşluk, İngilizce odaklı belge işleme yöntemlerinden farklı olduğundan, uzun Tibetçe metinleri açarken veya dönüştürürken performans sorunları yaşanması kolaydı
- Jonathan Clark’ın düzeltmesiyle, Longchenpa’nın Yishindzö’sü gibi 153 sayfalık tek bir “paragraf” metni bile artık hızlıca açılıp düzenlenebiliyor; RDF’den PDF’ye dönüştürme, 45 dakikadan uzun süre takılan bir işlemken 13 saniyede tamamlanıyor
- Çok uzun paragraf desteği, 27 Eylül 2024’te yayımlanan LibreOffice 24.8.2 sürümüne entegre edildi; böylece Tibetçe kullanıcıları ücretsiz açık kaynak yayıncılık araçlarını daha gerçekçi biçimde kullanabiliyor
Tibetçe dijital desteğin neden önemli olduğu
- BDRC’nin önemli görevlerinden biri, Tibetçeyi dijital dünyanın birinci sınıf vatandaşı yapmak için teknolojik yenilikler geliştirmek
- Tibetliler, 8. yüzyılda Budizmin kabulünden bu yana yazıya, yeniliğe ve teknolojiye büyük enerji ve kaynak ayırdı
- Tibet yazısı ve klasik dil, Sanskritçe ve Çince Budist metinleri Tibetlilerin anlayabileceği bir dile çevirmek için oluşturuldu
-
- yüzyılda kutsal metin çevirilerini ve Himalayalı yazarların Tibetçe Budist metinlerinden oluşan binlerce cildi seri üretmek için tahta baskı yaygın biçimde benimsendi
- Tibetçe bilgisayar fontlarının ortaya çıkışı ve Unicode Standard kapsamına alınması, Tibetçenin dijital dünyaya entegrasyonu sürecinde büyük bir sıçramaydı
Genel kelime işlemcilerle uyuşmayan Tibetçe metin yapısı
- Tibetçe metinlerin, henüz tüm araç ve uygulamaların yeterince desteklemediği özellikleri var
- Özellikle Avrupa dillerindeki paragraf kavramı aynı şekilde uygulanmıyor
- Tibetçe metinlerin çoğu zaman zorunlu satır sonu olmadan devam eden uzun bir akış olarak işlenmesi gerekiyor
- Bu akış bazen yüzlerce, hatta binlerce sayfaya ulaşabiliyor
- Genel kelime işlemciler başlangıçta İngilizce metinler düşünülerek tasarlandı
- Görece kısa paragrafları varsayarlar
- Kelimeler arasında boşluk olduğunu ve bu boşlukların genişliğinin esnek biçimde ayarlanabileceğini kabul ederler
- Tibetçe metinlerde paragraf uzunluğu fiilen sınırsızdır ve boşluk çok azdır; bu da bu varsayımlarla çakışır
- Sonuç olarak uzun Tibetçe metinleri açarken kelime işlemciler çok yavaşlayabilir veya hiç çalışmayabilir; bu da onları ciddi yayın projelerinde kullanmayı zorlaştırıyordu
LibreOffice düzeltmesi ve gerçek performans değişimi
- LibreOffice, MS Word’den esinlenen olgun ve kararlı açık kaynak kelime işlemcilerden biridir ve Linux dahil çeşitli platformlarda ücretsiz kullanılabilir
- Word veya InDesign gibi ticari yazılımlar uzun Tibetçe metinleri işleyebilir, ancak maliyetleri yüksektir ve Asya’nın çeşitli bölgelerinde çoğu zaman korsan sürümlerle kullanılır
- LibreOffice uzun paragrafları işleyemediği sürece Tibetçe yayıncılık için fiilen ücretsiz bir araç yoktu
- BDRC CTO’su Elie Roux, bu sorunu 2015’te LibreOffice’e bildirdi
- LibreOffice koduna müdahale etmek haftalarca Ar-Ge gerektiren büyük bir projeydi ve bir süre ilerleme sağlanamadı
- Birkaç hafta önce Jonathan Clark bu sorunu üstlenip düzeltti
- Longchenpa’nın Yishindzö’sü, 153 sayfalık tek bir “paragraftan” oluşan uzun bir metindir
- Artık LibreOffice’te hızlıca açılıp düzenlenebiliyor
- İlgili metin, BDRC arşivindeki yid bzhin mdzod kaydında görülebilir
- Bu belirli metnin RDF dosyasını PDF’ye dönüştürme işlemi daha önce 45 dakika sonra bile takılı kalırken, artık 13 saniyede tamamlanıyor
- Çok uzun paragraf desteği, 27 Eylül 2024’te yayımlanan LibreOffice 24.8.2 sürümüne entegre edildi
- BDRC, Tibetçe düzenleme yazılımlarında yaşanan eksikler ve kullanıcı deneyimi hakkında geri bildirim istiyor; topluluk iş birliğiyle Tibetçe dijital araçları geliştirmeyi sürdürmeyi amaçlıyor
2 yorum
Hacker News yorumları
Pennsylvania, New Hope'tan bir hippi ve erken dönem bilgisayar hacker'ı olan Jim Woolsey, Tibetçenin dijitalleştirilmesinde önemli erken figürlerden biriydi.
1993 tarihli röportaj https://www.mcall.com/1993/10/08/new-hope-man-computer-guru-... ilginç bir zaman kapsülü ve başlı başına okunmaya değer.
Aileden tanıdığımız biriydi; bu önemli ama yeterince takdir edilmeyen işe benzersiz adanmışlığına her zaman hayranlık duydum.
“Belgelerde makul derecede kısa paragraflar bulunur” ifadesi de programcıların metin hakkında inandığı yanlış varsayımlar listesine eklenmeli gibi.
OpenOffice'te paragraf başına 65534 karakterlik katı bir sınır vardı ve LibreOffice'in bunu kaldırması epey çalışma gerektirdi: https://bugs.documentfoundation.org/show_bug.cgi?id=30668
Metin yönü, aksan işaretleri, noktalama elbette akla geliyordu ama parçalara ayırmanın evrensel olduğunu sanıyordum.
Meğer değilmiş: “Avrupa dillerindeki paragraf tipografisi kavramı Tibetçe metinlerde gerçekte aynı şekilde mevcut değildir. Bunun sonucunda Tibetçe metinlerin çoğu zaman zorunlu satır sonu olmadan kesintisiz uzun bir metin akışı olarak işlenmesi gerekir; bu bazen yüzlerce ya da binlerce sayfayı bulur.”
'\n'karakterini ararken Tibetçeye yenilmiş olmalı.Saygıyla söylemek gerekirse, Tibetlilerin yenilikçiliği The Nine Billion Names of God eserinde de teslim ediliyor: https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God
Ayrıca onların yenilikçiliği bu kitaptan, en azından Wikipedia'daki olay örgüsü özetinden çok daha geniştir.
“Nispeten kısa paragraflar, belki birkaç sayfaya kadar” gibi bir ifade, dünyaya ne kadar belirli bir açıdan baktığımı gösterdiği için hoşuma gitti.
Sanırım tek sayfalık bir paragraf bile hiç yazmadım.
Adını unuttum ama bir yazarın birkaç sayfalık bilinç akışı metnini paragraf ve noktalama olmadan yazması, aklıma gelen en yakın örnek.
Örneğin James Joyce ve David Foster Wallace var.
Bu çalışma oldukça uzun zamandır sürüyor.
Tibetçe telaffuz öğretmek için eski bir HyperCard stack bile var; içinde 16-bit ses de bulunuyor: https://hcsimulator.com/Learn-Tibetan
Çeşitli bilinç akışı tarzı yazılar ve ilgili üsluplar da paragraflardan, bazen başka geleneksel yapılardan bile kaçınıyor; bu yüzden kelime işlemcilerin uzun paragraflarda zorlanması biraz şaşırtıcı.
Çok yaygın olmasa da hiç olmayan bir şey değil; yazarların ve yayınevlerinin bir şekilde bunun üstesinden geldiğini sanıyordum.
Yakın tarihli rastgele bir örnek: https://en.wikipedia.org/wiki/Ducks,_Newburyport
Aşırı uzun paragraf desteğinin, ya da bunun yokluğunun, nasıl çözüldüğünün ayrıntılarını merak ediyorum.
Bilen var mı?
Önbellekle O(n^2) etkisini azaltan oldukça kısa bir değişiklik.
Bu değişiklik, aşırı büyük paragraflar içeren belgeler için ölçeklenebilirlik iyileştirmesi içeriyor.
LF kontrol karakterlerini dikkate alacak şekilde yerleşim bağlamı boyutunu küçültüyor ve paragraf yerleşimi sırasındaki tipik erişim desenleri nedeniyle VCL'nin
vcl::ScriptRun::next()fonksiyonunu O(n^2) çağırmasını, mevcut global LRU cache'i kullanacak biçimde değiştirerek ciddi bir ek yükten kaçınıyor.Bengali ve Assamese'in Tibet alfabesini kullandığını biliyorum; bunun Tibetlilerin kendi dilleri için kullandığı yazıyla ne kadar benzer olduğunu bilen var mı?
Bengali ve Assamese Hint-Aryan kolundandır; Tibetçe ise tamamen farklı bir dil ailesi olan Çin-Tibet ailesindendir.
Bir Bengali konuşuru olarak, Tibetçeyle %50 karşılıklı anlaşılabilir olduğu söylenen bir dilin konuşulduğu Bhutan'a gittiğimde hiçbir şey anlamadım.
Epey Budist alıntı kelime olacağını sanıyordum ama dharma, karma gibi kelimelerin bile Tibetçede tamamen farklı duyulmasına şaşırdım.
https://en.wikipedia.org/wiki/Tibetan_script
Dil gerçekten ilginç bir varlık.
Öğrenmesi kolay olup geniş bir bölgede iletişime aracılık da edebiliyor; öğrenmesi zor olsa da çok karmaşık yapılar ve düşünceler kurmayı mümkün kılıp bunları konuşurlar arasında aktarabiliyor.
Tibetçe bu yelpazenin neresinde yer alıyor acaba?
Son derece teknik konuların, son derece teknik uzmanlık terimleri olur.
Ancak bir dilin sahip olduğu ince nüans miktarının, o dille ifade edilebilecek düşüncelerin karmaşıklığıyla ilişkili olduğundan emin değilim.
Ben LibreOffice projesinde gönüllü olan Eyal’im; sağdan sola yazılan yazı sistemleri ve karmaşık metin yerleşimi betikleriyle ilgili kalite güvencesi üzerine çok çalışıyorum.
Bu yazının bağlantısını paylaşan thunderbong3’e teşekkür ederim; ayrıca Tibetçe performans iyileştirmesini hayata geçiren The Document Foundation’ın yeni RTL-CTL-CJK sorumlu geliştiricisi Jonathan Clark’a içtenlikle teşekkürler.
LibreOffice’te karşılaşıp bildirdiğim hataların çoğu, belirli bir yazı sistemine özgü olmayan genel sorunlar.
Örneğin içeriğin sağdan sola olabileceğini unutan kodun bu durumda hatalı çalışması gibi.
Yazı sistemine özgü hataların önemli bir kısmı en yaygın kullanılan Arabic yazısıyla ilgili; bu yazı Farsça, Urduca, Cava dili gibi dillerde de kullanılıyor.
Yine de Tibetan veya Mongolian gibi daha az yaygın yazı sistemleriyle ilgili sorunlar da var: https://bugs.documentfoundation.org/show_bug.cgi?id=115607
Bu meta hata; Mongolian, Tibetan, Uyghur, Zhuang, Kazak, Xibo, Dai, Yi, Miao, Jingpo, Lisu, Lahu, Wa gibi dillerin sorunlarını izliyor.
Bu dillere özgü sorunların gerçekten az mı olduğu, yoksa kullanımın az olup kullanıcıların hata bildirmek için yeterli motivasyona sahip olmamasından mı kaynaklandığı bilinmiyor.
Yine de Jonathan’ın son düzeltmesinin gösterdiği gibi, geliştirici zamanı ayrılabildiğinde bunları çözmeye yönelik ilgi kesinlikle var.
Bu yazı sistemleri ve ülkeler/kültürler arasında belge düzenlemede adalet konusuyla ilgilenenler, LibreOffice’i bildikleri bir dilde deneyip hata bulurlarsa BugZilla’ya bildirse iyi olur: https://bugs.documentfoundation.org/
LibreOffice projesini yöneten The Document Foundation’ı finansal olarak desteklemeyi de düşünün: https://www.libreoffice.org/donate/
Dünyadaki büyük özgür açık kaynak projelerinden biriyiz; düzenli kullanıcı sayımız on milyonlarca, belki de 100 milyonun üzerinde ve yönetim kurulumuzda onlarca ülkeden insanlar var.
Ancak projeye ciddi miktarda para veya zaman yatıran büyük şirketler yok.
Collabora ve Allotropia gibi bazı ticari şirketler katkı sağlasa da, birçok temel sorun onların müşteri taleplerine yeterince yakın değil.
Bu yüzden RTL-CTL-CJK desteğini güçlendirmek için Jonathan’ı doğrudan işe almaya karar verdik; bu tür çalışmaları bireysel kullanıcı bağışları mümkün kılıyor.
Korece'de boşluklar olmasaydı zorlanırdık.