Extension:Page Forms/Common problems/fr

Vous trouverez ci-dessous les questions communes et les problèmes rencontrés lors de l'utilisation de. Cette page ne contient pas les bogues connus de - pour cela, allez sur Bogues connus et fonctionnalités planifiées.



Problèmes MediaWiki

 * Si un modèle contient des titres de section (comme ), lorsque le modèle est affiché sur une page, chaque titre de section aura son propre lien « Modifier ». De tels liens ne sont pas souhaitables, car ils conduiront l'utilisateur à modifier le modèle plutôt que la page actuelle en question. La façon la plus simple d'éviter ce problème est de placer la chaîne   n'importe où dans ce modèle; cela supprimera tous les liens de modification de section de toute page qui contient ce modèle. Une autre option qui vous permet de supprimer sélectivement les liens de section (mais toujours pas recommandée) est d'utiliser les balises, , etc. au lieu de  ,  , etc.



Problèmes liés à Page Forms

 * Vous pouvez modifier la façon dont les dates sont entrées et sorties par les formulaires en ajoutant la ligne  au fichier MediaWiki principal . Par défaut, les dates sont imprimées sous la forme  ; en faisant ce changement, les dates seront alors imprimées sous le format « Juin 20, 2007 » (avec le nom du mois fonction de la langue du wiki).
 * Vous pouvez également définir manuellement le format d'affichage des dates en utilisant la fonction d'analyseur #time définie par l'extension . Pour un format européen de style de date par exemple, vous pouvez avoir quelque chose comme ceci dans le modèle :


 * De même, vous pouvez modifier la façon dont les heures sont saisies et affichées. Si vous avez un champ de formulaire dont le type d'entrée est, par défaut il utilisera le format sur 12 heures, avec AM (pour le matin) et PM (pour l'après-midi). Vous pouvez le changer en format 24 heures en ajoutant dans votre fichier  la ligne :


 * If a page (which we'll call Page A) gets transcluded in another page (which we'll call Page B), and Page A belongs to a category that's associated with a form, it can have the unfortunate side effect of making Page B a member of that category as well, thus giving Page B an "edit with form" tab at the top, even if such a tab is not appropriate. You can solve this problem by putting the category declaration in Page A within a block, which will make Page A a member of that category but not Page B.
 * If, when you go to the special pages  or , you see a database error message that looks like "Access denied for user...", it means your database account lacks permission to create temporary tables.
 * If you run into any JavaScript problems using (such as the "upload file" window not popping up correctly), the issue could be a JavaScript bug coming from another extension, or from the skin. Pour déboguer le problème, ajouter   ou   à la chaîne de l'URL concernée. Ensuite, inspectez la page à l'aide du navigateur, puis cliquez sur Console pour voir s'il y a des messages d'erreur JavaScript.
 * Various of ' actions are done using the MediaWiki job queue, such as creating templates and properties using Special:CreateClass, and automatically generating pages. If these actions do not seem to be getting performed, it could be that the value of is not large enough. By default it is 300 MB (prior to MW 1.22, 100 MB); to increase it, add something like the following to :


 * If a form contains a large number of fields - such as through the use of multiple-instance templates - and not all of them are saved, it could be due to a limitation in PHP. Increasing the value of the  setting in php.ini may help.
 * If you are having problems with within forms, make sure that the following line is not in LocalSettings.php:


 * If is not appearing within textareas, it may help to add the following line to LocalSettings.php:
 * If you want to do any processing on a list of values before calling  on it, such as sorting it, splitting it up or printing its size, it may help you to use the  extension.
 * only handles forms for adding and editing data in wiki pages. You may want forms for other purposes: fortunately, there are a few other form extensions you can use. For example, allows you to create forms for emailing data. See also the MediaWiki forms manual for other such extensions.
 * only handles forms for adding and editing data in wiki pages. You may want forms for other purposes: fortunately, there are a few other form extensions you can use. For example, allows you to create forms for emailing data. See also the MediaWiki forms manual for other such extensions.


 * Standard wiki tables are not allowed within field values. You can overcome this limitation by using  instead of   in the wiki table syntax. If you make use of  within form fields (using the  extension), it will thankfully escape pipes within tables automatically. Or you could just use standard HTML tags to create tables.

Issues with other extensions

 * If you use Semantic MediaWiki for autocompletion, for instance using, you may find that certain values are truncated and instead end with a random series of numbers and characters.



Problèmes liés à l'architecture des données

 * Un problème général est l'utilisation des catégories. L'approche Wikipédia consiste à avoir de nombreuses catégories sur chaque page, pour identifier tous les aspects du sujet de cette page. L'approche générale de est cependant d'avoir une seule catégorie par page, et de faire définir cette catégorie par le modèle principal de la page : En d'autres termes, il est recommandé aux utilisateurs de ne pas entrer directement les déclarations de catégorie. L'exception à cette règle est lorsqu'il est nécessaire de marquer hiérarchiquement la page, c'est-à-dire d'être capable de l'ajouter à différents niveaux d'un arbre de catégories. Le type d'entrée   peut être utilisé à cette fin.
 * Lorsque vous définissez une relation entre deux classes, vous ne savez peut-être pas quelle classe devrait enregistrer cette relation. Usually such relationships will be of the one-to-many variety, also known as parent-child relationships, in which each page of type A has a relationship to any number of pages of type B, while each page of type B always has a relationship to exactly one page of type A. Un exemple concerne les pays et les villes : un pays peut avoir plusieurs villes, mais une ville appartient toujours à un pays donné. Dans ce cas, vous ne pouvez pas savoir si ce sont les pages Pays qui doivent avoir un champ Ville, ou les pages Ville qui doivent avoir un domaine Country, ou même si les deux champs doivent coexister. Dans cette situation, il est recommandé de spécifier la relation seulement de l'enfant vers le parent, c'est-à-dire d'utiliser un champ "Pays" pour les villes et non l'inverse. Cela pour deux raisons: d'abord, cela vous permet d'appliquer la règle selon laquelle chaque enfant a exactement un parent; et deuxièmement, cela rend l'auto-complétion du formulaire plus fiable, puisque les pages des parents sont généralement créées avant les pages de leurs enfants.
 * Vous ne savez peut-être pas si vous devez créer un formulaire ou plusieurs pour un ensemble correspondant de types de pages. For instance, in a wiki about restaurants, should you have a separate form/template/category set for regular restaurants, fast-food restaurants, diners etc., or a single form called "Restaurant", with a corresponding single template and category, that just uses a field to indicate the type of restaurant it is? A good rule of thumb is to look at the set of data that you want to be entered and displayed for each type of page. If it's the same across all the types, then you should probably use a single form/template/category set for all of them. If there are only a few differences, then you might be able to use the "show on select" feature to handle the different cases within a single form. However, if there are significant enough difference in the set of fields being displayed, then it probably makes sense to give such a page type its own form, template and category.
 * Il est possible de créer un espace de noms différent pour chaque type de page. Wikisource does this with an "Author:" namespace, for instance, and some -using wikis have one or more namespaces for different page types. Whether you do this on your wiki is up to you, but it is not recommended that you do it unless there is a real possibility of naming ambiguity otherwise. A massive wiki like Wikipedia will have a great deal of pages that require disambiguation, but most small wikis will barely have any, and so having separate namespaces will probably be a needless complication. (Actuellement, les exemples les plus courants d'ambiguïté dans les petits wikis sont causés parce qu'ils ont des pages pour les villes et les États des États-Unis : « New York » et « Washington » s'inscrivent dans les deux catégories. Il existe diverses solutions à ce problème, mais la plus simple peut être de que chaque état soit référencé par son abréviation sur deux lettres, par exemple "NY" et "WA".)