Roblox Wiki:Info
|
Archived Page This article has outdated information. It is now archived, only kept for historical purposes. Generally, outdated articles write about how to use or interact with the Roblox website. The services and features as written at the time have been changed or removed by Roblox Corporation. External links may be substituted with a Wayback Machine or Roblox Forum Archive link. |
This page is archived. For the Legacy Roblox Wiki project's respective info page, it's at Help:Contributing.
This article is a summary of where we are currently at with templates and what you should use when writing articles. It will probably require some adjustments, suggest them on the discussion page or edit the page to do them yourself.
Just as a note, this is not a guideline or anything. It is just to help writers and editors not get confused. It also serves as an help page in general for the wiki.
Members
Members (properties, events and methods) should be on their own page, named from their name followed by their type (e.g. FindFirstChild (Method)). The page with the name of the member (in the case of the previous example, FindFirstChild), should be a redirect to the page of the method.
Similar articles
If there is another article which is related to the name of the redirect page, do not make the redirect page redirect to a disambiguation page or be itself a disambiguation page! Instead, edit the page the redirect redirects to and use the {{redirect}} template to link to the other article.
If there are many other articles which are related to the name of the redirect page, do the same thing, but instead make the {{redirect}} template link to a page with the same name as the redirect page, followed by " (disambig)", and create a disambiguation page at that location.
Type of properties
Property pages, even though most of them still use the property argument, should be converted, if possible, to instead use the type argument, which should either use the {{type}} template to indicate the type, either contain a link to the page of the type. However, using the property argument is not wrong, this just means that new property pages should instead use the type argument and that older property pages should be slowly converted to use the type argument instead.
Objects
The same rules about similar articles should apply to objects as to members. An example is the Instance page, which redirects to the page of the Instance object.
Just to make it clear, the {{ObjectPage}} template should always be used and the other object templates should never be used directly (because they are all either inserted by the {{ObjectPage}} template, or deprecated).
Titles
Page titles should always start with a capital letter (the MediaWiki software imposes this, anyway). However, the rest of the words should not be capitalized unless they are normally capitalized in a normal sentence. The same applies to section titles. There are many articles on the wiki which do not follow this, and it should be corrected when possible, though correcting them is not an emergency and capitalizing the title incorrectly is not a crime.
Also, note that titles should ideally never be questions, should never end with punctuation (except when the punction is there as a part of a name) and should never contain links, especially where only part of a heading is linked.
This is described here.
Red links
There is nothing wrong with red links and links that point to inexistant pages should not be removed just because they point to inexistant pages. Of course, links pointing to articles that have no reason to be created should be removed, however, links are good even if they point to an inexistant page.
This is described here.
Code
Lua code, ideally, should always be used either with the {{code and output}} template, either be used with the {{code}} or the {{lua}} template. Putting code in a <code> tag, with or without the lua argument, is not bad, but it is preferrable to use the {{code and output}}, {{code}} or the {{lua}} template. Output which can not be used with the {{code and output}} template should be contained in a <samp> tag, which can optionally be contained in a <pre> tag for the appearance.
Line numbers
If you think that adding line numbers to the code would be useful, this is possible with the {{code and output}}, the {{code}} and the{{lua}} template by specifying the 'linenumbers' parameter, like this:
{{code|linenumbers=true|=
for _ = 1, 50 do
print("Hello World!")
end
}}
The result, in this particular case, would be this:
for _ = 1, 50 do
print("Hello World!")
end
This can also be done with the <code> tag, by adding 'n' to the end, though you must specify a language for it to work:
<code lua n>
for _ = 1, 50 do
print("Hello World!")
end
</syntaxhighlight>
Indentation
Code should always be indented. Indenting should be done with tabs, not with spaces. The {{code and output}}, {{code}} and {{lua}} templates will all change the width of tabs to 4 instead of 8. The {{code}} template also allows changing the tab width with the tabwidth parameter, but this parameter should be left to default unless there is a good reason to do so.
Also, tabs should only be used for indenting and for nothing else. If you want to align arguments and other things, use spaces, not tabs.
Completeness
When adding a new object or member, don't create the page just so it's there, because that's really easy to do. Anyone can do that. Be exceptional by first researching what the object does. If you're stumped, ask for help on the object's talk page.
When adding examples for members, make sure they show the full usage and make sure you actually explain what they do instead of just giving code. If a method has arguments, use them. If an event has parameters, use them. Try to come up with an example that's actually useful, instead of just printing a string to show that it works. Once again, if you're stumped, ask for help on the member's talk page.
If you plan on creating a page for an object or member without having researched it, don't bother!
Image maps
This wiki supports the usage of image maps through the ImageMap extension. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, a map of the world may have each country hyperlinked to further information about that country. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.
Image maps may seem complicated to use, but you can find information about them on the extension's page. There is also an useful tool here on the toolserver that allows you to create image maps easily.
Image maps can be useful, but do not use them to place images normally. Instead, use MediaWiki's syntax:
To include a file in a page, use a link in one of the following forms:
- [[File:File.jpg]] to use the full version of the file
- [[File:File.png|200px|thumb|left|alt text]] to use a 200 pixel wide rendition in a box in the left margin with 'alt text' as description
- [[Media:File.ogg]] for directly linking to the file without displaying the file
You can also give a link to a file's page by adding a colon in front of it, like this: [[:File:File.jpg]]
Finally can also specify what the image links to with the link parameter and you should also always define alternate text for the image with the alt parameter.
Internal links as external links
Sometimes, you might need to use an external link even for an internal link. This is the case for some special pages and for certain actions which require passing certain arguments to the index.php file. You should always try to use internal links when you can, but there are some cases where you will not be able to do so. When this is required, please do it with the fullurl magic word. Also, note that you can make such links look like normal internal links using the built-in plainlinks CSS class. The plainlinks CSS class should however only be used for links that are internal to this wiki, though using them for links on the ROBLOX website, and only on the ROBLOX website, can sometimes be fine, if you really feel it would make the page better.
