From EncyclopAtys
 Translation Status → This page is one of the 25 we would like to see translated into English.
|
 Im Übersetzung im Gange •  Translation in progress •  Traducción requerida •  Original •  Не переведено
|
A short technical guide for experienced contributors and documentation managers.
Contents
Working as a team
Never forget that any document (except protected pages, accessible only to administrators) can be edited at any time by anyone. See below (Edition puis Content Validation) for good practices to be followed.
Talk pages
It is often useful, convenient or necessary to leave a message to someone else. For that purpose a “Talk” page is associated with each document when it is created, for example here: Talk:Wiki Technical Guide [[Talk:{{FULLPAGENAME}}]].
In any case, you must try to maintain something readable, so each topic will start with a title ===Title of the topic==. It is better to have fifty small separate subjects, each with a title, than a single package of fifty subjects. This facilitates discriminated responses in their consideration, implementation, etc.
At the end of the subject, always sign with ~~~~. This immediately lets anyone know who posted the message and when.
Usually, responses are made by indenting as in emails. This is done by opening the line with one more : than the previous part. Obviously each answer, each rebound will be signed. This is very useful for someone who will ask the same questions later on and who will thus see this discussion as part of a “Knowledge Base”.
Last, it may be useful to attach to the title a ✓ to indicate that the subject is closed ==Title of the topic {{OK}}==. If the subject has to be reopened, the ✓ can be replaced by a ✗ {{KO}}.
Unfortunately, those concerned by the question are not necessarily informed (the number of articles monitored - and therefore likely to have their changes notified - is capped so as not to blow up the database). Thus, also think about preventing the person or persons who may be concerned by the discussion by indicating the link to the discussion. Again, title and signature, even if very short, are welcome.
Sponsorship
At first glance we will notice that if the Wiki is easy at writing, it is heavy to manage with all its rules of conviviality and efficiency, its traditions built on the experience of its predecessors, etc. This because the wiki also has its “Lore” (oral tradition).
Do you really want to get involved in the wiki? So don't hesitate to be sponsored, without embarrassment, shyness or shame... We have all made our debut, and perhaps, hopefully, it will be up to you to sponsor later on. You don't know anyone? Try to contact “alumni” on https://chat.ryzom.com/channel/pj-ryzom_wiki or contact them from Special:ActiveUsers.
Translations
There are four rules that coexist:
- • Forge (development part), Game behaviour chart, Graphic chart, Fundamental categories
- everything must be translated into English to be accessible to as many people as possible, whose majority more or less understand written English;
- • In-Game Behavior Chart, Graphic Chart, Wiki Management Templates, Fundamental Categories
- everything must be translated into all languages;
- • Lore, Chronicles, Public events
- everything must be translated into at least Ryzom's three “mother tongues”: DE, EN and FR;
- • the rest and especially the roleplay parts
- there are no rules, only players' and translators' concerns prevail.
Edition
With the exception of archived documents and documents with the official status of “final document” (Lore, Chronicle), everything can be improved and this is one of the riches of wikis.
Nevertheless, certain rules of constructive conviviality must be respected.
First of all, it is necessary to assess whether or not the changes are significant. There are no rules and it's more of a feeling, but if the change is drastic, it's wise to start by looking at the page's history (button next to “Edit”). If the content (not the form, look, spelling…) has not changed for some time, we can assume that its author left it for this and that the document may have aged, that it may need updating. An example is shown opposite.
An update can be considered drastic when it deletes paragraphs or even lines that are fundamental to the development of the topic. In this case it becomes appropriate to leave a message in the “User Discussion:xyz” page. While waiting for his answer (one week?), it is wise to keep in the modified page the original text passed as a comment. The easiest way to pass a text as a comment is to preface it with <!-- and to follow it with -->. But there are sometimes issues, especially if there are already other comments. In this case, the hammer and chisel can be used by framing the text with <noinclude><includeonly> and </includeonly></noinclude>. Why such a complication? Because it is always necessary to respect the writings of an author and his intellectual authorship, even in free software world. Otherwise, we run the risk of an:
Edit war
Excerpt from Wikipedia Edit warring:
“An edit war occurs when editors who disagree about the content of a page repeatedly override each other's contributions. Editors engaged in a dispute should reach consensus or pursue dispute resolution rather than edit warring. Edit warring is unconstructive and creates animosity between editors, making consensus harder to reach. Users who engage in edit wars risk being blocked or even banned. An editor who repeatedly restores their preferred version is edit warring, regardless of whether those edits are justifiable: “But my edits were right, so it wasn't edit warring” is no defense.”
This should not be confused with the edit conflict . Excerpt translated from Wikipedia Aide:Conflit de versions:
“In Wikipedia, a version conflict or edit conflict occurs when two contributors work on the same page at the same time: the second one who records, having worked with an obsolete version of the page, has his modification rejected. Since version 1.3 of MediaWiki, this only happens if the changes cannot be merged automatically.“
(see Wikipedia Help:Edit conflict for further information)
Working in tranquillity
Of course, incidents on the course and clumsiness will never be avoided at 100%, so the wisest thing to do is to follow the following recommendations (from Wikipedia Aide:Conflit de versions) :
“To avoid version conflicts, the easiest way is to avoid long modifications.
However, this is not always possible. This is why it is recommended, when modifying a page in depth, to first add the banner {{WIP|~~~~}} which is displayed as follows:
!!!! WIP !!!! The last editing was from Maupas on 13.06.2019.
-- Zo'ro-Argh Woren Siloy 28 mai 2019 à 14:19 (CEST)
Once the page is published with this banner, you can modify it at any time. Limit the number of changes by using the preview to make adjustments (this saves time and avoids cluttering the page with recent changes).
When you are finished, don't forget to remove the template {{WIP}}.”
(see Wikipedia Help:Edit conflict for further information)
The draft
Another way to work in peace is to work in your own user space. This space is [[Utilisateur:Zorroargh/Brouillons/...]].
The documents you prepare there are not available to search engines (except explicitly). Even Google shouldn't go there!
Validation of content
Usually, in Ryzom's wikis all pages are free to be processed as long as there is no vandalism. Nevertheless, players may need reliable documents. This essentially concerns:
- The Ryzom code of conduct throughout the game, including this wiki.
- The Lore which sets the fundamental characteristics of the game (homins don't speak Klingon, Karavan doesn't fly on fire dragons and Kamis don't emerge from an oil lamp). These characteristics are detailed in the portal of the Lore. Here, they will be briefly described to indicate their existence.
Other documents may be considered sensitive for maintenance, such as the widely used templates that can change the appearance, or even readability, of the documents.
Finally, contributors, whether developers, players (RP or not), animators or others, may find it useful to request validation of their work.
A document validated by the Lorists, the official communications officers or the administrators is protected against any modifications not expressly authorized.
The Lore
Summary of the specific treatment of documents related to the Lore
Official copy
Text written by the Lorists and transcribed or translated by encyclopatysts.
At the very top of the page, the Lore logo is affixed {{Official Lore}} wihich will display the picture 
.
Creation of a non-lorist user
Pour demander une validation de l'équipe Lore, apposer tout en haut de la page la bannière {{Lore Validation Request}} which is displayed as follows:
Validation
A Lorist affixes, if that has not already being done, the Lore logo, and erases any banners that may have been used to request validation. Then the Lorist (who can delegate this task to an administrator) protects the page. The Lore logo then becomes: 
.
Categories
All data, articles, images, templates, portals, etc., must be categorized.
On the use of categories
Categories are very useful for cataloging documents and easing their search. It must be understood that a category resembles a set in the mathematical sense of the term, in other words:
- an article can belong to several sets;
- a set of article can be fully included in another;
- It is unnecessary to declare that an article belongs to two sets if one of them is completely included in the other.
Example: a red sock can belong to the categories: socks, red objects, red clothes, clothes. Normally, declaring that this sock belongs to the red clothes is sufficient. But one could also say that it belongs to the socks and to the red objects without referring to red clothes. In both cases, it is useless to declare that it belongs to the clothes.
The choice of categories can sometimes be linked to the tools that allow you to search in a category and that are often displayed in portals. For example:
Portal …
There are for now 19 pages …
Ce qui est obtenu par There are for now {{Number of pages}} pages on …
Of course, it appears from the previous example that there may be exceptions mainly related to the ergonomics of the research. Indeed, the automatic search (random search for an item to include, for example - see Spotlight on below) in category trees requires a lot of time and energy. Therefore, it is preferable to use {{Number of pages}} that does not go down in sub-categories.
The main categories of this wiki
Wikis, linked to the Ryzom universe, are supposed to share data common to the basic languages of the game. These common data are grouped in four trees detailed in the article Categorization. Only the “big branches” are detailed to leave the freedom to organize the data to each linguistic group. But these trunks and their “big branches” are essential, especially for translators who want to easily navigate between groups of articles.
Template
Translated excerpt from Wikipédia Aide:Modèle
“A template is used to reproduce the same message, or the same layout, on several pages, sometimes according to parameters.
It is a pre-written element, more or less complex, intended to be embedded in a page in order to instantly obtain the desired visual result (formatting, display of specific elements, etc.). The banners at the top of the articles, the infoboxes, the centuries display… are templates.”
(see Wikipedia Help:Template for further information)
Visual aspect and graphic charter
The visual aspect must recall the identity of the game. For example: “infoboxes” remind us of “memory ambers” (RP) or interfaces of the Karavan (OOC). Icons in general refer more or less clearly to the game world.
A graphic charter has two functions (at least):
- an identification function, recalling the spirit of the site (for example by using the emblematic colours of nations, factions);
- an ergonomic function, by avoiding the “element of surprise”, i.e. avoiding differences of behaviour between pages or between translations.
For these two reasons, it should be adhered to as much as possible.
Banners, seals and indicators in header
Header or paragraph templates are used to alert the reader on the way the page they are consulting should be interpreted (obsolescence, in the process of being written, etc.) and to highlight important announcements regarding the article.
Footer templates are used to provide the reader with additional information that may be of interest after reading the page.
Page body
Page body templates are used to complete or highlight information related to the current page. Highlightings can be diverse, such as large inserts or various typographic layouts.
All templates
Warning : not exactly the same for all languages, but let us try to harmonize them as much as possible.
All templates are placed in the Category:Templates whose tree view is explained in the document Categorization#The_Wikipatys
Portal
Les portails dans notre wiki servent de pages d’accueil des différents grands centres d'intérêt du jeu. Ils sont répertoriés dans le cartouche {{Portal bottom}}
Ryzom: The Lore • The Game OOC
Atys: Atys world • Flora • Fauna
Nations: Fyros • Matis • Tryker • Zoraï
Factions: Kami • Karavan • Marauders • Rangers • Trytonists
Encyclopedia: Atys Chronicles • The Great Library • Mysteries OOC
Tous les portails ont une structure similaire, mais leur apparence varie selon la complexité des données qu'ils présentent. En général un portail comporte, de haut en bas :
- plusieurs onglets de sous-thèmes, l'accueil général positionnant la lecture le premier onglet ; dans certains cas, il peut y avoir une seconde rangée d'onglets ;
- le nombre d'articles concernés et catégorisés (voir les catégories associées) ;
- un résumé ;
- des informations (à gauche la « Doc du jour », à droite un panneau d'affichage) ;
- le cartouche récapitulant les principaux portails du Wiki de Ryzom (
{{Portal bottom|}}).
Les portails n'ont pas été fabriqués en un jour et donc leur modèle s'est affiné au cours du temps. En général on essaye d'y inclure des documents en utilisant le modèle {{:NOMDOC}} où NOMDOC=Nom du document à inclure.
Doc du jour
Il est parfois agréable d'avoir une documentation qui donne un aperçu des thèmes présentés réunis sous le portail. Cela peut se faire comme suit :
| Un document différent inclus | ENGLISH | FRANÇAIS |
|---|---|---|
| Quand nécessaire | {{:Featured article/...}} | {{:Lumière sur/...}} |
| Chaque jour de la semaine | {{:Featured article/GBA/Week/{{CURRENTDOW}}}} | {{:Lumière sur/.../Jour/{{CURRENTDOW}}}} |
| Chaque jour du mois | {{:Featured article/GBA/Month/{{CURRENTDAY2}}}} | {{:Lumière sur/.../Mois/{{CURRENTDAY2}}}} |
Panneau d'affichage
Les panneaux d'affichage contiennent des informations concernant aussi bien les lecteurs que le contributeur. Cela peut aller de la simple information aux urgences en passant par les « "To do lists" et les « Trucs et astuces ».
Les catégories associées
Toutes les pages concernées
Pour associer un article à un portail, il suffit d'ajouter en bas du texte de l'article en question un bloc d'instructions du type suivant :
{{clear}}{{Last version link}}
<noinclude>{{Portal|xxx}}
[[Category:yyy]]</noinclude>
où:
- le « clear » permet d'assurer que la barre de navigation vers le portail est bien en-dessus de la dernière image ;
- le « last version link » permet d'horodater la page et ajoute un onglet discret permettant de retrouver l'original d'une inclusion ;
- le « noinclude » peut être mis pour ne pas polluer l'inclusion.
À la une
L'ajout de la bannière de navigation vers le portail range en outre l'article dans des catégories « cachées », catégories qui ne seront pas affichées pour le lecteur, car inopportunes, mais qui sont signalées par un [+] placé après la dernière catégorie affichée. La technique de choix au hasard a été condamnée par Mediawiki, car trop coûteuse. Actuellement, on lui préfère un choix bridé (jour de la semaine ou du mois). Cela impose de créer une à une les redirections vers les pages qu'on souhaite mettre en lumière. Ainsi, par exemple, la page "Lumière sur/GBA/Jour/3" (3 du mois ou le mercredi) est redirigée vers "Primes Raider".
Que faire si l'article est trop long à inclure, ou si seulement certaines de ses parties sont intéressantes ?
Le plus sage est d'indiquer les parties à afficher ou occulter dans la future inclusion en les balisant dans larticle original.
- Les balises
<noinclude>et</noinclude>permettent d'exclure les parties qu'elles encadrent de la future inclusion. - Les balises
<onlyinclude>et</onlyinclude>permettent d'inclure les seules parties qu'elles encadrent dans la future inclusion. - Les balises
<includeonly>et</includeonly>permettent d'inclure les seules parties qu'elles encadrent dans la future inclusion, tout en les masquant dans l'article original (à manipuler prudemment dans un modèle).
{{read more|<l'article original>}} affiché ci-dessous) mais l'affiche dans l'inclusion.
