Here is [[Internal pagetitle|an internal pagetitle]]: an internal pagetitle. Text immediately suffixing the link will be incorporated into the link text, preface with <nowiki /> to suppress.
Here is [http://www.example.org/ an external link]: an external link. If no link text is supplied: [1]. Omit brackets for http://www.example.org/ (use <nowiki> to suppress). Same server can be specified using {{SERVERNAME}}.
To link to a Category page without adding the page to the category: [[:Category:Not in this category]]
Downloads
In general when pointing to Alpine Linux downloads stick with the Downloads Page, but if you by any meaning will need to include direct download information, do so by using one of below.
{{Download|alpine}}
For standard
{{Download|alpine-mini}}
For mini
{{DownloadDev|alpine}}
For standard
Download Stable Version Alpine 3.20.3
Download Stable Version Alpine 3.20.3
Download Stable Version Alpine 3.20.3
Links
{{#latestalp:alpine|url}} will give you latest download url for Alpine Linux Standard:
{{#latestalp:alpine|url}}
{{#latestalp:alpine-mini|url}} will give you latest download url for Alpine Linux mini:
{{#latestalp:alpine|url}}
Example:
Start from [{{#latestalp:alpine|url}} Downloading latest Alpine Linux Standard], than continue ...
produces:
Start from [{{#latestalp:alpine|url}} Downloading latest Alpine Linux Standard], than continue ...
<nowiki> collapses whitespace, ignores '''wiki''' [[markup]] but still converts → → entities..
Leading space displays as block element, in monospace, doesn't collapse whitespace.
<pre> displays as block element, in monospace, doesn't collapse whitespace. Otherwise like <nowiki>: it
ignores '''wiki''' [[markup]] but still converts → → entities.
Here is code, teletype, stuff to type, sample output, and a variable.
text{{{1}}}
Centered text
How do I use a template as a signature?
When you look at your preferences, you see a check box for "raw signature." But the field will only take a certain number of characters. What if you want more?
You will need to create two pages, possibly in your userspace.
Create the first page (FIRST PAGE)
Go to your preferences, check "raw signature" and put Template:FIRST PAGE in the signature. Save
Create a second page (SECOND PAGE) (possibly a sub-page of the first)
Go back to the first page (FIRST PAGE) and do Template:SECOND PAGE
Go to the second page (SECOND PAGE) and place the code you wish to have for your signature.
If you don't have this structure, you will still be inserting all your signature code into the raw code wherever your signature is used, because the software will insert "SUBST" in your preferences. You may not mind this, in which case you only need one page. If you want the raw code to only display Template:FIRST PAGE, which looks a lot cleaner, then you need to use the two-page structure.
How to move a page (Wikipedia)
A common example: moving a userspace draft into place. The intended article name is entered without any prefixes.
A move will fail if a page already exists at the target name, unless it is simply a redirect to the present name that has never been modified (check the edit history). The steps for moving a page are as follows:
With the page to be moved displayed, choose the "move" option near the top of the page. In the default Vector skin, this is in a drop-down menu to the right of the screen, after "History" and the "Watchlist" star (see picture). In the Monobook skin, it is a tab at the top. You'll be asked for a new name for the page, and given the option to also move the page's talk page (this box should usually be left checked). Complete the "Reason for move" field (which is like an edit summary). Although filling out the "Reason" field isn't required, you should state a reason for the page move.
When ready, click the move button and, if successful, the page will be renamed to the new title. The old title will become a redirect page, so any links to the old title will still go to the new page. However, note that double redirects (pages that redirect to the original page), will not automatically follow to the new page, so you will have to refer them manually (as explained at How to fix a double redirect and Checking for double redirects). However, if you're an administrator, you can move pages without leaving a redirect behind.
Open the what-links-here for that page (there may be a shortcut link on the page-moved summary screen to let you do this, but the what-links-here link will in any case be in the toolbox, which is near the bottom of the sidebar unless you've customized your skin away from the default Vector).
In the section of that page marked filters, click on the button labeled "Hide links". This will result in the page only showing redirects to the prior name. Open each of the redirect pages (best to do so in new tabs), click edit this page for each one, and change their target to the name of the page to which you have moved the page. Though this is an important cleanup step, if you miss some, they will normally be fixed by a bot shortly afterwards.
If there are more than 50 redirects listed (rare) on the "what links here" page, don't forget to navigate to all parts of the list using the "next 50" or other links available.
Since the article name is reflected in the lead section, that section may need to be updated to be consistent with the new name.
If you moved an article which contains any non-free content (such as images or sound clips), you will need to edit the files' own Wikipedia page, changing the non-free use rationale to refer to the new article title. This is to ensure continued compliance with the non-free content criteria (part 10c), which if not followed, may result in the file's speedy deletion.
Once the page has been moved, this will be recorded in the Move Log and a "move has succeeded" message will be displayed.
Console and Text browsers
Warning: Many console browsers will convert text in edit boxes to the encoding in use by your terminal (or what the browser thinks is your terminal's encoding which may not be the same thing) either at page load time (links and lynx) or when editing a field (w3m). If your terminal encoding is UTF-8 this is not a problem but if your terminal is using a legacy encoding (or is using UTF-8 but your browser thinks it's using a legacy encoding) then this is likely to destroy characters that are not present in the encoding your terminal is using when you save the page after editing.
ELinks
Text only, but renders tables and frames.
Supports HTTP authentication.
Users can use their text editor of choice to edit textarea fields.
Problems with editing UTF-8; set "User-agent identification" (in setup->option manager->protocols->http) to something like "Lynx/elinks/%v (textmode; %s; %t-%b)" to get non-ascii characters as hex codes.
View is enhanced (especially of diffs) by using the following user.css and lua hook file (place in ${HOME}/.elinks and enable via option manager)
user.css:
/*
1. place in ~/.elinks
2. set user css to be "user.css" (no path, relative to ~/.elinks)
3. use document colors: use 1 or 2
/
.diffchange {
color: red;
font-weight: bold;
}
.diff-deletedline {
color: green;
}
.diff-addedline {
color: cyan;
}
a.new {
color: cyan;
font-weight: bold;
}
hooks.lua:
--[[
lua preformatting function
1. lua has to be installed before compiling elinks; if this
is the case, it is used by default
2. place this file in ~/.elinks
this file does:
show and element, make more evident
preformatting for wikipedia pages: since elinks ignores the
class attribute of tags, we move it into the inner
element
]]
testing=false
function pre_format_html_hook (url, html)
-- formatting for
html = string.gsub(html, '<[sS]>', '[S:')
html = string.gsub(html, '</[sS]>', ':S]')
html = string.gsub(html, '<[dD][eE][lL]>', '[DEL:')
html = string.gsub(html, '</[dD][eE][lL]>', ':DEL]')
html = string.gsub(html, '<[iI][nN][sS]>', '[INS:')
html = string.gsub(html, '</[iI][nN][sS]>', ':INS]')
-- diff-addedline and diff-deletedline classes
if string.find(url, "diff=", 1, 1) or testing then
html = string.gsub(html, '
',
'
')
html = string.gsub(html, '
',
'
')
end
return html
end
Links
In old versions the login may be broken. (Try to check referrer sending and cookie handling. If everything fails try to use ELinks, and check the same settings.)
Lynx
Users can use their text editor of choice to edit textarea fields (this feature needs to be enabled at compile time)
Forces wrapping of very long lines in a textarea, which is a problem in editing some articles.
Display options for non-ASCII characters affect editing.
Most tables are rendered as simple text.
Viewing of diffs and redlinks can be improved by adding the following to the lynx.lss configuration file: