Dalam edisi pos mingguan yang ini, saya ingin mendiskusikan berbagai tempat di mana kita akan menggunakan teks tidak terstruktur dalam objek-objek wiki fungsi.
Yang berikut ini merupakan sebuah rencana dan permintaan komentar. Selain label, belum ada yang diimplementasikan, jadi kami sangat mengharapkan umpan balik kalian.
Label.
Setiap objek di wiki fungsi akan ditandai dengan sebuah Z-ID, mirip dengan Q-ID yang menadai butir-butir di Wikidata. Tetapi seperti Q-ID, kami tidak memperkirakan Z-ID akan sering dibaca dan digunakan. Jadi, setiap objek akan memiliki label, satu label per bahasa.
Tetapi tidak seperti butir Wikidata, setiap objek akan merupakan sebuah contoh dari suatu tipe tertentu. Contohnya, mungkin akan ada suatu objek yang merupakan contoh dari penambahan dari dua bilangan bulat. Jadi label bahasa Inggris untuk objek ini misalnya adalah "add". Label bagus lainnya untuk objek ini misalnya adalah “addition”, “sum”, atau “plus”. Nama yang tidak cocok untuk fungsi misalnya adalah “multiplication”, karena itu akan sangat membingungkan.
Keunikan.
Mungkin akan ada objek lain yang merepresentasikan fungsi yang melakukan penjumlahan, contohnya penjumlahan dua bilangan floating point, atau dua bilangan kompleks, atau dua matriks.
Dalam wiki fungsi label tidak harus unik pada umumnya - tetapi harus unik untuk setiap tipe. Jadi hanya boleh ada satu fungsi dengan label "add" yang mengambil masukan dua integer dan mengembalikan hasil satu integer. Atau hanya satu tipe dengan label "integer". Per tipenya, setiap label haruslah unik.
Jadi apakah setiap objek memerlukan label? Tidak. Akan ada banyak objek yang tidak harus punya label.
Tidak setiap uji coba suatu fungsi memerlukan label, dan tidak setiap implementasi fungsi memerlukannya. Mereka boleh punya label, tetapi tidak harus - ini adalah perbedaan lainnya dari Wikidata, di mana butir tanpa label hampir selalu menimbulkan masalah.
Satu catatan lagi pada label – label tidak harus berupa terjemahan langsung ke seluruh bahasa.
Jadi dalam satu bahasa, dua fungsi bisa punya label yang sama apabila mereka tipenya berbeda, tetapi dalam bahasa lain kedua fungsi tersebut bisa punya label yang berbeda juga.
Contohnya, dalam bahasa Inggris “length” bisa menjadi label yang cocok untuk sebuah fungsi yang menghasilkan banyak elemen dalam sebuah daftar, serta untuk fungsi yang menghasilkan panjang suatu sungai, atau fungsi yang menghasilkan durasi suatu film.
Sedangkan dalam bahasa Kroasia, ketiga fungsi tersebut bisa memiliki nama yang berbeda-beda (“broj elemenata”, “duljina”, “trajanje”).
Setiap bahasa bisa menentukan pola apa yang paling cocok untuk mereka. Apakah yang paling cocok adalah kata kerja imperatif (“add”) atau deskripsi hasil (“sum”) atau nama operasi (“addition”) bisa ditentukan oleh masing-masing bahasa, dan pedoman gaya masing-masing bahasa boleh berkembang.
Alias.
Selain label, setiap objek bisa punya alias tambahan per bahasa. Alias berguna ketika mencari suatu objek.
Fungsi di atas, diberi label '“add” dalam bahasa Inggris, bisa punya semua nama alternatif lainnya yang disebutkan di atas – “sum”, “plus”, “addition” – sebagai alias, jadi ketika seseorang mencari suatu fungsi dengan nama yang berbeda mereka masih menemukan hasil yang benar.
Dokumentasi.
Setiap objek juga bisa punya dokumentasi dalam setiap bahasa. Dokumentasi adalah teks wiki yang menjelaskan objek tertentu. Kebanyakan objek tidak akan punya dokumentasi sama sekali, tetapi banyak juga yang punya dokumentasi.
Jika Anda dapat kesempatan untuk membaca The Art of Computer Programming, Anda akan tahu sering kali ada banyak yang harus dibicarakan tentang suatu fungsi!
Tetapi selain cerita latar belakang seperti ini, kita juga bisa punya dokumentasi yang menjelaskan implementasi tertentu, atau penjelasan kenapa suatu uji coba berguna.
Dokumentasi juga bisa menautkan ke suatu pekerjaan Phabricator yang menjelaskan galat yang dulunya ada di sana dan uji coba ini memeriksanya agar menemukan galatnya sebelum galatnya muncul, atau tautan ke sumber daya lain seperti buku teks mengenai algoritma.
Kunci dan argumen.
Paling tidak tipe dan fungsi juga akan punya label untuk setiap kunci tipe dan untuk setiap argumen fungsi. Ini akan digunakan dalam membentuk antarmuka pengguna untuk menampilkan dan menyunting nilai dan panggilan fungsi.
Deskripsi singkat.
Satu pertanyaan spesifik yang kami miliki adalah – haruskah kami memiliki deskripsi singkat opsional untuk setiap objek?
Dalam banyak IDE, dan terkadang secara langsung dalam bahasa pemrograman (misalnya docstrings di Python) terdapat dukungan untuk satu baris singkat yang memberikan sedikit informasi mengenai suatu fungsi, di luar nama fungsi, argumen dan tipenya.
Kami akan memiliki sistem tipe yang kuat, dan kami akan punya banyak ruang untuk dokumentasi.
Jadi apakah kami benar-benar juga perlu deskripsi singkat? Apa contoh kasus penggunaan mereka? Bagaimana mereka akan digunakan di UX?
Di situs web, sesuatu yang mirip dengan pratayang pop-up di Wikipedia kelihatannya lebih berguna daripada satu baris, memberikan pratayang dari seluruh dokumentasi.
Awalnya saya berasumsi bahwa secara baku kita akan punya deskripsi singkat, mengingat pentingnya dan bergunanya mereka di Wikidata, dan mereka juga ditampilkan di prototipe AbstractText. Namun mereka tidak pernah berguna di sana.
Juga, tipe mengambil alih peran penjelas diambiguasi, seperti yang dijelaskan di atas, jadi tidak ada kebutuhan teknis untuk deskripsi singkat.
Saya untuk saat ini lebih memilih tidak memiliki mereka, tetapi saya ingin mendengar lebih banyak masukan.
Untungnya tidak ada keputusan yang selamanya mutlak. Model data wiki fungsi akan lebih fleksibel daripada model data Wikidata, dan apabila kita menyadari bahwa kita rupanya memerlukan deskripsi singkat, kita tetap bisa memperkenalkannya nanti.
Namun akan lebih sulit untuk menghapus sesuatu, karena hampir semua hal yang ada pasti digunakan, jadi saya lebih hati-hati dalam memperkenalkan fitur tanpa alasan yang bagus.
Penggunaan sendiri.
Ada pertanyaan yang mudah dilihat: hey, kita mengembangkan arsitektur ini untuk membuat konten multibahasa, mengapa kita punya semua dokumentasi dan label ini dan semua itu dalam bahasa sungguhan, mengapa kita tidak menggunakan fungsi kita sendiri untuk membangun ini semua?
Dan ya, kami setuju, itu memang pilihan yang terbaik. Hanya saja, kita belum sampai ke sana, dan sampai saat itu, kami masih akan membutuhkan label dan dokumentasi dan alias.
Jadi nanti saya akan sangat menantikan penggunaan konten abstrak untuk menjelaskan objek wiki fungsi itu sendiri.
Juga akan menarik apabila kita bisa membalikkan beberapa konten lokal, dan seberapa terbuka kita dalam melakukannya – karena ini akan memberikan kita banyak pandangan menarik tentang cara mencapai tujuan yang serupa dalam proyek Wikimedia lainnya, mulai dari deskripsi (dan bahkan mungkin label? atau daftar arti?) hingga artikel Wikipedia yang baru dirintis.
Akan ada banyak potensi untuk membuat konten kami di berbagai proyek lebih mudah dipelihara dan untuk menyediakan cakupan dasar yang lebih seragam dalam berbagai bahasa.
Putaran kedua pemungutan suara untuk nama wiki fungsi baru awalnya direncanakan untuk minggu depan pada tanggal 27 Oktober.
Proposal saat ini sedang diperiksa oleh tim hukum, dan kita harus tahu nama mana yang akan segera masuk babak final.
Karena peninjauan lebih lanjut dari kandidat terpilih diperlukan, serta beberapa tes teknis tambahan untuk menggunakan gadget pemungutan suara interaktif baru, pemungutan suara akhirnya akan dibuka pada Selasa 2 November selama dua minggu.
Pembaruan Wikipedia abstrak 
