Talk:Main Page/Archive

Working on the translations

Hi, I have seen a posting from wikipedia:nl:GerardM on the dutch wikipedia about this wiki. Am I correct that this is a wiki that can be used to translate here the local MediaWiki-language fields and that then someone will make a patch so the languageXX.php can be updated of that language?

If this is correct; I am willing to help with NL (= make me sysop here). --Walter 15. toukokuuta 2006 kello 09.38 (UTC)

GnuFDL?

Where is the license of this website???

It does not have a license. We publish the texts that are created here under the license of the projects they are used for (MediaWiki: GPL, FreeCol: GPL). Cheers! Siebrand 16:09, 9 October 2007 (UTC)

P.s. you are?

Correction. MediaWiki is software, thus it uses GPL. This license does not cover texts. They must fall under the GFDL. Sherbrooke 15:02, 31 October 2007 (UTC)

Why FreeCol on the main page ?

I do not have anything against this game. However, this site is dedicated to MediaWiki translation. There is enough work to keep all Betawiki contributors busy. It should be removed. Sherbrooke 15:04, 31 October 2007 (UTC)

Read the intro part on the main page, this is a private wiki, and it can be used for whatever by the person who owns it and runs it. And if it's used for some purpose, shouldn't that be indicated on the main page (at least as one sentence)?! ― Teak 16:37, 31 October 2007 (UTC)

I don't get it.

This website, edits I make on this wiki (translating etc.), what's the point? Will they ever make it to the actual Wikipedia in question? OchAyeTheNoo 21:46, 24 December 2007 (UTC)

The translations/edits will be committed to Subversion. This is done in a revision and when you look at wikipedia:sco:Special:Version you can see "MediaWiki: 1.12alpha (rXXXXX)". The X's is the number of the revision. So when the wiki upgrades to the revision in which your translations are committed, you can use/see those translations. I hope you understand me. SPQRobin 22:06, 24 December 2007 (UTC)

Thanks for that, SPQRobin, it makes much more sense now. OchAyeTheNoo 13:35, 25 December 2007 (UTC)

Did you think maybe that you had to translate for nothing ;-) SPQRobin 17:30, 26 December 2007 (UTC)

po files

Ok I figured out how to export as .po file. How do I import those I translated to the system?? Old fashioned way ship it by e-mail??--Teferra 22:56, 5 January 2008 (UTC)

Yes. Please email it to me. You may be the first to submit one, so we very much appreciate the test case. Please take this to Support next time. Cheers! Siebrand 09:30, 6 January 2008 (UTC)

translating the main page to polish

why can't i correct the translation? After clicking "translate the main page" I dont see anythig to edit. It works with other languages... Ymar 22:03, 24 May 2008 (UTC)

You have to select the correct task – Nike 22:31, 24 May 2008 (UTC)

thanks Ymar 22:34, 24 May 2008 (UTC)

Please sort the language list and make it work !

The language selection list at the top of the main page is completely unusable !

1. I means this selection box written in Wiki syntax as <languageselector /> and that displays this: <languageselector /> and which is supposed to reload the current page using a "?uselang=xxx" query parameter after the current page URL.
2. The list is in completely random order. Please sort it : if you use the language code as the sort key, then display it before the native name, just like in the translation interface.
3. The HTML that it generates is bogous:
   • it generates a <form>...</form> element for which it tries to change the display: CSS style property into inline, but it also generates the selection box within a <p>...</p> which is a block element. So it CANNOT be inline (the paragraph terminates the current inline span. Remove the extra <p>...</p> element that surrounds the <span>...</span> containing : a <select>...</select> element for the selection list and the <input> element. Apparently, you don't understand the HTML and CSS standards !
   • this last <input .../> eelemnt should not be hidden in CSS with display:none and should have the type="submit" property (see below)
4. When selecting a language in it, there's NO OK button to validate and submit the selection. The Javascript there (that is supposed to trap when the selection changes) only works within Internet Explorer. This is also for usability, because you could also return back to the page with the new selection you made, and there will be no way, even in Internet Explorer to say that we want to go again to the same selected language. So Please unhide the submission button (just beside the selection box) to confirm the user selection (you may keep the existing script if it works in IE, but the confirmation button MUST be there !
5. It is also a very bad idea to try to submit immediately a selection when it changes (think about those using a keyboard or other input devices, and not a mouse to scroll the list : your Javascript for IE should be removed as well).
6. So make it generate a simple form similar to the one within Special:Translate (that displays a usable sorted list and includes a separate form submission button). Verdy p 20:04, 11 December 2008 (UTC)

You'll probably be better off using Support for this. Siebrand 20:15, 11 December 2008 (UTC)

No ! This page is appropriate because it discusses about the main page and this is a problem of the main page (the only one that uses this bogous button). In addition the support page is there to discuss about translation issues, versioning, problems with specific languages, ambiguous translations and other problems related to the work to do, but not about the site itself, and not for this main page. Verdy p 20:25, 11 December 2008 (UTC)

One more note: if you really want to use the "?uselang" feature in URLs, make it so that all links generated (as <a href="{{fullurl:pagename}}">text</a> from links written in Wiki syntax as [[pagename|text]] will reinclude this query parameter in the URL, i.e. it should generate the equivalent of <a href="{{fullurl:pagename|uselang=xxx}}">text</a></nowiki> directly, copying the value of the current "uselang=xxx" query parameter in the URL used to display the page. For me, the "?uselang=" feature in MediaWiki does not work as it should, as it requires rewriting all links in all pages using the much more complex syntax <span class="plainlinks">[{{fullurl:pagename|uselang={{USERLANGUAGE}}}} text]</span>. Such complex syntax should never be needed for linking to pages usign the same "uselang" query parameter, and this syntax still has the side effect of hiding broken links as they will still be in light blue and not in red if they point to a missnig or deleted page. Verdy p 20:33, 11 December 2008 (UTC)

Note also that the implicit "guessed" {{USERLANGUAGE}} pseduo-template is broken in MediaWiki: it is supposed to contain the prefered language code of the visitor, using what is parametered in his browser (and sent as "Accept-Language:" MIME header in HTTP); however this parameter is not part of the query (not in the GET URL and not in POST variables), so this "Accept-Language:" is currently ignored by Squid caches (also ignored in the MEdiaWiki internal cache of pages already parsed). In other words, another visitor will come later, with another browser using a different language preference, and will get a copy of the page in the Squid cache, made for the language of the previous visitor before him that visited that page. The problem is in Squid configuration. For this reason, using {{USERLANGUAGE}} should only be used as a last chance option to guess the language desired by the visitor. The only safe option is to make the language code part of the URL (i.e. creating subpages for each language supported). Note that {{USERLANGUAGE}} is correctly set by MediaWiki (and not "guessed") only if the uselang query parameter is explicitly set in the GET URL (one more reason to keep the uselang value in all target URLs generated by normal Wiki article links. It seems to work however here on BetaWiki (where MediaWiki must have been patched, and no squid proxy server is used), but NOT within WMF sites (Wikipedia, Wiktionary, Commons, Meta, ...) that really still need for now a single cache for all visitors languages, and can't store in their caches multiple localized versions of the same page (selected according to visitor's "Accept-Language:" preferences in his browser). Verdy p 20:43, 11 December 2008 (UTC)

First. <languageselector /> is provided by LanguageSelector extension. Use bugzilla for issues with that. Second, this is a wiki, not a programming contest. We are not interested in hacks that try to keep uselang trough links or gazillions of templates to facilitate translation or whatever. Keep it simple, or otherwise our translators can't do their work. They already have a hard time navigating at Betawiki. If something cannot be done simple, don't do it. We will implement proper solutions in the software as needed when we have time. Breaking pages is not acceptable – "Group statistics in time" for example complained about template loops. PS: I'd like to get rid of all the language guessing templates. Users need to set the correct language themselves, we can only give them guess as an first alternative, and even that is not a job of templates. – Nike 22:24, 11 December 2008 (UTC)

Sorry

... ؟ترجمان05 10:05, 18 January 2009 (UTC)أتأسف عن حماية بعض الصّفحات العربية من التّحرير أهذا هو العمل التعاوني المفتوح

Not certain what the apologies are for, but they are accepted. :) Siebrand 10:37, 18 January 2009 (UTC)

language problem

i have problem in translating into urdu. because urdu is written from right to left and the editing box only supports left to right languages.. --محبوب عالم 20:52, 16 February 2009 (UTC)

in the user preferences it is possible to change the direction of Translatewiki.net .. so for this problem there is a solution :) thanks, GerardM 21:21, 16 February 2009 (UTC)

Language selection on Main Page

When are the languages going to be alphabetised? - AnakngAraw 05:50, 1 March 2009 (UTC)

I'm not sure whether that's possible :( --Ooswesthoesbes 08:51, 1 March 2009 (UTC)

Is there bug open in bugzilla: ? It is not developed by us, which means that we are unlikely to fix it. æNike 10:07, 1 March 2009 (UTC)

The extension does not have to changed, just on this wiki the array $wgLanguageSelectorLanguages, see mw:Extension:LanguageSelector#Configuration.--Patrick 10:44, 1 March 2009 (UTC)

$wgLanguageSelectorLanguages: Languages to be offered to the user for selection. If set to NULL (the default), all languages known to MediaWiki (by $wgLanguageNames) are considered. Which is the case we are using. – Nike 11:42, 1 March 2009 (UTC)

I found meta:Language names/codes, that can be used to create the explicit alphabetical list.--Patrick 12:03, 1 March 2009 (UTC)

That list is incomplete, and I'd rather not add more things which need to be updated manually. – Nike 12:37, 1 March 2009 (UTC)

I "plussoie" for this request (means that I want it to change). It is only on this wiki that the language list is not sorted.

On Mediawiki servers, the list of languages is sorted because its displayed labels all start by the language code followed by the name. Sorting the array simply by language code becomes then trivial (and having the language code prefix also allows easier selection, instead of search in a long list, you can just type the letters of the language code).

If this has been done on wikimedia servers (Wikipedia and others) in the user preferences panel, why can't it be corrected here for this <languages/> tag?

It should be really up to you, maintainers of this wiki to contact and urge the developpers to fix this random list, and showing them the example of this wiki should really convinve them to change it (it can be very trivial in PHP, given that the list already knows the language code for each selected item, it just forgets to display it, and forgets to sort the list using this code before generating the HTML code. In PHP, sorting arrays is trivial (just one sort(array) statement to sort on the array's associative index).

Even if you are not the developer of the extension, this will remain a problem for all other MediaWiki servers that will use it. In terms of usability, this list is simply... horrible. Verdy p 16:23, 31 August 2009 (UTC)

We have bugzilla: for that. Thanks. Siebrand 22:14, 31 August 2009 (UTC)