Propositions pour le logiciel[modifier | modifier le code]

Voici des propositions pour le logiciel avant une formulation (en) sur Bugzilla/Wikimedia/Commons.

Note: Je déplore la fermeture de Wikipédia:Propositions pour le logiciel par iAlex.

Recadrage des images[modifier | modifier le code]

Description: Afficher une image recadrée/rognée
But: limiter la prolifération des images. En cartographie, on dispose d'un jeu limité de cartes SVG de grandes qualités. La cartes de subdivisions manquent cruellement (les départements français). En l'état actuel des choses, on créerai la sous-carte pas simple copie et recadrage de la (grosse) carte initiale. C'est nul !
Moyen: Ajouter un paramètre geometry à la commande [[Image:...|geometry|...]].; La syntaxe de ce paramètre geometry reste à définir, mais ahma celle des commandes X devrait être copiée.
Amélioration/Alternative: De plus, cette extension pourrait être combinée avec/basée sur Commons:Help:Gadget-ImageAnnotator (voir Commons:Commons:Using_ImageAnnotator). On procéderais alors ainsi :

[[Image:Bundesrat der Schweiz 2009 Teil 1.JPG#Members of the Federal Council]]

(en)

Description: View a cropped image
Aim: limit the proliferation of images. Especially within cartography, it has a small set of SVG maps of great qualities and many maps of subdivisions don't exist. In the present state of things, we will create these missing sub-maps by copying and reframing the original map ; which is a bad way to do that.

How to: Add a parameter geometry to the command [[Image:...|geometry|...]].; The syntax of this parameter geometry remains to be defined, but imho, commandes X should be copied.

Improvement: Moreover, this extension could be combined with (or based on) Commons:Help:Gadget-ImageAnnotator (see Commons:Commons:Using_ImageAnnotator). Then, we will proceed as follows :

[[Image:Bundesrat der Schweiz 2009 Teil 1.JPG#Members of the Federal Council]]

Bases de données[modifier | modifier le code]

Le plus gros défaut de conception de Wikimédia est l'absence de base de données pour les données communes :

Images, fichiers : On a rattrapé cela avec Commons (de nombreux transferts restent à faire

).

Lien interwiki: sont indépendants de la langue à faire

Données numérique : dates, coordonnées géographiques, dimensions, ...

Données actuelles/évolutives : décès, classements sportifs (ATP par exemple), les personnes selon les postes (les chefs d'état par exemple)

Serveur GIS

Certes, il est malheureusement bien tard pour rectifier cela. Pour autant, cette évolution semble inéluctable.

L'état actuel[modifier | modifier le code]

Il existe déjà des bases de données sous la forme de sous-espace :

Cartographique Modèle:Géolocalisation (--STyx) (en:Location map) : basée sur un jeu de “modèles de type switch” (voir Wikipédia:Jargon/Géolocalisation)
Thématique Modèle:Ébauche (--Cépey) : même principe (voir Modèle:Ébauche/Aide paramètres)
Géopolitique : Modèle:Drapeau2 (--Xfigpower) Modèle:Country data pays
Personne : Wikipédia:Métadonnées personne (--Robin Hood ?, Bibi Saint-Pol ?, ... ?) : Elle est embryonnaire (?) et n'est pas exploitable dans WP
Autres : (de) de:Kategorie:Vorlage:Metadaten

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Actuellement, on interroge la base de données ainsi (pour simplifier, on omet ici d'éventuels paramètres) :

{{Géolocalisation/région|fonction}}

ou ainsi

{{Drapeau2/fonction|région}}

L'ajout de nouvelles fonctions/données, a un coût quadratique : plus le modèle a de fonctions, plus il est employé et plus la recherche de la valeur est couteuse.

Le nombre de tels espaces devrait augmenter pour limiter le nombre de fonctions par modèles.

L'option « un modèle = une valeur » est à envisager.

Solution à court terme[modifier | modifier le code]

Créer une arborescence de données selon le principe « 1 modèle = 1 valeur » (certaines valeurs restent paramétrés (i.e., fonctions); mais le modèle doit rester très petit)

On interroge alors la base de données soit ainsi :

{{... /fonction/région}}

soit (mieux amha) ainsi

{{.../région/fonction}}

Noter que la conversion devrait être aisée en employant un BOT.

Ainsi, on peut créer de nouvelles fonctions, ajouter de nouvelles régions sans que les modèles existant soient remaniés (pas de charge pour le serveur ; pas d'augmentation du coût d'obtention des données).

On peut donc envisager une base de données de grande ampleurs :

{{... /toponyme/fonction}}
{{... /thème/fonction}}
{{... /personne/fonction}}
....

Solution à moyen terme[modifier | modifier le code]

Création d'un nouvel espace de noms Data:

{{Data:.../région/fonction}}

Sous-espaces : Thème • Toponyme • Personnalité • Actuel • Biologie … ?

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Solution à long terme[modifier | modifier le code]

Un (/des?) serveur de données similaire à Commons.
ou faire évoluer Commons : Voir par exemple Commons:Template:Location map (une ébauche) et le code de Commons:Image:China_edcp_location_map.svg. Actuellement, une Image: peut être utlisée en tant que modèle sur commons ; mais (son "importation?") pas sur Wikipédia, hélas. Sinon {{Géolocalisation/Chine}} pourrait simplement être

#REDIRECTION[[Image:China_edcp_location_map.svg]]

Recommandation[modifier | modifier le code]

Catégorisation automatique[modifier | modifier le code]

Note: La « recommandation » actuelle « Utilisation des modèles catégorisants » vient de [1]. Elle est totalement obsolète et depuis longtemps erronée (depuis l'apparition des parserfunctions).

Lien

Voir les pages liées à {{Catégorise}} et {{Catégorisée par}}.
Article détaillé : Projet:Catégories/Réflexions/Archive 2007.
Aide détaillée : Projet:Catégories/Recommandation/Modèle de fiche.

Harmonisation du paramétrage[modifier | modifier le code]

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Article détaillé : Projet:Modèle/Harmonisation.

Amélioration du code des infoboxes[modifier | modifier le code]

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

A reprendre, à développer. Voir {{Fiche}}, {{Infobox}}

Aide détaillée : Projet:Catégories/Recommandation/Modèle de fiche.

Conventions de traitement des homonymies[modifier | modifier le code]

Problématique: Lorsqu'il existe plusieurs pages « titre (classe) » pour un même titre, quelle page sera nommée « titre » ? Quelle « classe » adopter ?

Exemples: « Irlande (pays) », « Irlande (île) » ; « Géorgie (pays) », « Géorgie (États-Unis) » (/« Géorgie (état) ») ; ...

Principe: Voici un principe de bon sens qui doit inspirer les règles de résolution des homonymies :

Lorsqu'il existe plusieurs pages « titre (classe) », plus une page a de pages liées, plus « titre » est justifié pour cette page.

Un début de règle

Lorsqu'il existe plusieurs pages « titre (classe) », La page nommée « titre » sera celle dont la classe est la plus élevée dans la hiérarchie. Cette hiérarchie est :

pays

subdivisions administratives (à déterminer)

subdivisions naturelles (à déterminer)

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

homonymie

Par conséquent, la page de résolution des homonymies sera toujours « titre (homonymie) ».

L'état des choses: La "recommandation" actuelle n'en est pas une (quelques évolutions : [2] [3]).; « Résolution d'homonymie » doit être plutôt considéré comme un exemple ; malheureusement il ne renvoie pas à « Dénomination ».

Motivation: Outre le fait de simplifier les liens internes (notamment, faire disparaître les « [[titre (pays)|titre]] » ; « [[titre (département)|titre]] »), le but est que les clés des bases de données correspondent aux titres des articles. Cette correspondance est très imparfaite actuellement à cause du laissez-aller dans la nomenclature articles (les cas de l'Allier est de l'Irlande, par exemple, sont éloquents).