Vés al contingut

Tema de Viquiprojecte Discussió:Adaptació de plantilles a Wikidata/multilingüe/migració infotaules a V5/Construcció eines instal·lació

Joutbis (discussiócontribucions)

Si us plau, corregiu-me si m'equivoco:

L'objectiu de l'eina d'instal·lació seria agafar els textos de {{Global Infobox person/Tab param}} i {{Global Infobox person/Tab exception}}, i en base a això modificar {{Global Infobox person}} per generar una infotaula personalitzada a la viquipèdia destí.

La sintaxi actual d'aquestes infotaules està pensada per {{GetTabParam}} i els tractaments en Excel que fa l'Amadalvarez.

Propietats desitjables de l'eina d'instal·lació haurien de ser:

  • comprovació d'errors als fitxers d'entrada: que no hi hagi coses incoherents, que tot estigui complet, ...
  • que la sintaxi dels fitxers d'entrada sigui compacta i llegible, editable per humans.
    • evitar fins on sigui possible repetir informació
    • agrupar tota la descripció d'un camp, que no estigui escampada per diferents punts del fitxer.
  • que la sintaxi sigui extensible per possibles versions posteriors de les plantilles i de l'eina.

Dit això, tinc unes quantes preguntes/crítiques sobre l'exemple actual a {{Global Infobox person/Tab param}}:

  • La majoria de les P's estan al principi, però cap al final, a partir de P642, n'hi ha una altra tongada. L'ordre o la posició són rellevants?
  • L'única diferència entre els paràmetres manuals (Mxxxx) i els altres (Pxxxx) és que, en un cas es prioritza el que hi hagi a Wikidata, i en l'altre el que s'hagi introduït a la plantilla?
  • Hi ha alguna manera d'especificar l'ordre dels blocs? Per exemple, m'he fixat que a les nostres plantilles, primer hi surten les dades sobre naixement i defunció, i més avall comencen càrrecs, oficis i altres; en canvi a l'anglesa va al revés.

D'entrada, processar els fitxers tal com estan ara no té cap dificultat. Però potser m'agradaria més una sintaxi centrada en les propietats, de manera que tot el que estigui relacionat amb una propietat s'especifiqui tot junt. O sigui, el que hi ha ara, més el possible "collapse", les unitats, o si és manual o automàtic. El canvi d'una sintaxi a l'altra el podria fer automàticament el bot, això no seria pas problema.

Quant als diferents blocs, ara mateix només se n'especifica el "header". Podríem pensar en una sintaxi extensible que ens permeti personalitzar-ho més? Una mena de "declaració d'infotaula" que doni l'ordre dels blocs, i permeti afegir-hi colors, icones o coses semblants?

Amadalvarez (discussiócontribucions)

@Joutbis Miro de respondre en el mateix ordre:

L'objectiu de l'eina d'instal·lació seria... No és aquest l'objectiu. Parteixo de la idea que la part comuna (la que sigui) és única per a tothom (si bé en l'arquitectura actual, hauria d'haver una còpia a cada plataforma); la resta d'elements de personalització els administra cadascú i són lliures de posar i treure. Llegint més en detall l'ideari (encara sense elements materials) del projecte de Global templates, apunten fins i tot a tenir només una còpia per a tothom on les millores o bugs que hom detectés s'implantarien amb efecte per a tothom, després d'una validació o treball comunitari per evitar impactes greus.

Dit això, amb la meva solució no es pot solucionar un desig manifestat a l'esmentat projecte que diu que: els noms locals de paràmetres i fins i tot els valors en cas de valors que condicionen funcionament (Y/N, true/false, etc.) ha de ser localitzat. Aquest aspecte, fins ara ho hem solucionat traduint-lo a la Qid. Això m'ha servit en outputs, però "entendre" inputs multilingüe em costa de pair. Per contra, amb la teva solució es tindria un original i una còpia localitzada, ambdues intocables pels editors. Si ho entenc bé, qualsevol alteració de les taules o del codi central, requeriria una re-generació. És això ?

Propietats desitjables: D'acord .

Preguntes/crítiques: L'ordre no és rellevant. El bloc de Ps del final estan allà perquè les vaig crear juntament amb els textos (header), ja que aquestes només es fan servir per generar etiqueta, i no està previst -en aquest cas- que se'ls passi cap valor, és a dir, no es fa servir val_Pnnnn. Però es poden agrupar totes.

Les Pnnnn i les M_xxxxxx haurien d'actuar amb la mateixa prioritat: si estan informades, van per davant de l'accés a WD. La única cosa que et pot haver confós és que les Pnnnn tenen, a més a més, un sinònim amb un text per ajudar la comprensió del codi que queda dins la Infobox, mentre que, a les M_xxxxxx el text é el codi.

Blocs: Sí, està previst però no m'hi he posat per no obrir més fronts. Vaig estar treballant en re-pensar la documentació pel editors i, si la realitat diu que no entren paràmetres manual, sinó WD, el que han de saber és com s'alimenta WD. Mira Viquiprojecte:Documentació estructurada infotaules/persona i fixa't els desplegables que expliquen "que has de fer a WD, i que obtindràs a la Infotaula". Doncs, bé, amb els ajustos que calgui fer, la idea de blocs seria la que es mostra a l'Opció 1 (que està complerta). L'Opció 2 respon al format detallat que podria ser complementari o alternatiu a l'Opció 1. Està obert.

Si el que comentes és sobre com es mostraran, està en la descripció teòrica però parla de futur.

Agrupar tota la informació d'una P. És la intenció. Si et fixes, hi ha una dada que són els qualificadors que gestiona que, pel tema que ens ocupa, no afecta, però que ens permetrà generar la documentació automàticament tirant de la /tab param.

Cert que es podrien afegir altres dades com les unit i els collapse, però no els havia donat importància perquè són molt excepcionals. O sigui que, endavant, anteposant sempre la facilitat d'emplenar per part dels usuaris finals.

headers: El nom és inapropiat. vaig començar amb els headers perquè ni tenien valor ni generaven un label de dades, però en el fons són "paràmetres amb un valor", com les unit o els collapse, però que no tenen paràmetre de contingut a qui associar-los. Els podem vincular als blocs, però segur que, en algun moment, ens caldrà un "text" que no està vinculat a res. Penso, per exemple, en missatges d'error o en categories derivades d'un càlcul, per exemple.

Merci,

Amadalvarez (discussiócontribucions)

@Joutbis Hola. Has vist els meus comentaris ?. Estic pendent per fer els canvis a la taula.

També t'haig de dir que no em sembla que vulguin una taula "easy for editors"; em sembla que els agrada més el format templatedata (awful to me).

Joutbis (discussiócontribucions)

Perdona, aquests dies vaig just de feina, i la setmana que ve tinc un examen.

Sobre els objectius: sí, la meva idea era que el codi central de la plantilla tingués totes les possibilitats, i que amb els Tab param i Tab exception es poguessin fer totes les personalitzacions necessàries. Les noves versions de la plantilla central, per exemple, afegirien paràmetres i informació; un cop publicades, les viquipèdies locals decidirien si val la pena incorporar la nova informació, personalitzant-la, o no incorporant-la. I entremig podrien fer canvis a la personalització, si volguessin; però al final, han de ser plantilles força estables.

No sé, jo veig compatible la meva solució amb els objectius del projecte. La plantilla "mare" no la faria servir ningú directament, i només es modificaria per consens dels líders del projecte; les personalitzacions ja serien pròpies de cada viquipèdia. No es podria editar directament (o sí, però si es fes, la propera generació "matxucaria"), però la capacitat de personalització hauria de ser suficient. I si hi hagués algun problema provocat per la plantilla "mare", l'aniríem resolent. Si no pot anar així, no veig gaire com fer-ho, i ha alguna cosa que se m'escapa.

El lloc on siguin la plantilla origen i la plantilla final, al capdavall, són secundaris i puc desenvolupar sense saber-ho.

Amadalvarez (discussiócontribucions)

No pateixis pel teu examen, que jo aniré incorporant alguns dels teus suggeriments a la taula fins que estiguis lliure. Tinc una mica de pressa en tenir una versió beta per poder compartir amb els possibles implicats, no només els que estem en el tema, sinó a la comunitat catalana que tenia una lògica incertesa sobre una idea que només estava en l'aire i veure-ho materialitzat, permet entendre'l, criticar-lo i millorar-lo. També em servirà per centrar la línia de disseny amb la gent del Global Templates. Per exemple, com ha de ser l'espai o forma on estan les parametritzacions (les taules). Em sembla que pensen en tenir una mena de "gran diccionari" per totes les plantilles i, si no vaig errat, de totes les llengües. El primer punt, em sembla un error perquè no tothom ho voldrà tenir tot, i perquè un mateix nom de paràmetre pot voler dir coses conceptualment diferents segon la plantilla; el segon punt, no crec que els elements de parametrització hagin de ser únics i centralitzats on tothom ha de poder tocar. Crec que és una idea pensada des del Content translator que fa temps que reclama una solució per saber traduir plantilles.

Bé tot aquest rotlle per dir-te que no t'oblidis de mi, però que pots dormir tranquil que no estic aturat.

Sobre la teva proposta: La frase "les viquipèdies locals decidirien si val la pena incorporar la nova informació, personalitzant-la, o no incorporant-la. I entremig podrien fer canvis a la personalització, si volguessin; però al final, han de ser plantilles força estables.", on ho farien?, sobre el codi de la versió local que penses generar ? o sobre els "elements de personalització" ?

Veig que estem apuntant al mateix lloc per camins diferents i només vull entendre-ho bé. Provo d'altra forma:

Disseny inicial:

Plantilla global (única, amb noms de paràmetres internacionals, amb etiquetes per defecte recuperades de WD, modificable centralment)

+ taula de personalització (una per plataforma i plantilla, amb taula equivalències param.intl <--> param.local, amb etiquetes i altres valors alternatius, mantingut en local)

= creació d'una pre-infotaula que crida a la Plantilla global (copia local o com sigui) i li passa tota la informació per funcionar (etiquetes per defecte o locals, nom locals canviats a internacionals, altres paràmetres de comportament, com blacklist de paràmetres, formats de presentació,...). La pre-infotaula es pot crear amb un batch i es pot mantenir manualment o tornar-la a resetejar amb el batch cada cop que es vulgui.

La teva proposta:

Plantilla global (entenc que iguals condicions)

+ taula de personalització (entenc que iguals condicions)

= creació d'una versió local de la plantilla global, personalitzant el codi amb la informació aportada a la taula de personalització.

És això ?

A mi em sembla més neta la teva proposta, però vull assegurar com imagines que faran les personalitzacions els locals.

Una altra pregunta: si no es vol fer cap personalització, cal fer alguna cosa especial, o simplement treballar amb la plantilla global ?.


Ja em diràs, Merci


Amadalvarez (discussiócontribucions)

@Joutbis Seguim després de la nostra videoconferència. Ja he fet els darrers canvis a l'enfocament de la gestió de les taules per donar més homogeneïtat i incorporar algun paràmetre que m'ha sortit.

Tal com vàrem quedar, l'encàrrec seria:

  • Fer un aplicatiu que substitueixi la Plantilla:Create Global pre-Infobox person i desar el resultat com a plantilla a la VP on s'executi.
    • Per a cadascuna de les entrades de la taula /tab param, ha de generar un codi com el que ara resulta quan s'executa la Create Global pre-Infobox person.
    • El codi intern de la Create Global pre-Infobox ja podria ser el codi de la pre-infotaula, però seria perjudicial pel rendiment, ja que hauria de consultar les taules i fer la generació del codi a cada execució. En canvi, agafar el resultat un cop feta l'expansió és més eficient, si bé comporta que s'hagi de repetir aquest procés de creació de la pre-infotaula quan es facin canvis a les taules.
    • L'aplicatiu s'ha de poder executar en la plataforma wikipedia, ja que l'han de poder executar, com s'ha comentat abans, cada cop que s'alteri el contingut de les taules.

Documentació de referència:

Salut !.

Amadalvarez (discussiócontribucions)

@Joutbis Hola ....

M'has abandonat o havies perdut l'adreça d'aquesta pàgina ?

Joutbis (discussiócontribucions)

Abandonat, no. De fet, penso en tu gairebé cada dia. Aquest cap de setmana espero resultats.

Joutbis (discussiócontribucions)

He estat pensant en el que havíem estat parlant, de compatibilitat de plantilles en diferents viquipèdies. Allò que deies que una mateixa plantilla que utilitzem com a base podria tenir resultats diferents en una altra viquipèdia i fer que el resultat no fos l'esperat.

Crec que una solució seria deixar que les plantilles bàsiques siguin paràmetres, que tinguin un nom per defecte, però que es puguin modificar. Així, si n'hi ha una {{date}} prèvia en aquella viquipèdia, que no es pot tocar, podria afegir-se una {{date_global}} (o el que sigui), que sí que sigui compatible. El lloc on definir aquests "sinònims" podria ser la mateixa "tab exception" o un fitxer de text personalitzable per cada llengua, el que vegem que sigui més pràctic.

Et vaig informant!

Amadalvarez (discussiócontribucions)

Si. Està clar que el canvi de nom és la solució. Ara bé, si la versió que trobés t'encaixa i fa allò que vols, ningú t'evita que sigui canviada amb posterioritat i no tens format de mantenir-te en la versió que et convé.

Això ja passa ara, però com que és dins un únic entorn, ja s'ho arreglen internament. El problema serà quan tens una versió global que funciona a la WP-a i WP-b perquè totes dues tenen la mateixa versió de la subplantilla X. Quan a la WP-b la modifiquen, que fem amb la infotaula usuària ? l'evolucionem condicionant la WP-a ola mantenim al nivell que ens convé i provoquem un fork de la subplantilla X ?


Bé, ja estic esperant l'encàrrec !!


Joutbis (discussiócontribucions)

S'hauran d'espavilar els de la WP-b. El que hauran de fer és crear una "versió_global" que sigui la del nostre projecte, i regenerar la plantilla amb el nou nom.

El que no veig de cap manera és tenir totes les viquipèdies client sincronitzades amb una plantilla. Ha de ser a petició i voluntàriament. Per això parlo de "regenerar": allò de "estic a la versió 2.0 i ja estic bé, la 3.0 me la salto, però si la 4.0 m'agrada sí que la instal·lo".

Joutbis (discussiócontribucions)

Hola, Amador

Espero que estiguis bé. Cuida't força. Nosaltres també ho estem.

M'ha costat, però finalment m'ha arribat la refotuda inspiració i ara sí que estic avançant significativament, i això vol dir que tinc unes quantes preguntes:

  • Els paràmetres amb variant, van amb guió baix o guió alt? Al Tabparam hi ha P859_02 (a l'esquerra de l'igual) però també P642-94 (a la dreta de l'igual, no sé si és significatiu. No és que sigui un problema, puc admetre les dues sintaxis, però voldria saber si hi ha algun matís en el tractament.
  • Al Tabparam, a la definició del P793, hi ha un error sintàctic, crec: surt PP1598
  • A la documentació del Tabparam, explica que la "label" pot tenir el format d'una Qxxxxx o un text. Però en alguns casos hi ha també una P. Per exemple P1344, P1350, P1399. Però no veig que tingui cap efecte (per exemple, a P1350, queda igual). Quin tractament se li ha de fer?
  • Veig que en alguns casos, s'afegeix un paràmetre al Tabexception perquè a Wikidata hi ha una etiqueta amb accents, i volem que els paràmetres siguin sense accents. D'acord, però que sàpigues que no em costaria gens treure els accents del que llegís per Wikidata automàticament, i tot això que t'estalviaries.
  • No veig que la part del ruby, extres i qualifiers s'utilitzi en cap moment. És un tractament posterior?

No em quedo aturat esperant resposta, encara em queda feina per anar fent, però t'avanço les preguntes perquè les vagis responent amb calma.

Amadalvarez (discussiócontribucions)

My dear @Joutbis. Me n'alegro saber que esteu bé. Jo he estat una mica fotut per anar amb males companyies, però no ha estat greu i ara ja estic acabant de sortir. Cert que la meva activitat ha baixat considerablement perquè em faltava esma per posar-m-hi.

A veure. No et diré que no cal que segueixis en la línia de treball ara que has agafat la inspiració, ara bé, estic provant una drecera aparentment molt útil que ha fet el Jmarchn. En resum consisteix a situar:

  • el contingut de la tab param (valors default)
  • de la tab exception (excepcions als noms d'etiquetes i noms de paràmetres
  • i totes les conversions que feia la create pre-infobox (aquell malèvol codi fet "a cocos")

dins un mòdul LUA força estandarditzat per què sigui fàcilment replicable per cada infotaula.

És a dir, la preinfotaula s'autoconstrueix a partir de les taules (que les té internament), rep la crida i, si fos el cas, els paràmetres manuals en llengua local, fa les conversions que cal per passar-ho a notació internacional i crida la infobox passant-li tots els continguts.

Ara estic acabant de fer les adaptacions i fent la documentació per explicar-ho.


Et mantinc al dia i valorem després que ens cal fer. Et sembla ?

Joutbis (discussiócontribucions)

Tal com ho tinc, estic a prop de generar el que fa la create pre-infobox. No entenc gaire el mecanisme amb el LUA, però me'n refio de vosaltres. El que sí que havia vist mentre ho preparava és que caldria canviar la sintaxi dels tabparam i tabexception, o sigui que pot ser que això sigui la solució.

Mentrestant ho deixo en suspens, i vaig fent altres coses. Ja em diràs.

Resposta a «Sintaxi»