Guidelines (Nederlands)

N.B.: deze richtlijnen zijn vertaalt met het oog op het schrijven van Nederlandse vertalingen van pagina's. Als je nieuwe Engelstalige pagina's wilt maken, kijk naar de officiële Guidelines.

Alle geregistreerde gebruikers (van het forum) kunnen deze wiki aanpassen. Om het allemaal consistent te houden wordt er verzocht deze richtlijnen te volgen. Als je denkt dat de richtlijnen aangepast moeten worden, of meer informatie moeten bevatten, schroom niet om contact op te nemen met Bartbes.

Doel

De hoofddoelen van deze wiki zijn als volgt:

1. Om de LÖVE API te documenteren en tutorials aan te bieden.
2. Om invormatie aan te bieden over spellen en bibliotheken die LÖVE gebruiken.

Dat gezegd hebbend, het is absoluut toegestaan om informatie over andere dingen toe te voegen die ver buiten die categorieën vallen.

Als je grote veranderingen in deze wiki wilt aanbrengen, zoals een nieuwe structuur voor ingebouwde types wilt neerleggen, bijvoorbeeld; doe het niet. Je moet eerst met Rude praten (in het Engels), anders is er een grote kans dat je aanpassingen toch maar worden teruggedraaid.

Naamconflicten

Om teveel URLs met (haakjes) te voorkomen, moeten documentatiepagina's simpele titels hebben zonder prefixen of suffixen. De logische uitzondering hierop is natuurlijk dat vertaalde pagina's altijd op _(Nederlands) (of _(Русский), afhankelijk van de taal) moeten eindigen. Bijvoorbeeld, naar het type Image kan extern verwezen worden als http://love2d.org/wiki/Image. Voor de Nederlandse versie is het noodzakelijk om naar Image (Nederlands) als http://love2d.org/wiki/Image_(Nederlands) te verwijzen.

Dit kan soms leiden tot naamconflicten, in welk geval de documentatiepagina altijd wint. Als je een spel genaamd Awesome maakt, en LÖVE later een type Awesome krijgt (die mogelijkheid kunnen we niet geheel uitsluiten), dan zal je spel moeten verhuizen naar een andere pagina.

Stijl

Als je praat over types in LÖVE zelf, link ernaar (naar de vertaalde pagina, als het kan). Bijvoorbeeld: “een Image is een object dat op het scherm kan worden weergegeven”.

Wanneer je het over variabeles en code hebt binnen in een normale zin, gebruik de <code>-tag om de leeservaring te verbeteren. Bijvoorbeeld: “als je foo en bar optelt, is het resultaat foobar.”

Documentatie

Documentatiepagina's moeten allemaal dezelfde structuur volgen om de documentatie bruikbaar te maken.

Alle documentatiepagina's moeteen een semantische link naar hun ouder hebben in de Zie ook-sectie. Zonder die link zal het niet verschijnen in de automatische lijsten die op de wiki voorkomen. Een semantische link voor een functie, type, of enum voeg je als volgt toe voor love.audio:

[[parent::love.audio (Nederlands)]]

All documentation pages must also have a semantic, 'list-friendly' description. This is done by adding the following to the bottom of the page:

{{#set:Description=Draws an [[Image]] on screen.}}

Modules

The following 'level 2' headers are allowed, but should only be used if they contain anything.

• Types
• Functions
• Enums
• Notes
• Examples
• See Also

All modules must be assiciated with Category:Modules.

Types

The following 'level 2' headers are allowed, but again, don't use then and leave them empty.

• Functions
• Enums
• Supertypes
• Subtypes
• Notes
• Examples
• See Also

All types must be assiciated with Category:Types.

Functions

For functions, all headers are required, except Notes, Examples and See Also. This means that if a function returns nothing, it should explicitly say that it returns nothing. The same goes for arguments.

Similarly, if there are no constructors for a certain type (e.g. Contact), this should be explicitly mentioned.

The outer items in the list below are 'level 2' headers, and the inner ones are 'level 3'.

• Constructors
• Function
  • Synopsis
  • Arguments
  • Returns
• Notes
• Examples
• See Also

If a function has overloads, repeat the 'Function' header for each overload. This is not required for trailing optional arguments; just indicate the default value in parentheses instead.

Arguments and return values should be presented as a definition list, using Template:param.

All functions must be assiciated with Category:Functions.

Enums

For enums, these headers are allowed:

• Constants
• Notes
• See Also

The constants should be listed as a definition list.

All enums must be associated with Category:Enums.

Games

For games, you can choose your own structure, but you should always add some semantic properties to the page to make it appear correctly in the list of games:

{{#set:Name=NoGame}} (Should be same as page title)
{{#set:Author=User:Rude}}
{{#set:Genre=What kind of game your game is}}
{{#set:LOVE Version=0.6.1}}
{{#set:Description=A short description of your game.}}
{{#set:Screenshot=File:ScreenshotURL.png}}

Screenshots will automatically be resized to fit a box of 161x100 pixels.

Also, put your game in Category:Games to make it appear automatically in the Games page. To put your game in the correct category, add this line at the end of the page.

[[Category:Games]]

It is also recommended that you provide screenshots of your game.

Libraries

No strict rules, but as for games, you should add these semantic properties:

{{#set:LOVE Version=0.6.1}}
{{#set:Description=A short description of your library.}}

Put your library in Category:Libraries to make it appear automatically in on the Libraries page. To put your library in the correct category, add this line at the end of the page.

[[Category:Libraries]]