Is there a way to reassign or change the core namespaces of mediawiki? For example, I'm having difficulty linking to a page I want to call "Template" because mediawiki has a namespace already for Template. I'd like to re-assign the mediawiki "template" namespace to something else.
Any thoughts?
You can partly change the name, under localsettings.php, add extra namespaces with the code number of template like adding main as 0, main:Main Page will redirect to Main Page
Basically, no.
You can change the display names of the namespaces in Special:AllMessages, and you can make aliases for the namespaces with $wgNamespaceAliases, but I don't think you can actually change the underlying names.
For example, to go to the talk page for Stack Overflow on the german wikipedia you can use http://de.wikipedia.org/wiki/Talk:Stack_Overflow or http://de.wikipedia.org/wiki/Diskussion:Stack_Overflow and they both take you to the same place.
BUT: The english wikipedia there is a page called Template and I just tested by making a page called Template on my wiki with no problems. So maybe it isn't the template namespace interfering. When I made a link to Template on my wikipedia userpage with [[Template]] it linked to the article Template, not to the name space.
I would advise very strongly against changing the names of any standard namespace. A name like "template" is so generic that surely you can find something else. For instance if you want to store code for C++ templates, call the namespace "Cpp_template" or "template_code".
Nothing in mediawiki prevents you from just using a colon as a prefix in a name, giving you exactly the same syntax as "supported" namespaces. I use that often. If it becomes helpful to differentiate those namespaces, e.g. for searching, then yes you can support them by editing LocalSettings.php (get the capitalization right folks, it matters in English, Linux shells and mediawiki).
For instance if I want to mark out a term as potentially problematic or biased, I use a "term:" prefix, for things like "term:Make_America_Great_Again" or "term:MAGA" which means the exact opposite of what its proponents claim. If I want to mark out verb phrases used in a user interface, it's "verb:delete" etc. For most of these it's not actually necessary to "support" the namespace.
You should ruthlessly customize namespaces and (even more so) categories for your task and purposes. If you are copying categories from some other wiki, you are probably doing it wrong. If you have not created any custom namespaces at least in the informal way I suggest, you are again probably doing it wrong.
But renaming standard namespaces or pages is a bad idea. You can use redirects for some of the same purposes. For instance, some "Special" pages have confusing and semantically inappropriate names that don't fit Wikipedia's or English language conventions. So I always redirect things like "Special:Wantedpages" with a new name like "open_links_in_this_wiki" which is semantically exact and doesn't tell people to just go create "wanted" pages with garbage in them instead of waiting to figure out if the name is appropriate or converging.
As a general rule, if you can't use the name easily in an English language sentence and [[just put brackets around it]], you need a redirect or rename.
Related
A Mediawiki template can use Magic Words to identify what page it's being transcluded into: {{PAGENAME}} — and various other details of its namespace. What I can't find out is if there's a Magic Word or some other technique to identify what section (or subsection) of the page* it's being transcluded into.
*i.e. what the headings and subheadings (used to compile the page's table of contents) closest above it are.
Templates need to be context-independent. Currently there are ways to work around that, so you could probably create an extension doing this, but it wouldn't survive the ongoing parser rewrite.
The HTML standard doesn't allow duplicate IDs in the same document, but what are the tools web developers can use to enforce this requirement?
Some difficulties developers are faced with:
JavaScript can create IDs dynamically, so static checks don't always work.
Libraries being used may also create IDs in the document, and not all those IDs are named by developers.
If your using an ide like dreamweaver there is orange dots on the same line as your id.
Best way to avoid having more than 1 id is to only use id's for structural stuff or something you know there is only going to be 1 of and classes for everything else.
Hope that helps 😎
Is there a tool available which would convert the sources given into HTML with links?
By links I mean that every type, class, and method used would point via href to its definition.
I haven't managed to make highlight, syntax-highlight, nor pygments work this way. Even if it supports input from ctags, it only adds the title attribute, but not links.
Highlight can easily be modified to support things such as adding links to function / class definitions, as well as manual entries.
I was able to hook on to the class and function detection, and have each instance linked to the PHP Manual in my testing. I don't know what you'd want yours to link to, so it's your choice (per language, of course.)
Depending upon the language of your source code you might want to use doxygen. It supports a variety of source languages and can export the comments to HTML and LaTeX.
Many modern languages, like Java or C# support XML-comments to document the source code. You can then extract these comments into a single XML file by compiling them with special options. From this XML you can then easily produce HTML by adding an appropriate CSS sheet. MSDN documentation, for example, is largely based upon these HTML files generated in automated mode.
i'm not sure to explain what i'm looking for.
What's the name of the "source code parser" for publish code, in HTML ?
For example, when i write some source code here in stack overflow, system auto-detect the sintax and write "correct" source code in html.
I've noticed that exists the HTML <"code"> tag, but it simply write source code in "courier" font.
So i'm asking you if exists some "external" component that, given a text, parse it out correctly in a HTML page.
Thank you!
SO uses prettify to syntax highlight the <code> snippets.
Source: Which tools and technologies were used to build the Trilogy?
It is a JavaScript tool that scans a page for code snippets, and colours them on the fly. The downside of this solution is that it doesn't work with JavaScript turned off. Seeing as syntax colouring is not really an essential task, it is arguably a small downside.
The system is called Markdown and here is an explanation of the code blocks it uses.
For the syntax highlighting that you mentioned, a different system is used called prettify.
There are two components to this:
The CSS/HTML structure for syntax highlighting (e.g. styles for printing keywords, #s, strings, comments etc... in certain colors). This can be generic or per-language.
The code parser (grammar parser), which breaks the code up into tokens and labels the tokens with the appropriate classes. This can be implemented on either back-end via whatever language your back-end is in; or on front-end via JavaScript (the example of the latter is Google's Code Pretty which is used by StackOverflow).
It can be coupled with some heuristic logic to decide what language the code belongs to (and thus which grammar/parser to use).
Internationalizing web apps always seems to be a chore. No matter how much you plan ahead for pluggable languages, there's always issues with encoding, funky phrasing that doesn't fit your templates, and other problems.
I think it would be useful to get the SO community's input for a set of things that programmers should look out for when deciding to internationalize their web apps.
Internationalization is hard, here's a few things I've learned from working with 2 websites that were in over 20 different languages:
Use UTF-8 everywhere. No exceptions. HTML, server-side language (watch out for PHP especially), database, etc.
No text in images unless you want a ton of work. Use CSS to put text over images if necessary.
Separate configuration from localization. That way localizers can translate the text and you can deal with different configurations per locale (features, layout, etc). You don't want localizers to have the ability to mess with your app.
Make sure your layouts can deal with text that is 2-3 times longer than English. And also 50% less than English (Japanese and Chinese are often shorter).
Some languages need larger font sizes (Japanese, Chinese)
Colors are locale-specific also. Red and green don't mean the same thing everywhere!
Add a classname that is the locale name to the body tag of your documents. That way you can specify a specific locale's layout in your CSS file easily.
Watch out for variable substitution. Don't split your strings. Leave them whole like this: "You have X new messages" and replace the 'X' with the #.
Different languages have different pluralization. 0, 1, 2-4, 5-7, 7-infinity. Hard to deal with.
Context is difficult. Sometimes localizers need to know where/how a string is used to make sure it's translated correctly.
Resources:
http://interglacial.com/~sburke/tpj/as_html/tpj13.html
http://www.ryandoherty.net/2008/05/26/quick-tips-for-localizing-web-apps/
http://ed.agadak.net/2007/12/one-potato-two-potato-three-potato-four
In my company all our strings are stored in *.properties files. Our build tools build a "test languange" copy of the properties files, which replace a string like this:
Click here
with something like this:
[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]
Now, when we set the language to "test" in our config files, these properties files are used. (And of course we don't ship the test language files).
This allows us to:
Make sure that Unicode characters are displayed correctly, including Japanese/Chinese/Korean.
Make sure that the layout scales appropriately for languages with longer words (German in particular has longer words on average than English).
Spot any hard-coded strings (as they will be in plain-English).
As for the actual translation, this is done by professional translators, not developers.
As an English person living abroad I have become frustrated by many web application's approach to internationalization and have blogged about my frustrations.
My tips would be:
think about how you show an international version of a page
using geolocation might work for many users, but as my examples show for many it will not
why not use the Accept-Language header for determining which language to serve
if a user accesses a page via a search engine then don't redirect them somewhere else e.g. to a homepage in a different language
it's extremely annoying to change language and have a different page reload - either serve the same page or warn the user that the current content is not available in a different language before redirecting them
English is a very common language, so perhaps default to that
But make sure the change language option is clear on the GUI (I like what Google Maps are doing, as shown in the post)
All I see on the Web is companies getting internalization wrong. Getting it right from a user's perspective is tricky indeed.
I have a couple apps that are "bilingual"
I used resource files in ASP.NET1.1
There is also something called the String Resource Tool
Basically you put all your strings in a .RES file for both languages and then determine what file to read from based on Culture or whether someone clicked a Link for the language
The biggest gotcha is making sure the Translations are done correctly