upviki.pl ne fidinde funkcias kaj multobligas kelkajn kap-linojn (ekz. viv/, vespert/)

Pli bone reverki ĝin:

• apartigu en propran skriptoj la parton kiu elŝutas kaj legas la informojn de Vikipedio; kaj la parton kiu aldonas ligilojn al artikoloj
• uzu libxml2 por eviti problemojn kun sintakso/regex - (kp. voko-grundo/perl/merge_trd_xml.pl)
• eble helpu la enmetadon per nemiskomprenebla markado de la loko en la artikoloj, kie eniru la Viki-ligoj
• eble apliku nur al redaktitaj artikoloj (?)
• eble estonte jam aldonu la referencojn en voko-formiko per XSL (?)

Permesu helan kaj malhelan kolorskemon. Tion oni atingas difinante du diversajn kolorarojn den CSS :root elemento unu kiel @media (prefers-color-scheme: dark) Vd. jamajn provojn en n1 / n1a.

• permesu per duobla musklako ekserĉi vorton el la artikolo, eble foriginte la finaĵon (kiel ĉe tuŝekrano?)
• dum redaktado: permesu enmeti trovvorton kiel referenco en la XML - eble kun interpaŝo plenigante mrk+vrt en la redakto-formularon, elekti la tipon kaj tiam enmeti
• dum redaktado: permesu serĉi citaĵojn kaj rigardi/enmeti ilin en la XML

Rearanĝu la retformularan redaktilon iom:

• servu la enhavon per Ajax/XML, tiel la paĝo mem estas pli facile rearanĝebla
• ordigu la aranĝon de la butonoj
• navigado drv-drv... estu flanke de textarea
• uzu ekranklavaron laŭ revaj.steloj.de

Permesu alnoti artikolojn - ekz-e markante ilin por posta redaktado. Ni povus utiligi tiucele tabelon: redaktanto-id, marko, noto. La notojn ni povus listigi apud "viaj submetoj".

Kiam oni redaktis la koncernan artikolon, ĝin ni marko per progres-vinjeto kaj semajnon post la lasta tuŝo ni povus forigi ĝin, lrom se ĝi estos denove alnotita intertempe. (do du statoj: tuŝenda, tuŝata (kaj for))

Ni esploru eblecojn subteni la tradukadon per uzo de vortaroj. Pluraj estas konektitaj al kono.be/ViVo kiun Bart rekonstruas tiel, ke estonte ni povos pridemandi ĝin per JSON.

Aliaj vortaroj en la reto ebligas aŭtomatan pridemandadon, ekz-e vortret-bazitaj: https://chinese.english-dictionary.help/english-to-chinese-meaning-time (do uzante anglan vorton kiel sufikso)

kaj por Vikipedio (per "en")
https://commons.wikimedia.org/w/api.php?action=query&&titles=Category:London&prop=langlinks&lllimit=500&format=xml&rawcontinue
resp. per "eo":
https://eo.wikipedia.org/w/api.php?action=query&&titles=Londono&prop=langlinks&lllimit=500&format=json&rawcontinue

UWN:

• https://www.mpi-inf.mpg.de/de/departments/databases-and-information-systems/research/yago-naga/uwn
• http://wordnets.org/
• http://lexvo.org/ (vd. petinterfacon http://www.lexvo.org/uwn/ kaj "Wordnet URIs" en http://lexvo.org/linkeddata/details.html)

En la nova fasono estas problemo kun la traŝovado de la paĝo en iOS Webkit (ekz-e iPad). Post kiam oni elektis iom longan artikolon ofte la malsupra parto de indekso kaj artikoloj ne plu estas atingeblaj. Oni povas tiri la paĝon, ĝis vidi ekz. la piedlinion - sed ĝi resaltetas poste kaj oni ne povas tuŝi do la ligilojn en la piedlinio. Same la navig-trabo kun la serĉilo supre malaperas super la supro de la videbla paĝo kaj nur per trifingra malgrandigo kaj iom da provado reaperas.

Mi ĝis nun ne komprenas, kial Webkit faras tion - eble por pli bone montri la centran parton de la paĝo (<article>)...?

Kelkajn similajn problemojn traktas la sekvaj paĝoj, eble ili povus helpi:

• https://nicolas-hoizey.com/articles/2015/02/18/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers/
• https://stackoverflow.com/questions/59143939/how-to-make-a-div-exactly-fill-the-browser-window-including-mobile-safari-as?noredirect=1&lq=1
• https://www.smashingmagazine.com/2018/08/scroll-bouncing-websites/

En la redaktilo la x^-butono foje aperas premita, sed estas malŝaltita, t.e. ne funkcias cx->ĉ

Retaplikaĵetoj (PWA) permesas uzo-sperton de retpaĝoj similantan tiun de apoj. Vd. ekz. (iom malnovan) enkondukon.
Aŭ tie ĉi pli nova enkonduko.
Ankaŭ tiu klarigo de bazaj konceptoj estas interesa.

Antaŭkondiĉoj:

• la fasono de Revo-retpaĝoj jam estas adaptitaj por bone funkcii sur malgrandaj ekranoj de poŝtelefonoj ks
• la servilo uzas HTTPS

Bazaj funkcioj instalendaj:

• retaplikaĵa manifesto (difinante eblecon de aldono de vinjeto al telefona hejmekrano, lanĉbildon ks)
• servo-laborilo (ServiceWorker) ebliganta preni novajn paĝojn fone kaj konservi ilin loke (vd ankaŭ kaŝmemoraj manifestoj)

==> Mi ne tute certas, kiel la serĉilo devus integriĝi en la tuton

Paŝo-post-paŝo-klrigo, vd jen:

• https://blog.heroku.com/how-to-make-progressive-web-app
• https://web.dev/learn/pwa/

Kontrolo de referencoj plendas pri ja kezistanta subart-mrk, ekz. "for.0.prefikso".

checkversioj.pl en sia nuna formo ne plu utilas, ĉar ĝi komparas la ekziston kaj versiojn de XML- kaj HTML-dosieroj al la CVS-dosieroj, sed la aktualaj fontoj nun estas en git (revo-fontoj) - ne plu en CVS.

Ĉar la git-fontoj mem ne estas en la TTT-servilo, ni devos elpensi alian manieron. Plu ni povus

• kompari dosierojn en hst, art kaj xml, ĉu iliaj versioj koheras
• krome utilus kontroli en la datumbazo, ĉu tie artikoloj mankas aŭ troas
• por kompari fontojn kun la TTT-servilo ni povus iom post iom kontroli por ĉiuj fonto-dosieroj, ĉu troviĝas la korespondaj dosieroj en la TTT-servilo, ekz. per curl -m HEAD aŭ simile...

Kelkaj eraroj ŝajne okazas nur en iOS Webkit kaj tiel ne estas troveblaj per tetado en FF, Chrome kaj Epiphany. Por trovi tiujn sen havi kompletan instalaĵon de macOS+XCode+Safari estus bone montri la enhavon de la ret-konzolo ie en la retpaĝo.

Kelkaj tiucele anstataŭigas la console.log-funkcion ktp. per iu, kiuj sendas la tekston al DOM-objekto/iFrame: https://stackoverflow.com/questions/6508313/javascript-console-log-in-an-ios-uiwebview

(Tio eble tamen ne inkluzivas esceptojn? - necesas elprovi)

Estas kelkaj ideoj por modernigo de la vortaro:

• 1. Interfaco: ne plu uzu kadrojn, anst. uzu centran serĉpaĝon kaj ŝargu ĉiujn enhavojn fone per Ajax

• 2. Simpligu la datumbazon: ĝi estiĝis iam kun la ideo dinamike krei la paĝojn, sed tio neniam realiĝis tiel. Pli bone havi nur tre platan strukturon de unu aŭ du tabeloj kun la kampoj "serĉvorto", "indekso", "referenco", "simpligo"

• 3. Anstataŭ la tradiciaj kvar indekspaĝoj Esperanto|Lingvoj|Fakoj|ktp. uzu aldonajn cirklajn butonojn ie kadre kun la literoj REVO, ekz.

  • (R)eferencoj (t.e. tezaŭro)
  • (E)sperantaj indeksoj (t.e. e-a, inversa, vortlistoj klasaj, fakindeksoj
  • (V)ortlistoj alilingvaj
  • (O)kazaj paĝoj

La frazo „Nenio trovita“ restas, se la retkonekto/CGI che sercho lamas, shajnigante ke vorto ne ekzistas. Ni malplenigu la rezultopaghon au montru „serchante…“ dum ni serchas. Tiel pli klarus, ke sercho dauras au havas problemon.

(Simile dum Submeto montru ion dum atendo de rezulto)

FF ne kopias al "clipboard" en la refeerenco-funkcio. Sciante tion, eble oni ne montru la kopio-butonon aŭ iel avertu.

Iu(j) robotoj ne respektas la regulojn en robots.txt kaj aliras skriptojn en cgi-bin/

• historio.pl - ne plu ekzistas, en kiu malnova dosiero la roboto ĝin trovis?
• mx_trd.pl - tre postulema pri DB, tion ni nepre devos protekti
• aliajn?

Por protekti eble ni apliku ion kiel: https://haacked.com/archive/2007/09/11/honeypot-captcha.aspx/

Daŭre robotoj legas en Revo, kio estas akceptebla por serĉmaŝinoj rilate la dosierujojn art/, /inx. Sed ne necesas ke ili legu tez/, hst/ kaj per CGI-skriptoj. Provu per rbots.txt kaj eble aliaj rimedoj pli reguligi tion.

La renovigita redaktilo ŝajne ne bonorde sendas novajn artikolojn, la unua linio ne estas

aldono: <dosiernomo>

<?xml...?>

sed iel tiel:

redakto: kreo

<?xml...?>

Mi trovis la jenajn, kiuj ne aldoniĝis:

• sejm - /home/revo/revolog/oldmail/20210127_091106
• Tver - /home/revo/revolog/oldmail/20210107_071105
• saben (aldonita) /home/revo/revolog/oldmail/20201227_111034

Se oni navigas en la retaplikaĵo (PWA) al shanghitaj artikoloj poste rulas sufiche malsupren kaj renavigas al la chefindekso tiu aperas malplena.

(chu eble tio povas esti problemo de y-pozicio?)

Ĵeromo rekomendas rigardi... du ekzemplojn de vortaroj en intereto, kiuj prezentas interesan fasadon:

la unua havas sub la serĉilo rubrikojn "uzoj" "temoj" kun indikitaj vortnombroj:
[fr] https://www.linternaute.fr/dictionnaire/fr/

la dua havas langetojn "specialaj temoj" "mallongigoj" kaj ceteraj super la serĉilo:
[de] https://dict.tu-chemnitz.de/

eble tio helpos al la pripensado.

En la tezaŭro ni ne montras listerojn el kategoriaj listoj (ekz. urboj ĉe la vorto urbo), sed tie referencas la kategorian indekson. Tamen ni multloke ni ankaŭ referencas ekz. al fizikisto (Avogadro k.a.) sed listigas sub "historiaj_personoj". Do ĉe la vorto fizikisto aperas nek listoreferenco "historiaj personoj" nek Avogadro. Verŝajne ni montru unu aŭ la alian.

parseart2 plenigas la tabelojn r2_*, i.a. de la tezaŭro. Ĝi ankoraŭ baziĝas inx_eltiro, inx_kategorioj, tez_retigo kaj poste uzas regulesprimojn por ekstrakti valorojn por la datumbazo. Sur la servilo ni ne havas XML::LibXML por pura ekstraktado, sed ni povus uzi JSON simile al vikiref, por pli fidinda programado.

• prepari XSL-dosierojn por ekstrakti la informojn el artikolo en formo de JSON
• reverki parseart2.pm por uzi JSON anstataŭ regulesprimojn kun XML
• solvu problemojn kun celref al artikoloj anst. drv, snc (kapvorto estas momente ???), eble ellasu ilin?
• solvu problemojn kun referencoj sen celo (fako?), ĉiuj tri celkampoj estas NULL
• solvu duolbajn elreferencojn drv/snc - kie ni bezonas ambaŭ ĉu por kontroli referencojn en readktilo...?
• renomu 'sup' al 'super'
• kial mankas 'prt' kaj 'malprt', ĉu ili tradukiĝas al sub/sup?
• 'lst' estas trivalora, mankas kolumno por la listo mem, se ni volas iri tien el la tezaŭro
• referenco 'lst' ekz-e mankas por homaranismo -> religioj
• la unua kolumno havas la fontan artikolon, ĉu ni bezonas ankaŭ celan, aŭ ĉu serĉo per LIKE estas sufiĉa
• ĉu ni kreu rigardon (VIEW) por la ofta ambaŭdirekta pridemando? verŝajne pro antaŭkompiliĝo ĝi estus pli rapida
• kontrolu indeksojn
• mankas ref-oj de subsnc (?)
• marksismo referencas al socialismo kaj tri aliaj, kiuj en la tabelo r2_tezauro aperas kun tez_cel* = NULL
• Groningo: duobla Viki-ligo; mankas ref. urbo/provinco (lst-ref)
• kazo -> deklinacio
• korvo -> korvedoj

Ni havas XML-dosierojn laŭ XML-normo OpenSearchDescritpion, kaj deklaron kiel meta type="search". Sed estas ne plu klare, kiel aldoni ilin en la diversaj retumiloj. Nur ĉe Fajrovulpo tio funkcias senprobleme en la URL-trabo per "..." -> "Aldonu Sercilon".

Iam oni povis ankaŭ aldoni per JS-funkcio, sed ne plu. Vd.:
https://www.fxsitecompat.dev/en-CA/docs/2020/window-external-addsearchprovider-is-now-a-dummy-function/

Estus bone sistematikigi stildifinojn (CSS), tiel ke oni povas kombini stilojn per klasoj kaj uzi samajn tra la tuta aplikaĵo (artikoloj, indeksoj, redaktilo). Estus ankaŭ preparlaboro, por uzi kolorojn laŭ variabloj, adapti la tekstaranĝon pli bone al diversgrandaj ekranoj...

Ekideoj:

• videbleco: v_for (nevidebla) | v_sur (areo ŝvebanta super la paĝo - por dialogoj) | ...
• aktiveco: a_tuŝ (tuŝebla areo) | a_btn (butono, ekz. kiel parto de formularo) | a_pkt (piktograma butono) | ...
• diversspecaj areoj por difini la kolorojn kaj tiparon semantike (navigado, titolo, tradukoj, ekzemploj, fontoj...) - eble se la HTML jam estas sufiĉe semantika oni ne bezonas apartajn klasojn.

Aldonante tradukojn el serĉo en universala vortreto ne plu montriĝas hoketo ĉe la lingvoj, kiuj jam havas tradukon ( en la naviga kadro ĉe la trovlisto )

La redaktobutonoj estas nek kompletaj nek la aranĝo ĉiam aperas optimala - depende de ekrangrandeco.
Ni trovu eblecon kompletigi ilin sed samtempe kaŝi malpli gravajn depende de la disponebla spaco. Krome kelkaj (citiloj, klarigoj) estus utilaj plurkuntekste (dif, ekz...):

Ideoj:

• etikedu butonojn per klasoj tiel, ke ili povu aperi en pluraj kuntekstoj: klasoj povus esti r:ekz, r:dif, r:30, r:50 aŭ simile, libere kombineblaj
• oni povus eble eluzi details, summary por hierarkia aranĝo... - sed tio ne kunludus kun la klaso-solvo, ĉu?
• se spaco sufiĉas ni povus oferti ekran-klavaron kiel en la redaktilo ĉe revaj.steloj.de
• aliaj ideoj?

Ni devas flegi la retumilon historion mem, uzante Ajax. Jen unu biblioteko, kiu povus helpi:
https://github.com/browserstate/history.js

Jen informoj pri JS-Api:

• https://css-tricks.com/using-the-html5-history-api/
• https://wiki.selfhtml.org/wiki/JavaScript/History
• https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event

Se ni havus aldone al simpla serĉo tabelecan filtreblan trovtabelon, ni povus uzi tion kiel flekseblan indekson kaj eble povus rezigni pri (kelkaj) statikaj indeksoj. Ĉu la fakindeksoj estas multe uzataj? -- ni povus realigi ilin per tia tabelo, same oni povus oferti filtradon je oficialeco, vortspeco ktp. tiel havante pli flekseblan eblecon por listigi serĉrezultojn. Krome oni povus oferti eksportadon de la specifaj rezultoj al CVS aŭ JSON...

Ĝis nun la referencoj de la kapvortoj al Vikipedio estas kreataj per skripto upviki.pl kiu devas ĉiutage vokiĝi kaj manipulas la HTML de la artikolo.

Tio havas iomajn malavantaĝojn:

• tuj post la aktualigo artikolo ne havas ilin
• oni ne povas simple sinkronigi transformitajn artikolojn kun la celo ekz-e per rsync
• ŝanĝo en la HTML-strukturo povas kaŭzi nerimarkitajn fuŝojn

Pli pura solvo estus unu el la sekvaj:

• Viki-referencoj jam estas enŝovataj en la kadro de la transformprocedo
• ili estas aldonataj al la artikolo dinamike je la tempo de montrado

La dua ebleco estas pli simpla ĉar momente ni havas la Viki-informojn en la datumbazo. Kiam ne rearanĝas la tezaŭron por krei la referencojn dinamike ni povus aldoni al tiu renovigita aliro ankaŭ la trakdtadon de Viki-referencoj.

Aktuale ni havas tri paĝojn por la bibliografio pro tri ordigoj (mallongigo, aŭtro, titolo). Pli bone estus provizi ĝin kiel JSON kaj ordigi tion laŭplaĉe - tiel ni povas redukti al unuopa paĝo.
Aŭ ni uzu la XML-formation, kiu jam estas uzata de Cetonio, sed en tiu aŭtoro kaj titolo estas kunfanditaj.

• transformo de bibliogreafio XML->JSON
• lego de JSON kaj prezenti kiel HTML
• reordigeblo (estos en venonta 2j)
• forigi la du aldonajn ligilojn el indekso precipa

Nuna stato:

• La db-strukturo per serĉi estas iom komplika
• La ekstraktado el XML fine estas per regulesprimoj en Perlo, kio ne estas ĉiam fidinda (ekz. ne ekstraktiĝas bone en-ekzemplaj tradukoj, vd. dresi, sendresebla -> unbändig)

Ideo estas reverki la procedon simile / paralele al la tezaŭro: enlistigi ĉiujn tradukojn en JSON-dosierojn, ekstrakti de tie en la servilo kaj ŝovi en tabelon trd, laŭbezone kreante rigardon trd-kap...

Se ni metus komencon de difino en la datumbazon ĝi povus servi kiel antaŭraigardo ekz-e en la tezaŭro, (simile kiel en Vikipedio). Montrante per la muso oni vidas la difinon, sed nur se oni volas vidi la tutan artikolon oni devas musklaki.

Simile tio povus helpi elekti la taŭgan sencon de referencota kapvorto. Tiam oni devus montri tion en la serĉrezultoj ekz-e.

Necesas distingi la difinojn de sencoj, derivaĵoj ktp. - do ni metus en la tabelon r3mrk...

Iru al izolita artikolo, premu redakti post antaŭrigardu - la tradukoj estas forkaŝitaj...

Por tradukado de lingvoj (mx_trd...) ni prezentu la tradukendajn vortojn laŭ konvena prioritato:

• mil unuaj vortoj(?)
• oficialaj vortoj
• oftaj vortoj (laŭ kiu mezuro, ekz. laŭ amplekso de la artikolo, alilingvaj tradukoj aŭ simile..., io kio eblas per la datumbazo eltrovi!)

Ni aldone povus uzi oftecoliston kiel tiun: https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists/Esperanto
Alia "facila" vortlisto: https://uea.facila.org/uploads/pages_media/1_vortlisto-de-uea-facila-versio-dupagha.pdf

Donu iom da helpo titolpaĝe(?) kiel serĉi, ekz-e per ĵokersignoj:

• fine: %ringo
• komence+fine: ring%fingro
• rimojn: %un_ aŭ en inversa indekso
• regulesprimoj/krucenigmo k[aoiue]ro...

La serĉskripto respondas per HTTP-200, sed nevalida JSON, kiam la datumbazo ne funkcias. La fiŝeto ne finas turniĝi tiam. Ni certigu validan JSON-respondon, kvankam kun erarmesaĝo kaj montru la erarmesaĝon kiel rezulto.

Ekz-e serĉante "ajar" oni trovas plurajn vortojn, kiu fakte devuse enhavi "ajar", sed la indoneziaj vortoj estas derviĵoj de "ajar". Do pli ĝuste oni devus montri la tutan tradukon kaj ne nur la parton inter <ind>...</ind>.

sw.js:104 Uncaught (in promise) TypeError: Failed to execute 'fetch' on 'WorkerGlobalScope': Cannot construct a Request with a Request object that has already been used.

okazanta en la linio return fetch... (supozeble ligita al tre malrapida respondo aŭ rompo de tempolimo de la peto al servilo)

var addToCache = function(request){
  return caches.open("offline").then(function (cache) {
    return fetch(request).then(function (response) {
      console.log(response.url + " estas konservita");
      return cache.put(request, response);
    });
  });
};

• novaldonitaj @mrk ne estas tuj referenceblaj (ekz-e por artikolinternaj referencoj), prefere nur avertu pri misreferencoj, sed tamen permesu sendi
• vd. ekz-e "aviz" kiu plendas ne trovi konfir.0o.certigi, kiu montras al subsnc kun @ref kaj @mrk. Supozeble la regulesprimo ne estas sufiĉe fleksa...

La serĉo estas limigita momente al la kvin unuaj preferataj lingvoj. Ne sciante tion ĝi povas surprizi. Do eble permesu eĉ 7 lingvoj kaj resendu informojn laŭ kiuj lingvoj okazis la serĉo kaj montru tion kun la rezultoj
(kaj evtl. referencu informojn, kiel eble ŝanĝi tion per preferoj... aŭ permesu serĉi pli da lingvoj kun averto...?)

Ĉar komencantoj redaktantoj ofte estas pli entuziasmaj ol spertaj eble ni bezonos mentoran sistemon. Prepare:

[ ] donu al redaktantoj rolon (sperto: 0=lernanto, 2=mentoro) - ignorenda en la komenco de cgi/redaktantoj.pl
[ ] permesu ricevi la rolon al cetonio- kaj araneo-redaktiloj kaj marku redaktojn de lernantoj
[ ] permesu al afido ricevi la rolon kaj prokrasti redaktojn de lernantoj post sintakskontrolo, donu al lernanto informon pri sintaksa kontrolo kaj evtl-a prokrasto ĝis mentorado
[ ] montru atendantajn redaktojn de lernantoj ĉe mentoroj sub "(viaj) submetoj"
[ ] montru atendantajn redaktojn de lernantoj ankaŭ en Cetonio, renomu la menueron kohere "submetoj" aŭ simile
[ ] permesu al mentoroj akcepti aŭ rifuzi redaktojn de lernantoj
[ ] permesu al mentoroj pluredakti submeton de lernanto kaj submeti sub nomoj de lernanto aŭ ambaŭ depende de la ŝanĝbezono

De tempo al tempo malnovaj submetoj estu forigitaj, ekz-e pli malnovajn ol 6 monatoj en stato 'arkiv'.

submeto.pl jam enhavas eblecon forigi ĉiujn pli malnovajn ol 200 tagoj. Eble iuj kun stato 'erar' aŭ 'trakt' restu pli longe por analizi eblajn misfunkciojn?

Kiu kiam voku la funkcion 'forigo'? Plej bone aldonu en voko-afido/bin/processsubm.pl...

• [pli...] -> [+nn] - montrante kiom da pliaj tradukoj estas
• bildoj ekster snc ne kaŝiĝas kiam oni fermas drv (ekz. "abrikot")
• kontrolu kontraston de koloroj
• kontrolu aliajn ecojn ebligante uzadon de handikapitaj personoj (ekranlegiloj k.s.) - eblas kontroli per FF Ktrl+Maj+I "Accessibility"

Uzante Revon kiel retapo (tra ServiceWorker) vokinta la serĉon mi ricevis netatenditan respondon "undefined":
Fehler beim Laden von 'https://reta-vortaro.de/cgi-bin/sercxu-json-2h.pl'. Ein ServiceWorker hat eine Promise an FetchEvent.respondWith() übergeben, welche den Nicht-Response-Wert 'undefined' zurückgab.

Sed simila rezulto okazis ankaŭ en la redaktilo, kiam serĉo je ekzemploj ne ricevis respondon dum certa tempo kaj mi tiam reŝargis la tutan paĝon. Do verŝajne tiu rezulto okazas ĝuste kiam oni interrompas senrespondan peton.

La tradicia aranĝo de navigpaĝoj: Esperanto | lingvoj | fakoj | ktp. estis adaptita al la porciumado de informoj sur statikaj paĝoj, kaj ne plu estas tute konvena, kiam ni bezonas kunpremi ĉion bezonatan sur malgranda ekrano de poŝtelefono. La dinamikeco de fona ŝargado donas la eblecon pli logike rearanĝi ĉion:

1. esplorado laŭ indeksoj

• alfabeta
• inversa
• kategoria
• mallongiga
• bilda
• fakaj indeksoj
• alilingvaj indeksoj

2. serĉado

• pli detalaj serĉeblecoj ol nur-vorta...
• trovoj

3. informoj

• por uzantoj
• por redaktantoj

4. redaktado

• trd | ref | indikoj | ekz ks

Kiam oni elektis kaj troviĝas ene de unu el la kvar navig-spacoj, eblas montri la kvar aŭ komplete sur granda ekrano aŭ kondensigite en la malgranda navigtrabo kiel vinjetoj:

🔍 | ☰ | ⓘ | ✎

Laŭ iom da ricevitaj reagoj, la nuntempa tezaŭro estas ne tro vaste uzata - eble tro kaŝita, eble pro la dissplitigo en multaj malgrandaj dosieroj estas tro malfacile navigebla. Krome la preparado de la multaj malgrandaj dosieroj estas sufiĉe da ŝargo por la aktualiga procedo komparante kun la marĝena uzado.

Jen kelkaj ideo por rekonceptado:

• ne kreu la tezaŭron en formo de multaj malgrandaj dosieroj, sed uzu la datumbazon por krei ĝin dinamike
• kunigu tezaŭrajn referencojn de ĉiuj sencoj el unu derivaĵo (simile al tradukoj)
• evitu montri tezaŭro-butonon, se mankas enavo por unu drv / eltrovu tion jam per XSL a.s. - por eviti tro da datumbazaj demandoj kaj tro da malplenaj rezultoj
• eble prezentu ĝin pli grafike, t.e kiel reto montranta la interligojn inter la nocioj kaj la hieraĥion. Por tio necesas limigo, ekz. al fako aŭ referenctipo aŭ profundeco de la interrilatoj (montri nur tri ŝtupojn de referencoj aŭ simile kaj permesu plunavigi laŭbezono)
• hieraĥia/grafika prezento ankaŭ povus helpi la redaktantojn ŝtopi la truojn en la reto kaj trovi la radikajn nociojn por marki ilin per <tezrad/>

Grafika prezento bezonus aŭ SVG aŭ JS Canvas. Jen du bibliotekoj, kiuj subtenas tion:

• https://d3js.org/
• https://visjs.org/

Eble ankaŭ konsideru la argumentojn en https://medium.com/@PepsRyuu/why-i-no-longer-use-d3-js-b8288f306c9a

En la artikolo "ĉirkaŭ", la referencoj de III aperas en la tezaŭro sub I. Ili montriĝus fakte sub III, sed tie ne estas derivaĵo. Prefere tute ne montru ilin do en la tezaŭro. Ne necesas!

Estus bone havi ankaŭ en la simpla redaktilo tradukdialogon por vidi kaj redakti ĉiujn tradukojn de unu lingvo en unu superrigardo.

Por pli komforta aldono de tradukoj necesus krei liston de tradukeblaj partoj: drv, snc, subsnc, ekz kune kun resumo, kiu permesas kompreni, kion traduki (frazo de la difino aŭ ekz. ks)

Trairante la liston oni povus aldoni unu aŭ plurajn tradukojn de antaŭelektita lingvo kaj poste aldoni ĉion per helpo de skripto en la XML-tekston.

Parto de tia funkciado estis jam realigita en revaj.steloj.de, sed mankas sen-markaj sencoj kaj ekzemploj. Kaj en la simpla redaktilo ni eble ne volas uzi surmetitajn dialogojn...?

estas certe dezirinde simpligi la abundan paĝaron de revo, interalie rearanĝi la aferojn kiuj restas kaŝitaj en la ne tre alloga "ktp"-ĉapitro.

por la serĉilo mi volis rekomendi ideojn de "simpla vortaro" http://www.simplavortaro.org, sed via propono jam proksimas al ĝi sen la pli analizaj funkcioj. kiel nun la serĉo-kadro inkluzivu la funkcion "iu ajn artikolo". ĉu ĝi ne povus iel inkluzivi ankaŭ la listigon de list- kaj fak-enhavoj, tiel ke apartaj fak-menuoj ne plu estus bezonataj? do kiel vi diras "rezigni pri (parto de) indeksoj kaj anstataŭigi ilin per pli detalaj eblecoj de serĉado". mi pripensos, kiel ĝi povus aspekti. eble simple malplena serĉofako kaj hokado de fak-nomo listigus la enhavon de fako?

lasante flanke la demandon de la redaktilo, kelkaj aliaj sugestoj...

post serĉado en la listoj de respondoj, estus bone indiki la nombrojn de trovoj en ĉiu lingvo.

en la akcepto-paĝo mi volonte trovus jenajn elementojn:

• "statistiko": prefere frazo indikus la tri ĉefajn nombrojn, ekzemple "hodiaŭ revo enhavas xx artikolojn, xx derivaĵojn, xx sencojn, kaj ligilo ebligus malfermon de la plena statistiko-paĝo, kun ankaŭ la ĝisdata listo de redaktoj.

• "ni uzas kelkajn mallongigojn...": miaopinie en tiu loko estu pli ĝenerala frazo kun ligilo al plena helpopaĝo kun la enhavo de nunaj "vortaraj mallongigoj" "bibliografio" kaj aliaj klarigoj pri la strangaj vinjetoj de la vortaro, kaj ankaŭ pri la serĉmetodoj. ankaŭ tie: "kiel uzi en diversaj sistemoj", "elŝuti pakaĵojn", "permeso de uzado".

• "se vi pretas helpi...": ĉi tie estu ligilo al plena paĝo responda al la enhavo de nuna "ktp > por redaktantoj".