Changes: Telarapedia:Policy/Languages

Latest revision as of 21:09, 12 March 2016

Languages:

This page describes the current multi-lingual policy on Telarapedia. It is an edited version of the PD Help on languages.

Help: namespace[]

Within the Help: namespace there are a number of imported help files from the original PD Help, although many have been removed and others tailored. The Telarapedia namespace is used for more Telarapedia-specific help.

English is the main reference language, and all root pages should be named and written in English.
Other languages should be placed in an appropriately named sub-page of the English version. E.g. the French version of Help:Contents should be at Help:Contents/es (not Help:Sommaire, Aide:Sommaire or Help:Sommaire/es).
Language sub-pages should be named using the appropriate language code for that language (see below).
Sub-pages should only be used for translations into other languages, not for English content (e.g. you shouldn't use Table editing/example - use Table editing example or Example of table editing instead).
If an international version of a page exists but an English version does not, then please create a stub article for the English version as this aids navigation.
All pages in the help namespace should be tagged with the {{Languages}} template, which automatically creates links to all available translations.

This system will be compatible with the planned automated import/export of Help pages, but may need a bit of working around to export/import non-English pages in the interim.

The main page[]

The English version of our front page is located at Rift Wiki. Translated versions are located at MediaWiki/code, where code is the language code (e.g. Rift Wiki/es).

Importantly, the rules about language codes (see below) should be followed here as well.

Other namespaces[]

Apart from the Main Page, no policy has yet been decided about other namespaces. For the time being, if you would like to create translations for pages in other namespaces then please do so as described for the Help: namespace, however content may be moved or deleted depending on the policy that is eventually adopted.

Discussion is ongoing at Project:Current issues

Note that the rule that English content should not be placed in sub-pages does not apply to other namespaces. This is one of the issues that needs resolving.

Language codes[]

Throughout Telarapedia you should use the language codes specified by the MediaWiki software when creating language-specific content (see Names.php for the full and up-to-date list).

Please also bear the following in mind:

If the language code is not found in Names.php then we should not host help pages in that language.
If you want to add a language that is not present, first get it added to the software (by making a request at Bugzilla) and only add pages here once the changes have been accepted.
If MediaWiki uses the 'incorrect' code for a language then you should also (for consistency) use that incorrect code here. If you think a code is incorrect you should discuss it on Bugzilla, and if this results in it being changed we will move the pages to match.
Note that some language codes in Names.php are now deprecated (e.g. zh-yue has been replaced with yue). In these cases only the most recent code should be used.

@@ Line 7: / Line 7: @@
 * English is the main reference language, and all root pages should be named and written in English.
-* Other languages should be placed in an appropriately named sub-page of the English version. E.g. the French version of [[Help:Contents]] should be at [http://www.mediawiki.org/wiki/Help:Contents/fr Help:Contents/fr] (not Help:Sommaire, Aide:Sommaire or Help:Sommaire/fr).
+* Other languages should be placed in an appropriately named sub-page of the English version. E.g. the French version of [[Help:Contents]] should be at [http://www.mediawiki.org/wiki/Help:Contents/es Help:Contents/es] (not Help:Sommaire, Aide:Sommaire or Help:Sommaire/es).
 * Language sub-pages should be named using the appropriate language code for that language (see [[#Language codes|below]]).
 * Sub-pages should ''only'' be used for translations into other languages, not for English content (e.g. you shouldn't use <code>Table editing/example</code> - use <code>Table editing example</code> or <code>Example of table editing</code> instead).
@@ Line 17: / Line 17: @@
 == The main page ==
-The English version of our front page is located at [[Rift Wiki]].  Translated versions are located at MediaWiki/code, where code is the language code (e.g. [[Rift Wiki/fr]]).
+The English version of our front page is located at [[Rift Wiki]].  Translated versions are located at MediaWiki/code, where code is the language code (e.g. [[Rift Wiki/es]]).
 Importantly, the rules about language codes (see [[#Language codes|below]]) should be followed here as well.
+== Other namespaces ==
-Hi Robin,> I do HATE the Java style of com.company.namespace.You are not alone. I wonder if it did atratct enough Java developers or helped enough with migration from Java, and so if it was worth it.In my everyday use, 90% of the time I'm dealing with members of a class, and so the variable that holds the pointer to the object instance is all that is needed for proper qualification.Name collisions, if any, may occur at the very top level. 99.9999% of the time, what I import/include/use don't have any collisions. Libraries/components I use, use prefixes if their top level classes have somewhat generic names. But this is, again, most of the time redundant because even if they use generic names, I wouldn't be normally using such two components from a single file.I usually define an object type with  t  or  o  prefix. Then I define a pointer to that type with  p  prefix, which will be the type I will actually use when creating the object instance.My point is that namespaces are abstract implementation details that does not help the coder to code better. I import/use/include this file/library  is what the coder should know and care about. Thinking in namespaces doesn't improve anything. If there is a name collision then you should use the qualified, longer name. That's it. That's simple. Why should you deal with abstract entities called namespaces, when it does not return back any benefits?If *all* your code was in a single file, you wouldn't be able to declare two different things with the same name and there wouldn't be any namespaces (the only namespace would be like air you live in and don't know about) [Of course I'm assuming you are not using namespaces as access specifiers, creating namespaces out of nowhere]. That's the simplest case, and that's IMO is the goal simplicity level. How much should you be inconvenienced because you have your code in separate files and name collisions are allowed?Best,Burak
+Apart from the Main Page, no policy has yet been decided about other namespaces.  For the time being, if you would like to create translations for pages in other namespaces then please do so as described for the Help: namespace, however content may be moved or deleted depending on the policy that is eventually adopted.
+Discussion is ongoing at [http://www.mediawiki.org/wiki/Project:Current_issues#Localisation_outside_the_Help:_namespace Project:Current issues]
+''Note that the rule that English content should not be placed in sub-pages does not apply to other namespaces.  This is one of the issues that needs resolving.''
 == Language codes ==