Les wikis couvrant des domaines thématiques se chevauchant avec le chevauchement de commnautés, tels qu'une branche d'un projet ou une bifurcation de commununauté d'un wiki existant, combinent-et-collent souvent le LangageDeFormes des deux wikis sur une page. Une syntaxe de lien externe comme l'InterWiki brise le flux de texte pour le lecteur, mais les schémas de liens indirects comme les PagesJumelles agissent comme une HaieEpineuse délimitant la frontière entre les deux communautés.
Par conséquent, injectez l'espace-nom d'un wiki (A) à l'intérieur de l'autre (B), en permettant les liens "internes" (par ex. la Casse Chamot sur MeatballWiki) pour lier vers les pages wiki externes. Pour empêcher de casser le flux de texte, le texte utilisé dans le lien doit être ôté de tout ornement : si le LienDeProximité est utilisé sur le wiki A, LienDeProximité, Lien-De-Proximité, Lien_De_Proximité ou similaires doivent être utilisables sur le wiki B (voir WikiNameCanonicalization). Si le site liant utilise un EspaceTreillis, ce peut être fait simplement en injectant l'espace nom de A à l'intérieur d'un sous-espace de l'espace-nom de B, permettant fortuitement la désambiguation de lien comme l'InterWiki et des liens automatiques parent-enfantala PagesJumelles.
Si B a un espace-nom plat, un lien vers la page X devrait pointer vers la page X sur A s'il existe, X sur B s'il n'existe pas sur A mais existe sur B, et s'afficher comme un LienCassé normal seulement si X n'est ni défini sur A et ni défini sur B. (L'injection EspaceTreillis peut ensuite être émulée en partie par la mise en place de liens InterWiki et PagesJumelles vers A.)
Mais, pratiquer le LienDeProximité est sujet au CocktailContexte, parce que la cible du lien se modifie au hasard (de la perspective de l'utilisateur) parce que les pages sont créées et détruites. C'est un problème si le LienDeProximité est utilisé pour lier vers du contenu plutôt que d'utiliser un LangageDeFormes. C'est aussi le cas localement sur un wiki, car les contenu peut être radicalement modifié, mais le problème est amplifié avec les LienDeProximité car les RétroLiens peuvent être brisés, empêchant les liens d'être réparés si le contenu est modifié.
De la prudence doit être requise pour permettre à X d'être défini sur le wiki B même s'il est déjà défini sur le wiki A. Les branches de projets peuvent s'assurer que les pages ne sont créées qu'UneFoisEtUneSeuleFois?, évitant le problème ; les bifurcations communauté peuvent ne pas vouloir cette limite. Forcer les utilisateurs à des URLs artisanales devrait être évité. Ce peut être fait en plaçant les liens vers les pages d'édition appropriées en bas de la page de lien sur le wiki B, ou quelque part ailleurs à portée de main (par ex sur la page d'édition).
Les bifurcations de communautés hostiles peuvent avoir besoin d'être prudentes au moment d'installer un LienDeProximité vers le wiki bifurqué, parce que les utilisateurs peuvent être perplexes au milieu d'une communauté différente, avec potentiellement une syntaxe d'édition différente, des règles de copyright et des attentes communauté. Dans ce cas, la HaieEpineuse des PagesJumelles agira comme un avertissement à l'utilisateur qu'il n'est "plus dans le Kansas".
Les liens de proximité sont des liens qui apparaissent comme des liens ordinaires mais pointent vers un site différent ou un EspaceNom différent sur le même site. Si deux wikis A et B agissent en tant que deux espaces noms différents et qu'ils autorisent les liens vers chacun d'eux, alors quand vous pointez vers la page X sur le wiki A, X peut pointer vers la page X sur A, si elle existe, ou vers la page X sur B, si elle n'existe pas sur A mais qu'elle existe sur B. Plus clairement, cela requiert que A et B échangent de l'information sur les pages qu'ils ont définies. C'est ainsi une méthode de SiteSoeur, mais c'est un pont plus direct que la formulation originale des PagesJumelles.
Voir WikiEspaceNom.
Notez comment cela reste très similaire à la manière dont nous utilisons les EspaceNoms en langage naturel. Si nous parlons de wikis et que je mentionne la SécuritéDouce, alors nous n'avons pas à dire que nous parlons de la MeatBall:SécuritéDouce. Nous avons seulement besoin de qualifier la référence quand nous ne sommes pas sûrs, c.a.d. "Le lien est extrait de ma page personnelle AlexSchroeder sur MeatBall, pas celle présente sur EmacsWiki".
Ainsi les liens de proximité peuvent être réalisés en liens éloignés explicites en les qualifiant avec un moniker InterWiki.
Une note sur la terminologie :
Les LiensDeProximité aident une nouvelle sous-communauté avec ses propres usages wiki à utiliser le langage de formes riche et la database de MeatBall sans violer le compendium du copyright, ou en utilisant l'horrible (UgLy) syntaxe InterWiki. Le projet peut rester en contact direct avec la merveilleuse communauté MeatBall, ce qui évite la bifurcation. Le site projet est ressenti comme une extension de Meatball. PeriPeri a énormément bénéficié de cela et CommunityWiki semble vouloir faire de même. -- ChrisPurcell
Les LiensDeProximité ne sont pas une InterfaceHumaine car ils sont magiques. Il y a des exemples de CocktailContexte parce que la cible du lien se modifie par hasard du point de vue de l'utilisateur une fois les pages créées. Une fois que vous avez créé une page ici, la cible change. Notez aussi que vous pouvez penser que vous pointez vers le Wiki B quand le Wiki A arrive et créer la page ; si le wiki A est d'une priorité supérieure, toute une cible change brusquement pour vous. Et quand vous modifiez l'ordre de l'InterCarte, cela modifiera aussi beaucoup de liens de manière invisible. Aussi, à cette heure il n'existe pas de moyen pratique de créer la page SécuritéDouce sur votre wiki.
Soyez uniforme et soyez visible. L'implémentation de Ward et de Steve des PagesJumelles produit beaucoup plus de sens à cet égard. -- SunirShah
Peut-être que la solution est de faire un langage de programmation de copie et de l'avoir "en utilisant" des rapports sur chaque page. Ainsi, plutôt que d'écrire continuellement Meatball:X, Meatball:Y, Meatball:Z sur quelque page du méta-wikipedia, je pourrais juste écrire "using meatball" en amont et épargner mon doigt fatigué. -- MartinHarper
C'est ce ce que j'ai vu sur TinyWiki à l'époque ; malheureusement je ne peux plus trouver la référence. Quant au commentaire de Sunir : utiliser les liens de proximité produit seulement du sens si je ne veux même pas créer SécuritéDouce sur mon site. Par conséquent, je ne m'occupe pas de cet aspect. Bien que je m'occupe vraiment de l'aspect "magique". Les "fonctionnalités possibles" de Martin ci-dessous pourraient aider. Au moment où j'ai décidé d'indiquer par l'intermédiaire des CSS (couleurs de liens) que le lien dirige hors du site. Et un outil-astuce vous indiquera vers quel site il vous dirige. Le cocktail demeure un problème, mais je ne suis pas sûr de vouloir m'en soucier. Après tout, le contenu distant pourrait avoir aussi bien changé. -- AlexSchroeder
Il existe une extension lien de proximité pour OddMuse [1] qui vérifie l'InterCarte et essaye de lire une liste des pages pour chaque entrée de la carte.
Par exemple, visitez la page personnelle d'AlexSchroeder. [2]
Fonctionnalités possibles :
PeriPeri a un LienDeProximité vers Meatball, mais émule des identifiants-réglés en saisissant le jeu de catégories sur chaque page. Voir en anglais PeriPeri:NearLink pour plus de détails.
Prowiki implémente le LienDeProximité vers différentes espaces-noms dans un wiki. De tels espaces-noms peuvent agir (comme dans FractalWiki) comme des wikis complètement séparés ayant leurs propres ModificationsRécentes, logs, dossiers, catégories, mise en page et langue par défaut. Mais à nouveau ce n'est pas la même chose qu'entre différents serveurs.
Ce qui peut bientôt être nécessaire est une sorte de lien de proximité "multiple", si la même page existe dans plus d'un espace-nom. Actuellement le système fonctionne avec une liste prioritaire - dès qu'une concordance est trouvée dans un des "espaces-noms de proximité" définis, alors le lien est établi. Il serait également possible d'offrir tous ces liens automatiquement ou d'offrir un lien (par exemple un symbole) vers une page additionnelle de commutation. Il pourrait être également possible d'ajouter une option utilisateur pour que l'utilisateur définisse les espaces-noms qui l'intéresse.
Est-ce que les LiensDeProximité, dans ce contexte ont été inventés par ChrisPurcell ? -- BayleShanks
Je pense que ce serait mieux pour l'utilisateur d'agrandir un LienDeProximité ou afficher un lien interwiki. -- HelmutLeitner
Cette page inspire une pensée à propos de "Et si le wiki ciblé n'aime pas la stratégie du LienDeProximité du wiki étranger", à propos de CoopérationSystème? (SystemCooperation?), SymbioticSystems? et ParasiticSystems?. Les LiensDeProximité sont une espèce de LienProfond (DeepLink), et si vous n'aimez pas être lié-profond, vous pourriez opter pour implémenter une DéfenseLienProfond? (DeepLinkDefense).
Je suggérerais que l'affichage (rendu page CommunityWiki) des liens de proximité dans la situation mb+cw soit modifié :
link (--) (--) "page_?_" (normal cw edit form, no change necessary) link (mb) (--) "_MB:page_" (near link shown as interwiki link) link (--) (cw) "_page_" (normal local link, no change necessary) link (mb) (cw) "_page_ (_MB_)" (two links to both pages)
Ce serait simple et transparent pour les utilisateurs. Pas de modifications nécessaires dans le contenu de la page. -- HelmutLeitner
Qu'est ce qui ne va pas avec la couleur+texte survolé sur MB ? C'est vraiment intuitif une fois que vous êtes habitué, et cela ne force pas la dyslexie sur les lecteurs.
Raisons :
Que penser de page<sup>MB</sup> ou page<sub>MB</sub> ? C'est inoffensif, cela affiche l'information, et ne ressemble pas à une SyntaxeWiki? possible.
La couleur n'est pas autorisée pour fournir de l'information supplémentaire importante ; les personnes daltonniennes ColourBlind n'apprécieront pas.