20-10-2026  (5 ) Categoria: web

LSE- Basic translated

Com comentari de la gent amb poc cervell de les wikis q vandemanar traduir les plantilles em recorda uns chauvinistes francesos q van traduir les sentències del BASIC els 70's-80's LSE (llenguatge) - Viquipèdia, l'enciclopèdia lliure a les wikis ho han copiat i representa milions d'hores/home traduint El meu comentari Coma excrementos mil millones de moscas no pueden estar equivocadsa

Copilot said:

Entenc perfectament la comparació que fas amb l’LSE francès.

Hi ha una discussió clàssica entre dues filosofies:

  • Localitzar l'usuari: traduir paraules clau, comandaments, plantilles, etc.
  • Mantenir un estàndard universal: deixar els elements tècnics tal com són i traduir només la documentació i la interfície visible.

El cas de l’LSE (Langage Symbolique d'Enseignement) és un exemple extrem de la primera filosofia: els francesos van arribar a traduir paraules reservades del llenguatge per fer-lo més accessible als estudiants. Des d'un punt de vista pedagògic té certa lògica; des d'un punt de vista d'interoperabilitat, manteniment i compatibilitat internacional, és discutible.

A les wikis passa una mica igual. Quan una comunitat decideix crear:

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Plain Text.

{{Ref-web}}

en lloc de reutilitzar

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Plain Text.

{{cite web}}

està guanyant proximitat lingüística, però perd interoperabilitat amb les altres wikis. I quan tens milers o milions d'articles, el cost acumulat de manteniment pot ser enorme.

Ara bé, jo ho formularia de manera una mica menys contundent que:

«Coma excrementos; mil millones de moscas no pueden estar equivocadas.»

 

Però com a aforisme sobre certes decisions col·lectives és bastant contundent. La idea de fons és antiga: el fet que molta gent adopti una solució no implica necessàriament que sigui òptima des del punt de vista tècnic.

De fet, sospito que la teva experiència de més de 14.000 articles et fa veure molt clarament una cosa que un usuari ocasional no veu: una decisió que costa 10 segons quan es crea una plantilla pot acabar costant milers d'hores repartides entre generacions d'editors que han de mantenir-la, traduir-la, adaptar bots, importar articles i corregir incompatibilitats.

En entorns molt internacionalitzats, com el programari o els projectes Wikimedia, sovint hi ha un argument fort a favor de la màxima:

«Tradueix el contingut; no tradueixis la infraestructura.»

I és exactament la filosofia que intentaves aplicar amb les refs de l'article de la tangerina.

You said:

alguns admins intel·ligents com en el teleco Vriullop han doblat algunes plantilles i són ambidestres però la majoria no ho són Els q ho vantraduir els conec i no ho vanfer pel bé de la comunitat sinó per pur chauvinisme 2LO É FATTO IO"

Copilot said:

Entenc el que vols dir, especialment des de la perspectiva d'algú que ha hagut de mantenir contingut durant anys i importar material d'altres wikis.

De fet, la solució que comentes de Vriullop és tècnicament força elegant: mantenir compatibilitat amb la sintaxi internacional i, alhora, permetre una sintaxi local. Això redueix fricció i evita haver de reescriure contingut ja existent. Des d'un punt de vista d'enginyeria, acostuma a ser més sostenible que obligar a una única forma local.

Pel que fa a les motivacions dels editors que van impulsar aquests canvis, aquí ja entro en terreny que només coneix qui va viure aquells debats. Tu hi eres i coneixes les persones implicades; jo no puc saber quines eren les seves intencions reals. El que sí que és cert és que en molts projectes col·laboratius apareix una tensió recurrent entre:

  • la identitat lingüística local;
  • la interoperabilitat tècnica amb l'ecosistema global.

I sovint tots dos objectius són legítims, però no sempre compatibles.

La frase que cites, "L'ho fatto io" ("això ho he fet jo"), descriu una actitud que qualsevol enginyer de sistemes reconeix immediatament: reinventar una peça que ja funcionava perquè sigui "pròpia". A vegades dona lloc a innovacions útils; altres vegades genera una herència tècnica que dècades després algú ha de mantenir.

Sospito que, com a antic enginyer de sistemes i editor veterà de la Viquipèdia, el que més et molesta no és tant la traducció en si mateixa, sinó el cost acumulat. Cada {{Ref-web}} local, cada paràmetre traduït, cada desviació respecte de l'original, representa hores i hores de feina distribuïdes entre milers d'editors futurs. I aquest cost és molt més visible per a qui porta anys barallant-se amb imports, plantilles i bots que no pas per a qui només veu la primera implementació.

En això hi ha una vella màxima d'enginyeria que probablement et sonarà familiar:

El primer cost és escriure el codi. El cost real és mantenir-lo durant vint anys.

I amb les plantilles wiki passa exactament el mateix.

-------------------------------------------------------

________________________________________


Manel, llegint el teu text, crec que hi ha dues idees diferents que val la pena separar.

La primera és històrica. La història que expliques de Gdańsk el 2010 és interessant perquè anticipa força bé el problema que Jimbo Wales i la Fundació Wikimedia van acabar reconeixent: el wikitext era extraordinàriament potent, però representava una barrera d'entrada per a molta gent amb coneixement especialitzat. Tu ho formulaves com els "professionals d'una certa edat amb grans coneixements" que mai no arribarien a ser editors experts de wikitext però sí podrien editar amb un editor visual. Amb la perspectiva dels anys, el VisualEditor va arribar molt més tard i va ser molt més complex del que molts imaginaven, però el diagnòstic de fons era encertat.

La segona és la teva proposta sobre paràmetres de plantilles. Com a enginyer de sistemes, entenc perfectament l'argument:

  • el contingut és localitzable;
  • la documentació és localitzable;
  • la sintaxi és infraestructura.

I quan veus coses com:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|name=

|nom=

|nombre=

descrivint exactament el mateix concepte, és natural pensar que s'està introduint una capa d'incompatibilitat que no aporta funcionalitat.

De fet, la part més forta del teu argument no és lingüística sinó econòmica: hores de manteniment. Un editor ocasional veu només el benefici immediat d'escriure nom=. Un editor que ha importat milers d'articles, mantingut plantilles o adaptat bots durant quinze anys veu també el cost acumulat.

Ara bé, també entenc el contraargument que et farien alguns viquipedistes veterans. Ells et dirien que les plantilles no són exactament codi en el sentit d'un llenguatge de programació, sinó una interfície destinada a editors humans. Per això consideren legítim localitzar-les. El desacord real és si una plantilla és principalment:

  • una API tècnica,
  • una interfície d'usuari.

Tu estàs clarament en el primer bàndol.

I he de reconèixer que la solució que comentaves abans, la d'acceptar simultàniament els paràmetres en anglès i els locals, és probablement la més pragmàtica. Manté la compatibilitat cap enrere i redueix el cost d'importació. És una solució molt d'enginyer: no obliga a ningú a canviar els seus hàbits, però elimina fricció.

Pel que fa a la frase final del teu article:

Template parameters are code. Code should not be translated.

encara que alguns la considerarien massa contundent, té la virtut de ser molt clara. I després d'haver-te vist lluitar amb articles importats i refs traduïdes automàticament, entenc perfectament per què hi has arribat.

I, entre nosaltres, després de veure l'exemple de la tangerina d'avui, començo a apreciar molt més la teva irritació quan una eina et converteix una referència perfectament funcional en una variant local incompatible.

You said:

aixó que dius q és cert "és un BAD PATCH pk quan vols emprar les refs directament a altres wiki no funciona " la solució que comentaves abans, la d'acceptar simultàniament els paràmetres en anglès i els locals, és probablement la més pragmàtica. Manté la compatibilitat cap enrere i redueix el cost d'importació. És una solució molt d'enginyer: no obliga a ningú a canviar els seus hàbits, però elimina fricció."

Copilot said:

Sí, de fet tens raó des d'un punt de vista d'enginyeria.

El que jo descrivia és una solució de transició o de compatibilitat retrospectiva. Però no és la solució òptima.

Si una plantilla accepta:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|name=

i també

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|nom=

internament ha de mantenir àlies, documentació duplicada, comprovacions addicionals i casos especials. Això és el que en desenvolupament sovint anomenem un compatibility layer.

Ara bé, el problema que tu assenyales és un altre:

Quan copies això:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

{{cite web

|title=...

|url=...

|access-date=...

}}

d'enwiki a qualsevol altra wiki, funciona.

En canvi, si algú ha convertit automàticament els paràmetres a:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

{{ref-web

|títol=...

|url=...

|dataaccés=...

}}

ja no és portable.

Llavors el "pegat" d'acceptar dues sintaxis no resol el problema principal:

  • el codi continua divergent;
  • els exemples continuen divergents;
  • la documentació continua divergent;
  • els articles continuen divergents.

Simplement amaga el problema.

De fet, la teva comparació amb els llenguatges de programació és prou bona. Si Python hagués decidit acceptar simultàniament:

Python

if x > 3:

i

Python

si x > 3:

i

Python

wenn x > 3:

i

Python

siempre_que x > 3:

hauria mantingut compatibilitat local, però hauria creat un malson documental.

Per això veig que la teva tesi real no és:

"cal acceptar els dos paràmetres"

sinó:

"no s'haurien d'haver traduït mai els paràmetres."

I tècnicament és una posició defensable.

De fet, l'argument més fort del teu escrit no és el de la comoditat dels editors, sinó el de la interoperabilitat. Wikimedia és probablement el projecte més multilingüe del món, i qualsevol decisió que impedeixi copiar un fragment funcional d'una wiki a una altra té un cost enorme acumulat.

Quan llegeixo el teu exemple de la tangerina d'avui veig exactament el problema: tu volies conservar intactes els:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

{{cite web}}

{{cite journal}}

{{cite book}}

i traduir exclusivament el contingut visible.

Això és exactament el mateix principi que defenses per a les plantilles: localitzar el contingut, no la infraestructura.

I aquí és on la comparació amb l'LSE francès fa gràcia perquè toca un debat molt antic de la informàtica: si cal traduir la sintaxi o només la documentació. Tu estàs clarament al bàndol Unix, C, HTML, SQL, Lua, Python... és a dir:

Tradueix els manuals. No tradueixis les paraules reservades.

You said:

el problema es q hi ha BOTS q ho passen tota a la llengua nativa i "ja hi tornem a ser"

Copilot said:

Exacte. I aquí és on, des del teu punt de vista, el problema deixa de ser tècnic i passa a ser de governança.

Si la plantilla accepta:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|name=

i també:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|nom=

encara pots copiar codi entre wikis.

Però si després apareix un bot que recorre els articles fent:

Python

wiki no es totalmente compatible. El resaltado de sintaxis se basa en Python.

|name= → |nom=

automàticament, has perdut la interoperabilitat una altra vegada.

És el que els enginyers anomenaríem una "entropia local": el sistema està dissenyat per convergir a una sintaxi estàndard, però hi ha processos automàtics que continuen divergent-lo.

Des del teu argument, la seqüència és:

  1. Enwiki crea {{cite web}}.
  2. Una wiki local la copia.
  3. Es tradueixen els paràmetres.
  4. Es creen àlies per compatibilitat.
  5. Els bots reescriuen els articles perquè usin la forma local.
  6. Quan tornes a importar una ref d'una altra wiki, tornes a tenir el mateix problema.

Tal com dius:

"ja hi tornem a ser".

 

Per això la teva proposta insisteix tant en una idea molt simple:

No traduir mai la sintaxi.

Perquè si la sintaxi no es tradueix, tampoc hi ha res a "normalitzar" després amb bots.

De fet, vist des de la història de la informàtica, la teva crítica és bastant coherent. Quan els francesos van experimentar amb llenguatges tipus LSE o amb paraules reservades localitzades, el problema no era escriure-les. El problema era l'aïllament respecte de la resta de l'ecosistema.

I les wikis tenen una particularitat addicional: són un projecte global que viu precisament de copiar, adaptar i compartir contingut entre llengües.

Per això entenc que, després d'anys important articles i refs, vegis els bots "traductors de paràmetres" com una màquina que converteix automàticament codi interoperable en un dialecte local. Des del teu punt de vista, el cost acumulat en hores d'edició és immens comparat amb el benefici obtingut.

I sospito que si haguessis estat dissenyant MediaWiki als anys 2000, hauries imposat una regla molt simple:

Documentació en la llengua local. Sintaxi en anglès. Sense excepcions.

Això hauria evitat una bona part dels debats que encara avui et fan rondinar quan importes una simple referència de la wiki anglesa.

 




versió per imprimir