Jump to: navigation, search


move nds

Can please somebody rename everything related to nds translations to nds-de and create nds as a (empty) new locale of its own? Is that possible?

The reason for this is, that nds.Wikisource shall be a shared project used by the communities of nds(-de) and nds-nl. nds.Wikisource will use a new locale in a shared spelling. Therefore nds needs to be renamed to nds-de and the new locale gets the code nds. That means, that the language selection menu in the preferences shall have three entries "nds - Neddersassisch", "nds-de - Plattdüütsch", and "nds-nl - Nedersaksisch" ("Neddersassisch" is a working name for the shared locale, might change in the future). --Slomox:: >< 02:38, 6 February 2009 (UTC)

Are you referring to MediaWiki proper, or only to the translation related aspects? I could do the MediaWiki part of it. Since it needs some coordination, I would suggest to use a branch for it. Unfortunately, I do not know enough on branching the code to just go ahead and start one right now, but I can try to find out or get help. Should I? --Purodha Blissenbach 12:55, 6 February 2009 (UTC)

This sounds like a crap solution for previous crap. I suggest something proper is worked out. Also see Low Saxon language family. If Wikimedia is involved, the language committee should be consulted about eligibility. Siebrand 14:44, 6 February 2009 (UTC)

Wikisource-logo.svg Wikisource is a Wikimedia project Smiley.svg --Purodha Blissenbach 15:22, 6 February 2009 (UTC)
This sounds like a crap solution for previous crap. I suggest something proper is worked out. That's not a helpful comment. The previous arrangement of nds and nds-nl had historical reasons. What I suggested above fixes the flaws of the old situation. ISO/Ethnologue is not helpful in any way, cause it's arbitrary. If you suggest that something proper is worked out, then please tell, what's improper with the solution?
Low Saxon Wikisource is eligible according to the Language Committee. The Committee in its decision has considered the fact, that there are two (three with pdt) variants of Low Saxon.
@Purodha: What do you mean by 'MediaWiki proper'? Do you mean "MessagesNds.php"? This needs to be renamed to "MessagesNds_de.php" and a new "MessagesNds.php" needs to be created. But nds.wikipedia will stay nds.wikipedia for now. But the first step would be to be able to work on the new locale here on Betawiki. --Slomox:: >< 15:13, 6 February 2009 (UTC)

@Slomox: Yes I mean that, and few things around it. I do not know whether or not I can work the needed changes out regarding the Extension:Translate, if any. I've never done something like that, so I don't know. For work to be done at, I believe, I am not having all required rights. --Purodha Blissenbach 15:29, 6 February 2009 (UTC)

So, Siebrand, what would be the correct procedure to create the new locale? --Slomox:: >< 20:11, 6 February 2009 (UTC)
I suggest that the language committee should accept the idea before we implent it.
From my knowledge, I think, moving current nds to nds-DE, then copying it back to nds so as to next amend nds to be more general, would be a good way to go.
If we do that, I have open questions regarding fallback languages:
  • curently, we have:
    nds-NLnlen, and
  • Likely, both nds-NL's and nds-DE's fallback languages should become new nds, which would force us to amend the new ndsen for symmetry reasons. Imho better would be:
    nds-NLndsnlen, and
but that cannot be had without a modification inside MediaWiki. I recomment making that modification, at least as a perspective. I'd volunteer to implement all of that inside MediaWiki. --Purodha Blissenbach 23:00, 19 February 2009 (UTC)
I suggest that the language committee should accept the idea before we implent it Well, langcom declared nds.wikisource eligible and was fully aware that it will be a project inclusive to all variants of nds. That makes it implicitly clear, that they approve the idea of a shared locale. And moving nds to nds-de and newly creating nds is the only meaningful arrangement of codes. And according to their mission statements they are not responsible for anything else than new projects. If anybody wants to ask them, go ahead. But I see no point in asking questions to which the answer is obvious.
nds-NLndsnlen, and
would be the best solution. --Slomox:: >< 18:09, 20 February 2009 (UTC)
I created a bugzilla request: bugzilla:17592 --Slomox:: >< 18:26, 20 February 2009 (UTC)
While I see that, that the langcom is not responsible for making that decision - the nds-ws community is - I'd rather consult with the langcom in order to both broaden consensus and find out, what their standpoin(s) is/are and, whether or not they have an even better proposal to make :-) expecting them to agree.
Nevertheless, I am going to try both of the above amendments
  • moving nds → nds-DE, adding new nds
  • allowing more complicated fallback language paths (bugzilla:17608)
in a test wiki during the next days. --Purodha Blissenbach 23:39, 21 February 2009 (UTC)
@Siebrand, about your comment on the bugzilla entry: nds-nl/nds-de is not "the one and only" possible breakdown of Low Saxon. But it is the one which does the greatest service to the community.
ISO's codes are arbitrary. It divides Dutch Low Saxon into seven codes although they are all easily mutually intelligible. If you think, that dividing at the border is political and not linguistic: well, ISO makes further subdivisions, but all of those subdivisions end at the border too.
I have _never_ heard anybody seriously suggesting tht Sallands is a language of its own. Actually not even ISO does so. ISO language codes are for tagging content in IT applications. It's meaningful to make it possible to have specific tags to tag content as being Sallands, but that doesn't necessarily mean, that Sallands is a _language_. All Low Saxon variants from the IJsselmeer to the Oder and formerly to Lithuania and even Estonia, from Denmark to the Harz, from the Siberian Taiga to the American prairies and to the Pampas are mutually intelligible. And still ISO has ten codes for them. Northern Frisian is a language restricted to a close area, but due to isolation they have developed distinct features that make mutual intelligibility just as hard as with the most distinct Low Saxon varieties. But North Frisian has just one code. Why the difference? The difference is arbitrary. If you like, I can give you a dozen and more examples of inconsequent or wrong or questionable ISO codes.
ISO 639 is just not made to tell whether a language variant qualifies as a language or whether it is worth to create a separate locale. It just provides the codes to use if your personal assessments lead you to the opinion, that the language variant needs distinct tagging. --Slomox:: >< 00:50, 22 February 2009 (UTC)
  • Hoi, I asked the other members of the language committee for an opinion on the tagging. I am not happy with the split of the way this proposed. Currently they are integrating the ISO-639-5, this may provide a benefit. Thanks, GerardM 07:55, 22 February 2009 (UTC)
While I can easily understand various grievances, voicing them is both good and neccesary, but not yet constructive towards a better proposal. I for one seem too dumb or too preoccupied to see one, except giving up orthography diversions altogether, i.e. remerging nds, and nds-NL into nds. But that finally is almost the same as adding a merged/unified version, and keeping the others (only naming them more correctly) So, Siebrand, GeradM, what would be better? Btw., there is nothing said about nds in ISO 639-5. --Purodha Blissenbach 18:54, 23 February 2009 (UTC)

Ct select ("⧼Ct select⧽")

What is $1 in this? – Nike 10:41, 26 December 2008 (UTC)

It is $this->mType and used in a variable called $source_filename. An extension? Siebrand 10:44, 26 December 2008 (UTC)
Should leave this open for some more time to allow further analysis. – Nike 20:05, 4 January 2009 (UTC)
The same parameter is used also in Ct upload ("⧼Ct upload⧽") and one possible value is image and other seems to be attachment. Ct select ("⧼Ct select⧽") contains hardcoded : in the code. So does Ct caption ("⧼Ct caption⧽") and Ct link ("⧼Ct link⧽"). The extension is also a horrible code, and " in translations would probably break it while it tries to add messages to the JavaScript verbatim. As this extension seems to be insecure, I wonder should we even support it. --Nike 08:45, 20 February 2009 (UTC)
Hardcoded colon removed, and added to messages in r47632. Investigating security vulnerabilities now. MinuteElectron 19:20, 21 February 2009 (UTC)
JavaScript security vulnerabilities reported in bugzilla:17600. MinuteElectron 19:29, 21 February 2009 (UTC)


G-description-title ("⧼G-description-title⧽") generally would have to be using {{GENDER:$1|…, since there is a user name represented as $1. In our case, that involves the selection of a grammatical article, and an appropriate reflexivum. For one of our female genders (the one we go with until we have both), and the (only) male gender, each happen to be identically spelt, so (currently) there is no practical need for GENDER. Should it be used anyways, or better not used, or is that arbitrary? Thx. --Purodha Blissenbach 08:45, 11 February 2009 (UTC)

There is always a slight possibility that it is not parsed at all. Other than that, I see no reason either way. --Nike 17:03, 13 February 2009 (UTC)
Added to Translating:Tasks#Messages_needing_GENDER_support. Siebrand 19:13, 24 February 2009 (UTC)

== badsiglength ("Your signature is too long. It must not be more than $1 characters long.") == The original English message for this was amended on 18 February but I don't think that it has been fuzzied yet. Lloffiwr 11:20, 22 February 2009 (UTC)

That was a choice. The change was basically nit picking, and I decided not to fuzzy it. Siebrand 10:38, 23 February 2009 (UTC)
Done Done Fair enough. From the nitpicker:-) Lloffiwr 19:24, 23 February 2009 (UTC)


I think it is better, when "current revision" is replace by the right message, so it is easy to customized the linktext. It can be Currentrev ("Latest revision") or Currentrevisionlink ("Latest revision"), I do not know with message is the right. Thanks. --Der Umherirrende 15:04, 22 February 2009 (UTC)

Not in favour of using int:. Adding a hint to what the quoted text refers to: full support. So I suggest you change the translation hint. Siebrand 10:37, 23 February 2009 (UTC)


May you restore the translation please? --Toliño Fala aquí comigo 18:22, 23 February 2009 (UTC)

Done Done. --Purodha Blissenbach 19:15, 23 February 2009 (UTC)

Messages needing GENDER support, the 2nd

Added to Translating:Tasks#Messages_needing_GENDER_support. Siebrand 19:13, 24 February 2009 (UTC)

Language choice is not persisted among page changes

When in a language portal (i.e., Portal:pt), I click on the Translation Tool link which leads me to Special:Translate. After that, click on a message group to translate, always leads me to the translation for the language set in my preferences instead of preserving the one from whose Portal I came from. Malafaya 18:55, 14 February 2009 (UTC)

You need to change your language setting in 'preferences' to the language you want to translate to, then the 'translation tool' will give you the messages for that language. Lloffiwr 17:27, 15 February 2009 (UTC)
The point was not having to change it... :) The way it is it's misleading because if you don't notice, you will think you're translating another language. Malafaya 19:01, 16 February 2009 (UTC)
OK - so you want to ask whether the wiki software can be changed to allow you to go to the messages in a language via the language portal, without having to change the language setting in preferences? I think that would save time for those of us who work in more than one language. I have no idea whether this is possible but I think that it might be even more confusing than before. As it is now, I know what default language any message will appear in by looking at the interface language on the screen. If I want to view or change a message in a different language without changing the settings I just go to the message in the default language and change the language prefix in the navigation bar. In general I think that it is very easy to be confused between the different pages belonging to each message, whatever the system I use to navigate to a particular language. I have ended up putting a translation onto a qqq page and putting an explanation of a message onto a translation page before now! Lloffiwr 20:52, 17 February 2009 (UTC)
While most usually translating to ksh, I happen to translate, or rather correct obvious errors, in some other languages occasionally. Several times already I forgot to switch back, and accidentally saved my ksh translations in the wrong language. I'd like some more obvious visible hints - e.g. a different background color of edit fields other than in my default language, and/or a big fat langguage code next to the edit window, or something. --Purodha Blissenbach 23:32, 17 February 2009 (UTC)
It makes sense for us who translate more than one language. What I mean is that having a link to the Translation tool in a language portal makes sense if it leads you to the page where you can translate that same language. It is misleading if you click on Translate in, say, Portal:Eo and end up translating (without any other visual cues) your "default" language (Portuguese, in my case). I believe this is a bug. I can see that the parameter language is propagated until the last page before the Translate tool. I believe only one further step (maybe forgotten?) is missing to make it work. I.e., the link should be instead of just (language=eo is already there in that page; it's just a matter of reuse for links) Malafaya 00:30, 18 February 2009 (UTC)
Having the language code written somewhere obvious (added to the Save button perhaps?) would be great. If the link from each language portal to the translation tool went to the corresponding language, I think I would use it, and hope to get used to it:-) Lloffiwr 09:09, 18 February 2009 (UTC)
Tried to implement this a test last night. Found it less easy than expected. Though translatewiki.nets edit page of translateable messages is special, it seems to use MediaWikis normal edit fields and buttons. Altering the "Save" button appears not trivial. Postponed. --Purodha Blissenbach 10:23, 22 February 2009 (UTC)
There are places where extensions can add code. Any opinions which baa1-baa6 would be the best at example page ? --Nike 13:14, 22 February 2009 (UTC)
How about baa4, or baa3, or both? Lloffiwr 23:04, 22 February 2009 (UTC)

I also fixed the original bug, the language=foo parameter is now remember when going from portal pages for example. --Nike 14:20, 22 February 2009 (UTC)

tooltip-rollback (""Rollback" reverts the last contributor's edit(s) to this page in one click")

Can we use {{int:...}} as described in mediawiki talk:tooltip-rollback/en? --Ans 14:01, 20 February 2009 (UTC)

Yes, you can use int:. Siebrand 15:52, 20 February 2009 (UTC)
Well, I've just suggested you to use {{int:...}} in the original en message, as described in that talk page. How do you think about this? --Ans 04:40, 23 February 2009 (UTC)
I am not in favour of doing this. Noting in the translation hints that it is possible to use it should suffice, in my opinion. Siebrand 07:27, 23 February 2009 (UTC)


Recently, MetavidWiki messages have disappeared from here. What happened? --fryed-peach 17:49, 23 February 2009 (UTC)

The MetavidWiki developer introduced new messages which conflict with existing message from the OggHandler extension. I have deactived the translation of MetavidWiki as emergency measures in mwr:47585. Yesterday a new version with corrected message keys were committed and after cleanup we will enable it again. Raymond 07:38, 24 February 2009 (UTC)
Thank you for your answer. --fryed-peach 01:14, 25 February 2009 (UTC)

Shared-repo-from ("from $1")

This message should be fixed due to linguistic problem. It will be printed in English.

  • File:abc.jpg from Wikimedia Commons

In Korean, It should be:

  • Wikimedia Commons의 File:abc.jpg

Please fix this problem. Thanks.--Kwj2772 03:06, 24 February 2009 (UTC)

I will use bracket rather software change.--Kwj2772 10:11, 28 February 2009 (UTC)

What to do about errors you cannot correct?

Hi, I spotted a Norwegian translation (in both no: and nn:) which I thought was incorrect. I understand Norwegian, but I cannot use it actively, so I am unable to correct the errors. I was in doubt if I should leave a message at the translations' talk pages, or invalidate them by marking them fuzzy. I ended up doing the latter to better get the attention the Norwegian translators ([1], [2]). Was that the right thing to do, or was another action better? Byrial 16:17, 24 February 2009 (UTC)

Add "!!FUZZY!!" in front of the translate message (exactly as put here), and leave a message on the talk page (or in the edit summary). Siebrand 19:06, 24 February 2009 (UTC)

Wrong use of bold text in MediaWiki:Readonlywarning?

Hi, I am puzzled about the English text for this message. It uses wiki markup for bold text ('''bold''') that spans more than one line. That does not work and the bold text stops at the end of the first line. Shouldn't that be corrected? Byrial 00:37, 25 February 2009 (UTC)

Done Done, together with some more like this one, in mwr:47797. --Purodha Blissenbach 10:54, 25 February 2009 (UTC)


Where is the place, in which this message is used? And what does it mean? --Ans 06:51, 25 February 2009 (UTC)

This is used when moving a page, and indicates whether the page you are moving from should be made a redirect or deleted. MinuteElectron 15:45, 25 February 2009 (UTC)
Thank you. --Ans 05:04, 2 March 2009 (UTC)


I think Openid-prefsTemplate:Msg/wrong parameter should be optional. --fryed-peach 13:39, 25 February 2009 (UTC)

Done Done in mwr:47805. Raymond 08:44, 26 February 2009 (UTC)

Alphabetical sorting

The alphabetical sorting done by MediaWiki (in categories, All pages listing, etc) is done in an incorrect way at least for the Portuguese language.

  1. MediaWiki firsts lists all pages starting with a capital letter (A-Z) and afterwards pages starting with a-z. The Portuguese language don't distinguish it (A=a, B=b, C=c [...]);
  2. Accentuated letters (Á á É é Í í Ó ó Ú ú À à È è Ì ì Ò ò Ù ù Â â Ê ê Î î Ô ô Û û Ã ã Ô õ Ä ä Ë ë Ï ï Ö ö Ü ü Ç ç) are displayed at the end of the sorting list. The Portuguese language don't distinguish it (A=a=Á=á=À=à=Â=â=Ã=ã, C=c=Ç=ç [...]);

Is possible to set the alphabetical sorting by language? 555 21:26, 25 February 2009 (UTC)

I do not believe this is possible, IIRC sort order is determined by MySQL collation which is a per-wiki "setting" (although it cannot really be changed from the default UTF-8 or latin1). MinuteElectron 21:52, 25 February 2009 (UTC)

MediaWiki uses a sort order that (afaics) exactly no language / script of the world is using. :-) So you can say that all languages are treated equally bad. Already bug 164 (of currently 17666!) asks for a better solution. Several others do, too. Voting for them may be a good idea. Commenting them so as to keep the issue on the mailing list would be another stragety.

Until we have a better solution, we can resort to {{defaultsort:}} inside pages. --Purodha Blissenbach 22:43, 25 February 2009 (UTC)

Translated el messages with <br /> in them

(Continuity: Support/Archive/2009/2#New_line_in_definitions.27_text)

↑ Thanks for the help back then.

I tried out to find the aforementioned messages using the search form, but this way wielded no results. I recognize this maybe is hard because <br /> is code, not plain text. Could someone please propose a way to find the messages? --Dead3y3 00:45, 27 February 2009 (UTC)

Try for example this page and browser search 08:17, 27 February 2009 (UTC)

Quickly extracting message names from the source file yields:

cd phase3/languages/messages
awk '{if ($0~/^\047/) {print a; a=$0} if ($0~/;$/) {print (a $0); a=""} else a=(a $0)}' MessagesEl.php | grep "<br" | cut -d " " -f 1

Use with care, this may be an incomplete list, or hold false positives. When I saw that a simple grep "<br" found 50% lines being continuation lines without message names, I 'quick-and-dirty'-ly used awk to concatenate 2nd, 3rd, etc. lines of messages to their 1st (ignoring what happened to comment lines and other lines not defining messages), grep to filter those that now had <br inside, and cut to extract the 1st column before a blank from the result. Enjoy! --Purodha Blissenbach 08:36, 27 February 2009 (UTC)

Btw. \047 is another way to write ' inside regular expressions. I had to use this because the entire awk program was already contained in ''s. --Purodha Blissenbach 08:42, 27 February 2009 (UTC)

This is for MediaWiki only. If you put <br />s into extension messages as well, they are not as easily found. --Purodha Blissenbach 08:47, 27 February 2009 (UTC)

Here is the list as links: tog-editsectiononrightclick ("Enable section editing by right clicking on section titles") tog-showtoc ("⧼tog-showtoc⧽") noconnect ("⧼noconnect⧽") laggedslavemode ("Warning: Page may not contain recent updates.") wrong_wfQuery_params ("⧼wrong_wfQuery_params⧽") nonunicodebrowser ("Warning: Your browser is not Unicode compliant. A workaround is in place to allow you to safely edit pages: Non-ASCII characters will appear in the edit box as hexadecimal codes.") editingold ("Warning: You are editing an out-of-date revision of this page. If you save it, any changes made since this revision will be lost.") copyrightwarning ("Please note that all contributions to are considered to be released under the $2 (see $1 for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!") copyrightwarning2 ("Please note that all contributions to may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see $1 for details). Do not submit copyrighted work without permission!") longpagewarning ("⧼longpagewarning⧽") protectedpagewarning ("Warning: This page has been protected so that only users with administrator privileges can edit it. The latest log entry is provided below for reference:") histlegend ("Diff selection: Mark the radio boxes of the revisions to compare and hit enter or the button at the bottom.
Legend: (cur) = difference with latest revision, (prev) = difference with preceding revision, m = minor edit.") noexactmatch ("⧼noexactmatch⧽") rclinks ("Show last $1 changes in last $2 days
$3") fileexists-extension ("A file with a similar name exists: thumb

  • Name of the uploading file: $1
  • Name of the existing file: $2

Do you perhaps want to use a more distinctive name?") fileexists-thumbnail-yes ("The file seems to be an image of reduced size (thumbnail). thumb Please check the file $1. If the checked file is the same image of original size it is not necessary to upload an extra thumbnail.") disambiguations-text ("⧼disambiguations-text⧽") linksearch-text ("Wildcards such as "*" may be used. Needs at least a top-level domain, for example "*.org".
Supported protocols: $1 (defaults to http:// if no protocol is specified).") enotif_body ("Dear $WATCHINGUSERNAME,



Contact the editor: mail: $PAGEEDITOR_EMAIL wiki: $PAGEEDITOR_WIKI

There will be no other notifications in case of further activity unless you visit this page while logged in. You could also reset the notification flags for all your watched pages on your watchlist.

Your friendly notification system

-- To change your email notification settings, visit

To change your watchlist settings, visit

To delete the page from your watchlist, visit $UNWATCHURL

Feedback and further assistance: $HELPPAGE") historywarning ("Warning: The page you are about to delete has a history with $1 revisions:") blockipsuccesstext ("$1 has been blocked.
See the block list to review blocks.") blocklogtext ("This is a log of user blocking and unblocking actions. Automatically blocked IP addresses are not listed. See the block list for the list of currently operational bans and blocks.") lockdbsuccesstext ("The database has been locked.
Remember to remove the lock after your maintenance is complete.") trackbackbox ("⧼trackbackbox⧽") fileduplicatesearch-info ("$1 × $2 pixel
File size: $3
MIME type: $4") --Purodha Blissenbach 08:53, 27 February 2009 (UTC)

Done Done Thanks all very much! Marking as done, for archiving. --Dead3y3 01:08, 28 February 2009 (UTC)

Cite messages

It seems some translated messages of the Cite extension haven't been commited. For example, Cite error refs without references ("⧼Cite error refs without references⧽") for Esperanto, though translated since 4th January, is still not present in the Cite.i18n.php file. I recall someone else claiming this same problem for another language (ksh?) earlier on. I would recommend forcing a commit for all the messages in this extension. Thanks, Malafaya 12:23, 27 February 2009 (UTC)

Done Done with mwr:47903. Reason why these messages were skipped is unclear. Raymond 09:34, 1 March 2009 (UTC)

Configure-setting-wgAPIPropModules ("⧼Configure-setting-wgAPIPropModules⧽")

What is 'prop'? --Harald Khan Ճ 09:00, 28 February 2009 (UTC)

prop is a parameter to the API. It takes a list of subparameters. Likely the prop module is the software module, or subprogram, that handles this parameter prop, and its subparameter list. Extensions of the prop module are likely things added to the list of permissible values in the parameter list under special circumstances, or special choices taken away from the list of permissible values, etc.. Such "special circumstances" could e.g. exist, when a specific MediaWiki Extension is installed, or specific setting have been made in the installation. --Purodha Blissenbach 11:49, 28 February 2009 (UTC)
Ok, thanks. --Harald Khan Ճ 13:59, 28 February 2009 (UTC)


Centralauth-log-entry-chgstatus ("⧼Centralauth-log-entry-chgstatus⧽") lacks closing ". --fryed-peach 05:12, 3 March 2009 (UTC)

Done Done Revision 47970 --Purodha Blissenbach 10:26, 3 March 2009 (UTC)

leaving obsolete message undeleted, but marked as obsolete

All obsolete message like, Sp-translate-data-SkinNamesTemplate:Msg/wrong parameter, should not be deleted, to leave the historical information in public view. The FUZZY marking the message as obsolete can be used. --Ans 06:50, 3 March 2009 (UTC)

request undelete

Could you please undelete all deleted revision of the pages,

I want to investigate the historical contents of these pages. --Ans 07:55, 3 March 2009 (UTC)

Done Done. The two messages have longer histories now. I moved the template to User:Ans/Template:Identical/E-mail password precautiously. The deleted template is being referred to from elsewhere, I did not investigate more than this plain fact. In order not to accidentally break anything, I moved it away after restoring it, and deleted the redirect. --Purodha Blissenbach 10:17, 3 March 2009 (UTC)

Centralauth-admin-blocked ("⧼Centralauth-admin-blocked⧽")

What is $1 in Centralauth-admin-blocked ("⧼Centralauth-admin-blocked⧽")? If it is a duration, it does not say much. If it is a date and time of expiry, it needs to have date and time separated for proper translation. --Purodha Blissenbach 10:01, 3 March 2009 (UTC)

$1 is a date/time. Siebrand 08:55, 5 March 2009 (UTC)
Done Done Updated in mwr:48047. Siebrand 09:05, 5 March 2009 (UTC)

Centralauth-log-entry-chgstatus ("⧼Centralauth-log-entry-chgstatus⧽")

A quotation mark is missing. --Metalhead 11:05, 3 March 2009 (UTC)

Done Done Revision 47970 --Purodha Blissenbach 10:26, 3 March 2009 (UTC)

Diff-styleadded ("⧼Diff-styleadded⧽"), Diff-styleremoved ("⧼Diff-styleremoved⧽"), Diff-removed ("⧼Diff-removed⧽")

What are $1 in these messages, and what kind of styles are the first two talking about? Byrial 11:05, 3 March 2009 (UTC)

Styles are CSS data, such as in <span style="color:red">… , and the $1s are copies of added or removed pieces, afaicr. --Purodha Blissenbach 11:44, 3 March 2009 (UTC)
Hmm, I would really like to see a page where they are used. Any idea where that is? Until then I will have to guess a little bit. Byrial 23:53, 3 March 2009 (UTC)
Go to a history list in {{SITENAME]], start a comparison of the new type, via the rightmost button (in ltr mode) such as

If there were styles added or removed, you had either of these messages, I seem to believe. I do not know of a page like this. Maybe, you make one youself? --Purodha Blissenbach 02:24, 4 March 2009 (UTC)

Wrong English name of language

Hi there, all over TranslateWiki the English name for the Cornish language seems to be set wrong, it is currently coming up as "kernewek". See Portal:Kw and other places. Could this be changed to "Cornish" please? Many thanks --Kw-Moon 22:10, 3 March 2009 (UTC)

The behaviour on Portal:Kw is as expected, can you provide an alternaitve example? MinuteElectron 22:39, 3 March 2009 (UTC)
Sure, on Translating:Languages, notice that all the headings have the name of the language in both English and its native equivalent. E.g. German – Deutsch, Greek – Ελληνικά, Spanish – Español... but when it gets to Cornish's entry on the list (kw), the heading is kernewek – Kernewek, when it should be Cornish – Kernewek. I think it is some kind of global setting. Thanks, --Kw-Moon 22:47, 3 March 2009 (UTC)
No, on Translating:Languages the languages names are not shown in English but in the actual interface language besides the native names. If your interface language is Cornish, but the language names (except for Cornish itself) are not yet translated to Cornish, you will see the English names as fall back. That can explain what you are seeing. Byrial 23:48, 3 March 2009 (UTC)
Ah, my mistake, thanks for clearing that up. Could you point me to where I can translate the language names? I've searched through the entire translation tool and used the search box but couldn't find where to go. Many thanks, --Kw-Moon 11:57, 4 March 2009 (UTC)
We use the translations from CLDR. See Todo item 1 for more info. Siebrand 08:31, 5 March 2009 (UTC)

Deletion from svn

Please delete the Japanese (ja) translation for cite_references_link_many_format_backlink_labels from svn. It should use the default (same as English). --fryed-peach 02:45, 4 March 2009 (UTC)

Done Done Revision 48018. --Purodha Blissenbach 10:59, 4 March 2009 (UTC)
Thank you! --fryed-peach 13:45, 4 March 2009 (UTC)

Centralauth-admin-blocked ("⧼Centralauth-admin-blocked⧽")

Which format $1 has? "March 4, 2008, 23:18" or "1 day"? —Preceding unsigned comment added by Kwj2772 (talkcontributions)

see also above. --Purodha Blissenbach 08:46, 5 March 2009 (UTC)
Done Done Siebrand 09:10, 5 March 2009 (UTC)

Project Honeypot

If "Project Honeypot" means this, it would be better to change its spelling to "Project Honey Pot". --fryed-peach 07:51, 5 March 2009 (UTC)

Done Done Siebrand 08:24, 5 March 2009 (UTC)

Review_has_been_stored ("⧼Review_has_been_stored⧽")

Is span required or may be moved out of message? --EugeneZelenko 15:24, 5 March 2009 (UTC)

Typically something that can be moved to the code. Siebrand 16:01, 5 March 2009 (UTC)
Moved Moved with revision 48072. --Purodha Blissenbach 00:00, 6 March 2009 (UTC)

tooltip-rollback (""Rollback" reverts the last contributor's edit(s) to this page in one click")

Can we use {{int:...}} as described in mediawiki talk:tooltip-rollback/en? --Ans 14:01, 20 February 2009 (UTC)

Yes, you can use int:. Siebrand 15:52, 20 February 2009 (UTC)
Well, I've just suggested you to use {{int:...}} in the original en message, as described in that talk page. How do you think about this? --Ans 04:40, 23 February 2009 (UTC)
I am not in favour of doing this. Noting in the translation hints that it is possible to use it should suffice, in my opinion. Siebrand 07:27, 23 February 2009 (UTC)
Using "{{int:Rollback short}}" will make the tooltip message to be consistent with the UI on which the tooltip is describing. --Ans 05:12, 2 March 2009 (UTC)
Yes, I know what you are suggesting. Siebrand 08:16, 2 March 2009 (UTC)
Then, what is the reason why it should not be used in en? --Ans 03:53, 3 March 2009 (UTC)
The reason is that this may unknowingly push translators to stick to the English source message, or make awkward translations, even though they can for example use a correct grammar form by not using the int:. Siebrand 09:04, 5 March 2009 (UTC)
I tend to use other messages verbatim with int in cases when it would be imho helpful to users recognizing them (from) elsewhere, in settings such as:
  • Do …, then klick the „{{int:xyzzy}}“ button.
  • … find more in the „[[{{#special:xyzzy}}|{{int:xyzzy-log-name}}]]“.
etc. Among others, I want to be on the safe side in case one of the used messages is changed. Of course, that requires, that my language allows simple and normal grammatical constructs to include multiword expressons verbatim, no matter what their internal structure is. For us it's usually easily done by quoting them. --Purodha Blissenbach 11:50, 5 March 2009 (UTC)

Wrong link + anchor text, on Special:WhatLinksHere

In the page Special:WhatLinksHere/Project_list/translations/1-languages_Main_Page_Betawiki/ksh, there is link in small print just under the page title, having an anchor test bewilderingly different from its real link target. The main problem being imho: either of them is wrong ;-) I believe, this is a bugzilla item, but I am not 100% sure. Just say "yes", and I shall report the issue there :-) --Purodha Blissenbach 13:02, 1 March 2009 (UTC)

I do not see a problem. Please provide all details, including the skin you are using, and the 'link text', and 'link target' you are referring to. I checked in both Modern (tw.n's default skin) and MonoBook, and I see nothing bewildeirng or incorrect. Siebrand 13:13, 1 March 2009 (UTC)
I've tried a handful of skin now. They're all the same regarding this strange link. (Cologneblue has "<!-- -->" in it upper left corner but that's always there)
The link title also shows "Project list/translations/1-languages Main Page Betawiki/ksh" everywhere, which is the anchor text, too, but it does not link there. The page it does link to, behaves similarly, etc.. --Purodha Blissenbach 18:08, 1 March 2009 (UTC)
Works for me. Siebrand 18:26, 1 March 2009 (UTC)

Message no longer required

I came across this message : MediaWiki:Renameuserlog, which has been deleted. May we safely delete the remaining translations of this message as well? PieRRoMaN 12:53, 1 March 2009 (UTC)

Do not delete pages. They may be used in earlier versions, and they are not in the way. Aside from that, it takes up your time which in my opinion is better spent translating. Siebrand 13:08, 1 March 2009 (UTC)

Deleted message: Imagelist-summary

This message was deleted. It should be removed from translation list. --Joseph 17:19, 28 February 2009 (UTC)

Are you sure that, it was already deleted before version 1.13 started? --Purodha Blissenbach 17:52, 28 February 2009 (UTC)
I can still see 1 message untranslated in Special:LanguageStats/tr for 1.13. The only message is MediaWiki:Imagelist-summary/tr. So, I think that, if the original message was deleted, then it shouldn't be listed as untranslated.--Joseph 19:44, 28 February 2009 (UTC)
That message is not used in the latest version of MediaWiki, but it may be used in older versions. --fryed-peach 18:13, 5 March 2009 (UTC)

Siteuser (" user $1")

Where does this message appear? Should it be capitalised at the beginning? Lloffiwr 15:27, 28 February 2009 (UTC)

It is used in Credits::getContributors(), which is called from Credits::getCredits() (and some extensions), which is used in Skin::pageStats(), which is used in the skins Nostalgia, CologneBlue and Standard. Now I just have to find a URL that will actually call and display :). Siebrand 09:13, 5 March 2009 (UTC)
It is only used if $wgMaxCredits has been changed in the local configuration (when not equal to 0). For demo purposes I have set this value to 3. Continuing my investigation... Siebrand 09:21, 5 March 2009 (UTC)
Set the value to '6' to be able to get a better idea of what is happening. You can add "&action=credits" (example) to page URLs now to see this message. It looks like the whole credits feature is a bit buggy at the moment and needs to be fixed a bit. Siebrand 09:27, 5 March 2009 (UTC)
Ah, right! The first 3 credited users have given a 'real name' in their prefences, and consequently are mentioned by name, the other 3 users have not given a real name, and are mentioned by user name. Nice feature :) Siebrand 09:30, 5 March 2009 (UTC)
Done Done. Have added explanations to relevant messages. Thank you for digging into this. Lloffiwr 17:51, 7 March 2009 (UTC)

Username in block-related intro texts

Texts on top of the various blocking-related pages (blocklogtext ("This is a log of user blocking and unblocking actions. Automatically blocked IP addresses are not listed. See the block list for the list of currently operational bans and blocks."), ipblocklist-summary ("⧼ipblocklist-summary⧽"), globalblocking-logpagetext ("⧼globalblocking-logpagetext⧽"), globalblocking-list-intro ("⧼globalblocking-list-intro⧽")) are typically used to refer to each other; when an admin checks active blocks for a user, he is likely to also check block log, global block log, external cross-wiki block status etc. Having to enter the user's name manually each time is annoying; it would be nice to get the user name in a parameter so it can be included in the links. (Note that log pages use User:XXX while the others use XXX; the namespace part should be stripped away.) --Tgr 11:39, 23 February 2009 (UTC)

This is a feature request that has nothing to do with i18n/L10n. Please report it in bugzilla:. In case there *is* an i18n/L10n component in the above, please separate it from the functional elements. Siebrand 11:46, 23 February 2009 (UTC)

Experimental code in message handling

We are testing code which makes wfMsg to do the right thing (tm). Please report any possible weirdness and bugs. – Nike 14:43, 22 February 2009 (UTC)

No weirdness, I guess... Siebrand 00:07, 6 March 2009 (UTC)

imageList.loading ("Commonist:ImageList.loading/en-gb") and imageList.loaded ("Commonist:ImageList.loaded/en-gb")

I think image should be replaced with file in these messages for same reason as bugzilla:44. --EugeneZelenko 16:28, 18 January 2009 (UTC)

Should be relayed to the Commonist developer. Nike is developer contact here. Siebrand 09:58, 18 February 2009 (UTC)
hi! as long as the commonist is as image-centered as it is, i don't think it's worth the effort, but in principle i could make the necessary changes in about 5 minutes. -- 23:26, 5 March 2009 (UTC)

Globalblocking-modify-logentry ("⧼Globalblocking-modify-logentry⧽") and Globalblocking-block2-logentry ("⧼Globalblocking-block2-logentry⧽")

It would be nice to know what $1 in Globalblocking-modify-logentry ("⧼Globalblocking-modify-logentry⧽") and Globalblocking-block2-logentry ("⧼Globalblocking-block2-logentry⧽") precisely are. Since they are linked locally — it appears in [[]] in the message — they have to be a wikipage or a special page. --Purodha Blissenbach 11:11, 5 March 2009 (UTC)

$1 is a link to a user page (Title::makeTitleSafe( NS_USER, $address )), $2 is a reason for the action. Siebrand 09:33, 6 March 2009 (UTC)
Hopefully, GENDER can take a "User:" namespace prefix. I'll check that. --Purodha Blissenbach 11:03, 7 March 2009 (UTC)
AFAIK it doesn't. – Nike 12:53, 7 March 2009 (UTC)
It doesn't, indeed. I'm going to suggest to change that, its unproblematic. Also, I've seen another possible enhancement which I shall suggest, too. --Purodha Blissenbach 17:50, 7 March 2009 (UTC)
Sorry, the intended stripping cannot be safely done :-(
Reason: You cannot create a new user having a name "user:name" (and thus a user page at "user:user:name"), likewise you cannot create users having aliased namespacenames in their names. But there is a loophole. You can create user names with colons inside, and you can add/alter namespacenames, or aliases, such that user names become unavailable for creation. Yet existing such user names remain valid and operable, and can be used for logging in. That means, it would be too dangerous to strip "user:" namespacesnames or aliases inside GENDER, because one cannot know for sure not to be dealing with a legacy username without a prefix.
Consequentially, I suggest to amend the code using these messagew to pass a sheer user name in $1, moving the namespace prefix from code into the message. --Purodha Blissenbach 12:22, 18 March 2009 (UTC)

shareduploadwiki-linktext ("⧼shareduploadwiki-linktext⧽") is used in different ways

Hi. MediaWiki:Shareduploadwiki-linktext/qqq is used as $1 in both MediaWiki:Shareduploadwiki-desc/qqq ("The description on its $1 there is shown below.") and MediaWiki:Shareduploadwiki/qqq ("Please see the $1 for further information.").

That's make the translation of these 3 texts difficult as the linktext is used in different grammatical contexts.Byrial 13:07, 26 February 2009 (UTC)

BTW. Never do such a thing like "the $1". It generally cannot be translated as the "the" will cause changes to the following word(s) in many languages including Danish which I am translating to. Byrial 13:24, 26 February 2009 (UTC)
Yeah we know, the developers don't always :) – Nike 17:29, 18 March 2009 (UTC)
Done Done Fixed in r48951. – Nike 08:23, 28 March 2009 (UTC)


Hoi, Mark Williamson is busy converting the Gothic localisation into the Gothic script. He asked me if he can do this at I think this should be ok. Thanks, GerardM 19:55, 11 March 2009 (UTC)

Done Done Made it possible again to work on 'got'. Review. Siebrand 11:45, 15 March 2009 (UTC)


Is link tag necessary in this message or may be moved out? --EugeneZelenko 14:15, 12 March 2009 (UTC)

Imho could be moved out safely. – Nike 14:07, 13 March 2009 (UTC)
Done Done mwr:48386 --Purodha Blissenbach 19:33, 13 March 2009 (UTC)
(After import) – Nike 19:50, 13 March 2009 (UTC)

problematic messages in MediaWiki 1.12

I have looked at these problematic messages and am not sure whether possibly some or all of them are 'false positives', not just the capitalised special page names. Some of the translations appear to be messages that were changed after being FUZZIED, but the English messages appear to be the original versions before being changed (this appears also in other languages like French, for example). Does this matter? Lloffiwr 22:35, 16 March 2009 (UTC)

  • I believe, when a message wasn't really changed, you can simply unfuzzy it. Maybe the change was pure cosmetic. --Purodha Blissenbach 08:31, 17 March 2009 (UTC)
Sorry, I didn't explain myself very well at all above. Have changed the question above. An example is the message Mw-core-1.12-emailauthenticatedTemplate:Msg/wrong parameter where the english message has the old date/time variable and (some of) the translations have the new separate date and time variables. So should we be changing the message back to the old system? Lloffiwr 10:45, 17 March 2009 (UTC)
I assume MediaWiki 1.12 doesn't support the new variables. This is why we have separate messages for various versions. --fryed-peach 12:10, 17 March 2009 (UTC)
Done Done Thank you for the explanation. Have started removing (unsupported) syntax but tried to leave special page names capitalised. Lloffiwr 10:24, 21 March 2009 (UTC)

Big exporter

What is "Big exporter" in the context of Group-bigexport ("⧼Group-bigexport⧽"). --fryed-peach 12:36, 17 March 2009 (UTC)

Likely, this is the new option to include five levels of linked pages in Special:Export. (Some gods may know why it has a hardcoded limit of five) --Purodha Blissenbach 12:42, 18 March 2009 (UTC)

Problematic Italian messages

There are some false positives in errors. First, see problematic messages on Blahtex extension. It says that there is one unbalanced brace, but that's deliberate! We need some escaping, I think. Second: see MediaWiki:Abusefilter-reautoconfirm-none/it. We don't need GENDER support there. Can you drop it please? Thanks in advance, --Pietrodn 10:13, 18 March 2009 (UTC)

The current system has some limitations that hardly warrant the amount of work to iron them out at the moment.
If you really do want to avoid the bogus errors, you can try <!-- } --> in the message, or try using &#123; for the brace. Not recommended! I don't know whether or not they work when the message is used at runtime, so please do check that. The message showing as intended here in is not enough! --Purodha Blissenbach 12:53, 18 March 2009 (UTC)
As to GENDER — if you don't need it, simply don't use it. If you want to avoid the bogus error, use GENDER with all forms equal, or only 1 form, both is acceptable. If you did not need GENDER in general, checks could be disabled (but I know enough Italian to know that, generally, you need GENDER) -- greetings --Purodha Blissenbach 12:57, 18 March 2009 (UTC)

Newusernotifbody and Newusernotifsubj

I think SITENAME should be used instead of parameters in these messages. --EugeneZelenko 14:27, 18 March 2009 (UTC)

Imho, {{SITENAME}} should never be used hardwired, and best not be used at all in generic messages, so as to reduce the number of message texts, which any new installation has to review each time when setting up a new wiki. You could leave $3 unused and take {{SITENAME}} instead. It has to be a parameter of some sort, because it may be needing {{GRAMMAR}}. --Purodha Blissenbach 17:51, 18 March 2009 (UTC)
I think using GRAMMAR with SITENAME is better way of doing things then arbitrary parameter. --EugeneZelenko 14:06, 19 March 2009 (UTC)
I agree, because that makes it easier for new installations to find this part of the messages that need checking and possible amending. (You can grep for "SITENAME" and thus find the message names. My suggestion was to provide a list of links to those message on a "hints" page or section of the kind "What to do when your wiki has just been installed" in addition to a link to the manual (where such a list cannot be provided, because it cannot link to an arbitrary wiki). My proposition on bugzilla was turned down. :-( Reason: "We do not want that"
See also MediaWiki:Mainpagedocfooter/qqq. – Nike 17:16, 20 March 2009 (UTC)

Ternery operator

Is "Ternery operator" in Abusefilter-edit-builder-misc-tern ("⧼Abusefilter-edit-builder-misc-tern⧽") a typo for "Ternary operator"? --fryed-peach 07:35, 19 March 2009 (UTC)

I assumed it so. --Purodha Blissenbach 09:32, 20 March 2009 (UTC)
Done Done Siebrand 16:14, 29 March 2009 (UTC)

Monobook question: Hide extensions from Special:Translate/Wikimedia Extensions

Is it possible to hide individual extensions via own monobook.css? --Metalhead 17:32, 19 March 2009 (UTC)

No. There are no class definitions for extension entries. Low prio feature request added to list. Siebrand 19:01, 28 March 2009 (UTC)

How to look for translations containing certain characters

I have made mistakes in some of my previous translations because my newly installed linux has bug in displaying some Lao characters. ໜ and ໝ need to be substituted by one anothers in my recent translations. Is there any easy way to find my translations containing these characters? Thank you. Tuinui 02:11, 20 March 2009 (UTC)

Use the review function for message groups. You can display up to 2500 message translations on a page. Then use your browser's search to find messages containing them. Alternatively export to gettext, edit offline and send in the resulting .po file. Siebrand 19:03, 28 March 2009 (UTC)

Abusefilter-edit-builder-funcs-ip in range

Abusefilter-edit-builder-funcs-ip in range ("⧼Abusefilter-edit-builder-funcs-ip in range⧽") mentions an IP range. Which range? Does not translate without a reference. --Purodha Blissenbach 09:31, 20 March 2009 (UTC)

It's a function for a programming language – the IP range is specified as an argument to that function. Werdna 01:26, 27 March 2009 (UTC)


The description of abusefilter-edit-builder-misc-cond ("⧼abusefilter-edit-builder-misc-cond⧽") says: Don't change "(if X then Y else Z)". — Is it really not allowed to translate the words "if", "then", "else"? --Purodha Blissenbach 10:02, 20 March 2009 (UTC)

Yes, that is a type of conditional constructs in programming languages. You can test it at test wiki. --fryed-peach 18:02, 20 March 2009 (UTC)
Ok. Ok. Thanks. --Purodha Blissenbach 02:46, 21 March 2009 (UTC)

FlaggedRevs not a „MediaWiki extensions used by Wikimedia“?

It is right, that the Extension „FlaggedRevs“ is not a „MediaWiki extensions used by Wikimedia“? FlaggedRevs is used on many Wikis from WMF, so it should list there. Der Umherirrende 09:49, 21 March 2009 (UTC)

It's so big. – Nike 12:58, 21 March 2009 (UTC)
And what is the problem? FlaggedRevs has only 305 message. All message by now: 1493. So the FlaggedRevs are 20 %. I see no problem. But it is only my opinion. Der Umherirrende 00:06, 22 March 2009 (UTC)
The wording of part of the messages is highly problematic, as is their technicality (e.g. messages combined from other messages, with quite some level of indirections and variability) which makes them in part very hard to translate grammarwise, leave alone subtle meanings of some rather obscure words. I believe many message are impossible to translate without some community discussions and consensus on the words to be used for some of the classifications, etc., and their pecise ramifications, and their exact handling. This precludes a not so small percentage of message from having sensitive translations before the extension is being used, and can be seen and discussed in the life of a wiki commnity. I was able to translate some 60 of about 300 messages rightaway (such as "Go" buttons, etc.) and unable to do the rest, because:
  • I cound not determine a meaning (50% or more)
  • I cound not understand usage (i.e. message nesting, some 20%)
  • A translation would have to have problems inside other message solved first (some 40% or more)
As you see, problems overlap. Since the extension is not used in most wikis/languages, it does not make sense to invest lots of labour in it for the languages concened. Yet LangCom has the requirement of having a certain percentage of messages of all extensions used on wmf wikis translated, which puts the languages/wikis at unequal stands, depending on FlaggedRevs usage. That is one of the mativations of counting FlaggedRevs extra. --Purodha Blissenbach 02:59, 22 March 2009 (UTC)

exif-subsectime ("DateTime subseconds")/exif-subsectimedigitized ("DateTimeDigitised subseconds")/exif-subsectimeoriginal ("DateTimeOriginal subseconds")

Having problems understanding these messages. Have found an example of each of them in the metadata of this picture from Commons. None of the translations I can read make sense to me, although the German translation has '1/100 s' for 'subseconds'. In the example the data is '40' for each of them, which seems to me to perhaps be the time (40 subseconds) the camera took to do a particular task. Anybody know enough about digital cameras to tell whether this is right? Or perhaps it's the accuracy of the times entered elsewhere on the metadata? I understand from Wikipedia that 'DateTime' is a computer time format, so if nobody understands this information then I will just not translate 'DateTime'. I am certainly learning an awful lot of very obscure things whilst translating these messages! Lloffiwr 19:46, 21 March 2009 (UTC)

Best try to find an EXIF specification and look it up there. Then add it to the message documentation here... Siebrand 10:40, 28 March 2009 (UTC)
Google is your friend:
  • SubsecTimeOriginal: A tag used to record fractions of seconds for the DateTimeOriginal tag
  • SubsecTimeDigitized: A tag used to record fractions of seconds for the DateTimeDigitized tag
  • SubsecTimeOriginal: A tag used to record fractions of seconds for the DateTimeOriginal tag[3]
Oh, and please do not substitute msg-mw. Siebrand 10:44, 28 March 2009 (UTC)

Rev-deleted-unhide-diff, Rev-deleted-text-view

There are unnecessary references to {{SITENAME}} in Rev-deleted-unhide-diff ("One of the revisions of this diff has been deleted. Details can be found in the deletion log. You can still [$1 view this diff] if you wish to proceed."), and Rev-deleted-text-view ("This page revision has been deleted. You can view it; details can be found in the deletion log."). --Purodha Blissenbach 21:09, 22 March 2009 (UTC)

Not anymore :) Siebrand 20:00, 23 March 2009 (UTC)
Tx! Tx! --Purodha Blissenbach 10:43, 24 March 2009 (UTC)

Coll-add category tooltip

Article is too Wikipedia-centric term. --EugeneZelenko 13:56, 23 March 2009 (UTC)

Same for Coll-clear collection tooltip ("⧼Coll-clear collection tooltip⧽"). --EugeneZelenko 14:02, 23 March 2009 (UTC)
Done Done Siebrand 20:02, 23 March 2009 (UTC)

Special:LanguageStats should used Percent

I don't no it is right here or in bugzilla: Special:LanguageStats should used the message Percent ("$1%") and formatnum to format the number with the right decimal comma. Thanks. Der Umherirrende 18:29, 23 March 2009 (UTC)

Can be done. Will look into that. Siebrand 19:37, 23 March 2009 (UTC)
Done Done mwr:48721. Siebrand 22:47, 23 March 2009 (UTC)
That looks good. But by the fuzzy value is a lost of precision because it is not rounded to two digit after decimal point. When the value is less than 0.5% it is shown as 0%, that's wrong. It is also possible to add trailing zeros? (99,7% -> 99,70%) Der Umherirrende 20:41, 24 March 2009 (UTC)
Accidentally omitted those. Fixed. Siebrand 20:52, 24 March 2009 (UTC)
table with Percent/de
3,03 %
16,67 %
0,65 %
Thanks. Only sortable makes trouble by other interface then "en", because wgSeparatorTransformTable from the interface language is not load. But that is not a big problem, I can live with that. Der Umherirrende 21:11, 24 March 2009 (UTC)
I am uncertain - can sort refer to attributes other than field content? If so, attach an id="some-prefix_100.00_suffix" where the constant some-prefix protects against ids starting with a numeric, which is not allowed, and the variable suffix is something like, AA, AB, AC, … protecting against duplicated ids, which were not allowed, and has the nice side effect of making the sort stable. --Purodha Blissenbach 13:35, 25 March 2009 (UTC)
To get the dupes it is necessary to sort first in core. I think that is not a good idea. Der Umherirrende 20:11, 25 March 2009 (UTC)
Do not try to find dupes in advance. Appending sequence letters suffices. --Purodha Blissenbach 00:23, 26 March 2009 (UTC)

maintenance-stats-updateTemplate:Msg/wrong parameter, maintenance-move ("⧼maintenance-move⧽"), maintenance-re-re ("⧼maintenance-re-re⧽")

May be … should be used instead of ...? --EugeneZelenko 14:18, 25 March 2009 (UTC)

Ellipsis ("...") is better. --fryed-peach 14:44, 25 March 2009 (UTC)
Done Done, as per Revision 48978. --Purodha Blissenbach 02:46, 29 March 2009 (UTC)

== Missingsummary ("Reminder: You have not provided an edit summary. If you click "Save page" again, your edit will be saved without one."), Missingcommentheader ("Reminder: You have not provided a subject for this comment. If you click "Save page" again, your edit will be saved without one."), Explainconflict ("Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. Your changes are shown in the lower text area. You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page"."), Watchlistedit-normal-explain ("Titles on your watchlist are shown below. To remove a title, check the box next to it, and click "Remove titles". You can also edit the raw list.") == I think int: should be used for button name to keep translation consistent. --EugeneZelenko 14:23, 25 March 2009 (UTC)

I've added appropriate hints in the message documentations: MediaWiki:Missingsummary/qqq, MediaWiki:Missingcommentheader/qqq, MediaWiki:Explainconflict/qqq, MediaWiki:Watchlistedit-normal-explain/qqq. --Purodha Blissenbach 02:35, 29 March 2009 (UTC)

Simple Security

According to the code and the the documentation, $1 in Security-desc-LS ("⧼Security-desc-LS⧽") is either "namespace" or "category". It should be localised. --fryed-peach 16:24, 26 March 2009 (UTC)

Please make a bug report in bugzilla:. Siebrand 10:36, 28 March 2009 (UTC)
Done Done, see bug 18238. --Purodha Blissenbach 22:37, 28 March 2009 (UTC)
Thanks, I've voted. --fryed-peach 15:56, 29 March 2009 (UTC)

Security-info ("⧼Security-info⧽") and Security-info-toggle ("⧼Security-info-toggle⧽")

These message should be combined into one to avoid broken sentence. --EugeneZelenko 14:18, 27 March 2009 (UTC)

What will break? $1 in 'info' is replaced by 'info-toggle', and 'info-toggle' is used nowhere else. This is use elsewhere, too. Siebrand 10:35, 28 March 2009 (UTC)
If it is used nowhere else, it is at least unneccessarily complicated, and could be all put in one message. I agree that the current situation is prone to broken grammar. --Purodha Blissenbach 10:48, 28 March 2009 (UTC)

extra text "Message documentation"

When edit a /qqq-message the save button has a extra text "Message documentation". It is possible to localize this? Thanks. Der Umherirrende 23:56, 27 March 2009 (UTC)

No. Message documentation is in English, as is the warning. Siebrand 18:57, 28 March 2009 (UTC)


The page should show a own message instead of the header, when there are no rows. Thanks. Der Umherirrende 00:01, 28 March 2009 (UTC)

Low prio. Added to list. Siebrand 18:56, 28 March 2009 (UTC)

Altered font selection

I am a bit unhappy with the new (wider) font slected for Now not a singel page fits on my screen any more, I am getting right-left scroll bars. When I reduce their size to 78%, they all seem to do, which is not too bad, I loose some of the lines around boxes, but almost everything but the site naotice is readable. Only the edit extarea is hardly :-( readable any more. --Purodha Blissenbach 10:40, 28 March 2009 (UTC)
LOL! As you see from my typos that went undetected, it's really not readable well enough. --Purodha Blissenbach 10:43, 28 March 2009 (UTC)

I have revert them. Please purge your browser cache. Der Umherirrende 10:47, 28 March 2009 (UTC)

Oh, thank you. I would not have minded to find the old font and put it in my personal CSS, but you have been quicker :-) --Purodha Blissenbach 10:50, 28 March 2009 (UTC)

It might be nice if someone warned User:Ahmed-Najib-Biabani-Ibrahimkhel about his reverted changes - and why - and told him how to fix this in his personal css. Siebrand 18:56, 28 March 2009 (UTC)

Security and Protectlogpage

Security ("⧼Security⧽") generates an error message: The translation for this message cannot be equal to that of protectlogpage ("Protection log") Yet the originals are identical! --Purodha Blissenbach 10:57, 28 March 2009 (UTC)

Well, one is "Security log", the other is "Protection log". If the translation is the same, one of the two logs will not be visible in the drop down for logs in Special:Log. Siebrand 18:53, 28 March 2009 (UTC)
Oops, I apparently confused the messages. There are two identical ones saying "Security log" under different names indeed, but the other is not protectlogpage ("Protection log"). Sorry. To my excuse I have to say that my translation of both "Security log" and "Protection log" are identical. I'll find another wording for the "security something" stuff, which is about protection against being read, actually. Herewith:
Done Done. --Purodha Blissenbach 22:09, 28 March 2009 (UTC)


Without explanation or use case, I have problems to translate Abusefilter-edit-throttle-groups ("⧼Abusefilter-edit-throttle-groups⧽"), the original:

Group throttle by:

(one per line, combine with commas)

My questions: Is there an input field inserted behind the 1st colon in the message? "Throttle" is singular, but grouping requires at least two items to be useful, is that an error or am I missing something? What kind of info is to be put on separate lines, throttles, or groups? Where do their names or other identifiers come from, i.e. how would a user know them? How can one combine things with commas, when they have to be on separate lines? --Purodha Blissenbach 07:34, 9 March 2009 (UTC)

It's the label for a textbox on the right. The throttles are somewhat complicated, and described (probably poorly) at Werdna 01:22, 27 March 2009 (UTC)


Translating messages in the Abuse Filter extension is quite some guesswork, since explanations are missing. I neither could find a wiki where I could inspect messages in their context, nor could I get it to work in my test wiki.

Abusefilter-edit-builder-vars-diff ("⧼Abusefilter-edit-builder-vars-diff⧽") (Unified diff of changes made by edit) is hardly making any sense to me, and I believe also not to the average English reader. Btw. "diff" is highly technical jargon, and likely not generally understood well enough. That the message is hardly understood shows its German translation as Vereinigter Versionsunterschied der Bearbeitung, which is grammatically self-contradicting, re-translated: "The difference of a version of editing combined (or merged)" (Combined with what? Combining needs at least two, yet there is only one here. :=) --Purodha Blissenbach 08:26, 17 March 2009 (UTC)

"Unified diff" is a specific format, see wikipedia:diff#Unified_format. – Werdna 09:36, 17 March 2009 (UTC)

Oh, I see, thank you. So I could leave "unified diff" untranslated, and the message boils down to:
Show differences in ''<span lang="en">unified diff</span>'' format
(as "the change" and "the edit" translate the same, they cannot be used here without creating utter confusion) Good! --Purodha Blissenbach 13:11, 18 March 2009 (UTC)

Modifications to FreeCol source language [en]

I was told to post here a patch for review on updates to the English for Freecol. Nickshanks 17:06, 21 February 2009 (UTC)

Nike needs to handle this. Siebrand 19:13, 24 February 2009 (UTC)
Applied as is. The following messages needs updating due to added ellipsis: menuBar.view.europe menuBar.view.tradeRoutes menuBar.view.findColonyNike 14:01, 13 March 2009 (UTC)

Original English messages a bit unclear/too technical

I don't think the average user knows what a namespace is (i.e. non-technical users).

So I think a few messages in English should be changed.

  • Powersearch-ns (used on Special:Search)
    Current message: Search in namespaces:
    Since it's not necessary and most people wouldn't understand the "namespaces" part i suggest we change it to "Search in:"
    Other messages that include the word "namespace" aren't as visible, and the message is rather unclear if you remove it.
  • Blanknamespace (used on e.g. RC, Search)
    Current message: (Main)
    This is fairly hard to get a global name for the main namespace that's better - e.g. for Wikipedia it could be "Article", but for Wiktionary it would be "Entry" and for other sites it could vary a lot. So perhaps "Main" is the best we can do?
    It is not at all clear what the parentheses mean (my friend who looked at it thought that the main namespace was selected or something). If we want to tell users the namespace doesn't have a prefix - shouldn't that be explicit: "Main (no prefix)"? Either that or removing the parentheses all together: "Main". I think the former would be better.

Does this sound like good ideas? What do you think? Skalman 17:39, 26 February 2009 (UTC)

During my first encounters with MediaWiki, I had these problems, and I did not understand namespaces for a while, and few related things. That was years ago, and I got used to them. --Purodha Blissenbach 11:55, 28 February 2009 (UTC)
Yeah - we can't presume that readers will even want to understand such stuff - as a reader you shouldn't have to encounter the word "namespace", while it is quite useful for editors. Skalman 15:08, 2 March 2009 (UTC)
I agree that "Search in:" is probably enough for the first message. If a reader doesn't understand the choices that are in the tickboxes after that then that reader probably won't understand "namespace" either! I suppose an alternative would be to make "namespace" into a link to a help page on Meta that would explain what a namespace is. I also support your suggestion "Main (no prefix)", although again for general readers who don't know about prefixes this might be just as confusing as before. Lloffiwr 19:01, 7 March 2009 (UTC)

Globalblocking-logentry-expiry ("⧼Globalblocking-logentry-expiry⧽")

What is $1 in Globalblocking-logentry-expiry ("⧼Globalblocking-logentry-expiry⧽")? If it is a duration, fine. For a date and time of expiry, we preferrably had date and time separated for a better translation. --Purodha Blissenbach 10:37, 5 March 2009 (UTC)

Actually, this is one of the rare cases where we can do without a date/time split in a text message, the reason being its terseness. Should we generally have date/time separated everywhere, except in tabular list enties, or should we be more lenient? I lean towards the more rigid version, among other reasons because I assume that, sooner or later, there will be more languages that need a separation, or benefit from it. --Purodha Blissenbach 23:38, 5 March 2009 (UTC)

It is wfTimestamp( TS_ISO_8601, $block->gb_expiry ) or 'infinity', and could be manipulated before being added to the log entry. Siebrand 09:38, 6 March 2009 (UTC)


Centralauth-merge-no-accounts ("⧼Centralauth-merge-no-accounts⧽") tells the user that his username wasn't found in the database and that the database is corrupted. Shouldn't there be some advice to the user about what to do or what that means to him? --Slomox:: >< 16:59, 9 March 2009 (UTC)

Imho, Yes. How about: "You cannot proceed at the moment, and please inform an [[Special:Listadmins|administrator]]."
I do not think that wiki administrators actually can do anything for the problem. Currently Wikimedia is the only user of Central Auth, and bugs should be filed to their bugzilla. – Nike 14:33, 13 March 2009 (UTC)
Yeah, I was a bit short-sighted. How about: "You cannot proceed at the moment. Please file a bug at [[:bugzilla:|MediaZilla]] selecting the product "Wikimedia", and the component "General/Unknown", so as to help getting the issue solved as soon as possible. Thank you."
Well yeah, but that has the other problem of hard coding Wikimedia. – Nike 17:30, 18 March 2009 (UTC)

Adding language code to edit screen

This is a copy of part of a discussion which has gone to the archive, resurrected because I think that Nike is still waiting for our opinion on which solution is best. Lloffiwr 15:19, 28 February 2009 (UTC)

While most usually translating to ksh, I happen to translate, or rather correct obvious errors, in some other languages occasionally. Several times already I forgot to switch back, and accidentally saved my ksh translations in the wrong language. I'd like some more obvious visible hints - e.g. a different background color of edit fields other than in my default language, and/or a big fat langguage code next to the edit window, or something. --Purodha Blissenbach 23:32, 17 February 2009 (UTC)
Having the language code written somewhere obvious (added to the Save button perhaps?) would be great. If the link from each language portal to the translation tool went to the corresponding language, I think I would use it, and hope to get used to it:-) Lloffiwr 09:09, 18 February 2009 (UTC)
Tried to implement this a test last night. Found it less easy than expected. Though translatewiki.nets edit page of translateable messages is special, it seems to use MediaWikis normal edit fields and buttons. Altering the "Save" button appears not trivial. Postponed. --Purodha Blissenbach 10:23, 22 February 2009 (UTC)
There are places where extensions can add code. Any opinions which baa1-baa6 would be the best at example page ? --Nike 13:14, 22 February 2009 (UTC)
How about baa4, or baa3, or both? Lloffiwr 23:04, 22 February 2009 (UTC)
When trying to find the right place to do it, and, say the users default language was und, when editing a zxx message, I was planning for either of these:
  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save page to zxx] [Preview] [Show changes] Cancel | [help] (opens in new window)
  2. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Switch back to language und] [Save page] [Preview] [Show changes] Cancel | [help] (opens in new window)

When editing messages in the users default language, and when editing any other wiki page, nothing should be different from the current page:

  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save page] [Preview] [Show changes] Cancel | [help] (opens in new window)
--Purodha Blissenbach 17:48, 28 February 2009 (UTC)
Why not combine 7. and 6., and put the additional button of 7. behind the others, and label them 'Save to xxx', and 'Back to zzz' only? -- 07:21, 1 March 2009 (UTC)
Like so:
  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save to zxx] [Preview] [Show changes] [Switch to und] | Cancel | [help] (opens in new window)
? --Femina 12:33, 1 March 2009 (UTC)
If pushed I would say that I prefer solution number 6 - it is straightforward and not too different from other wikis. If the language code only appears when not in the default language that is fine, but I think that having the language code appear for all languages including the default language code would also work well. However, all of the suggestions made by both Purodha and Nike would be an improvement. So whichever is the option that is most efficient for the site is the option that I support:) Lloffiwr 09:38, 8 March 2009 (UTC)
I for one would like the language only to appear when changed from standard because I am afraid, else buttons may sometimes appear too similar (depending on languages). Also, I'd really appreciate an easy way to go back to my standard language other than having to fiddle with the URL in my browsers address field. This involves scrolling the field sidewards several times, and finding the language code in the middle somewhere, which is really time consuming.
A button to go back is kind of unneccessary, technically, a normal link would suffice of course. The reason why I made it a button in the examples above was mainly the more distinctive appearance of the whole, so as to more likely avoid erroneous clicking. --Purodha Blissenbach 09:09, 9 March 2009 (UTC)
I don't really have any strong feelings about which particular option is best; I'm sure I'll appreciate using whichever option is decided upon:-) Lloffiwr 14:13, 10 March 2009 (UTC)

I see, we have a mild variant "Save (Message Documentation)" now. Thank you. Did you think, that other languages should better not be shown? --Purodha Blissenbach 12:37, 18 March 2009 (UTC)

Qqq is what is causing most troubles, so it naturally needs to be different. What comes to other languages, they are less often accidentally used, and I myself currently and some others may prefer using interface language other than what they are translating. In this case it would always be shown, which is not good. Also, Siebrand didn't really think this is important thing, so I kept the effect on minimal on that basis too. – Nike 17:19, 18 March 2009 (UTC)

lucene search

Can this web install Lucene search extension as in wikipedia? This will enable some language, for example Thai, to be searchable. --Ans 04:51, 26 February 2009 (UTC)

We do not have the functional or technical resources to make this possible. This request will not be granted. Siebrand 13:57, 26 February 2009 (UTC)
I do not understand the request. I thought the default search engine is pretty good now. Is there some problem with it? – Nike 18:31, 26 February 2009 (UTC)
I have several times experienced that a search for some Danish text what I saw used here in the translatewiki either failed, or gave too many hits because of similar use in other languages. I suggest downloading po-files from Translating:Offline and using them to search locally. That way you can use any search tool you like, and no other languages will disturb the search. Byrial 11:38, 27 February 2009 (UTC)
There's no word segmentation in Thai sentences, so mw search can't search Thai words in Thai sentences. However, Lucene 2.1 does segment Thai words, so Thai words can be searched in Lucene 2.1 --Ans 04:59, 2 March 2009 (UTC)
Apart from Thai word segmentation problem, I still cannot search for many segmented phrase, for example, the phrase "ระบุส่วนต่างเวลา" in MediaWiki:Timezoneuseoffset/th is not searchable. --Ans 09:13, 3 March 2009 (UTC)
Lame alternative, but can you use Google? Siebrand 00:18, 6 March 2009 (UTC)
I've just tried google (query for "ระบุส่วนต่างเวลา"). It found this Support page, but not MediaWiki:Timezoneuseoffset/th --Ans 06:33, 9 March 2009 (UTC)
I do no think setting up lucene would be that hard, but is there any documentation for it? I do not have time to just play around with it. – Nike 15:01, 13 March 2009 (UTC)
  1. lucene-search 2.1 doc
  2. lucene-search 2.0 doc
It is a bit complicate, if you want to also setup the incremental updater for the search index. --Ans 14:56, 16 March 2009 (UTC)
Hmm, I've just tried querying google for "ระบุส่วนต่างเวลา", again. It now found the message page MediaWiki:Timezoneuseoffset/th. May be lucene-search extension is not needed now (but nice to have) :) --Ans 15:04, 16 March 2009 (UTC)

Request for namespace alias creation

Hi, I just renamed ns:Talk for French from Discuter to Discussion. We now need an alias from the old title to the new one. Thanks in advance. PieRRoMaN 14:17, 8 March 2009 (UTC)

When namespace names are changed, a developer *will add* those aliases (or get spanked). Siebrand 15:54, 8 March 2009 (UTC)
Does it mean we don't need to care if links would be broken due to changing namespace aliases? Japanese translators are considering such changes and a request to developers. BTW, it would be great if we could specify multiple aliases for a single namespace in Special:Magic. --fryed-peach 07:58, 16 March 2009 (UTC)
In a way yes, but in a way it forces the translators to make the decision and not to add unnecessary aliases. – Nike 17:16, 18 March 2009 (UTC)

Language variable in messages of Babel extension

There is a variable "$3" in the Babel messages which represents the respective language. The issue is that we are use adverbial forms of the language name in Upper Sorbian (hornjoserbsce) and Lower Sorbian (dolnoserbski). But, the Babel messages require a noun form which has to be declined, e.g:

This user has basic knowledge of $3.
Tutón wužiwar ma zakładne znajomosće $3. (in Upper Sorbian)

At present this results in:
Tutón wužiwar ma zakładne znajomosće hornjoserbsce.

But it should be:
Tutón wužiwar ma zakładne znajomosće hornjoserbšćiny.

Hornjoserbšćina is the actual name of the language, here in its genitive form.

Similar in Lower Sorbian: the adverb is dolnoserbski in Lower Sorbian, and the noun is dolnoserbšćina, genitive is dolnoserbšćiny.

Using a variable here isn't good. I think if you will keep using a variable the two language names should be changed to hornjoserbšćina and dolnoserbšćina in names.php to use the variable later on with the GRAMMAR template to express the respective grammatical case. But, I don't know if there will be any complications with the hitherto existing occurrences of these two language names. Regards, --Michawiki 22:18, 8 March 2009 (UTC)

That is what the optional "-n" messages in Babel are for. Siebrand 22:23, 8 March 2009 (UTC)
Ah, thank you. I tried to customize the default messages but they have been pushed to the problematic messages then.That was the reason why I asked. Regards, --Michawiki 22:44, 8 March 2009 (UTC)

Thanks, but I cannot use translatewiki

You closed my bugs Bugzilla:17859, Bugzilla:17794, Bugzilla:17742, Bugzilla:17736, and told me to use translatewiki.

But translatewiki requires we "set your user interface to the language you will be working on".

You are making a big mistake thinking that everybody can work best that way.

I can't.

So my bug reports got thrown in the dumpster. Jidanni 03:30, 9 March 2009 (UTC)

OK, I can still make a contribution by mailing patches to .po files. That way I can use all my own familiar interfaces. Following the instructions on Translating:Offline, I have mailed a patch that will solve Bugzilla:17859.

However some of the other bugs involve setting up test scripts, which is beyond the scope of translate wiki.

And some of the other bugs are asking how to proceed: do you wish me to make the rash changes I propose?

So by just summarily closing all the bugs, you do not resolve the issues. Jidanni 05:57, 9 March 2009 (UTC)

What comes to scripts, I'd like to integrate them into the interface if they are made in php. – Nike 17:14, 18 March 2009 (UTC)

Upper Sorbian Flagged-Revs messages are used for Lower Sorbian Flagged revisions Stabilization messages

If I use preview for following Lower Sorbian messages (Flagged Revisions - Stabilization)

stabilization-text ("⧼stabilization-text⧽"), stabilization-select1 ("⧼stabilization-select1⧽"), stabilization-select2 ("⧼stabilization-select2⧽") and stabilization-select3 ("⧼stabilization-select3⧽") which use the Flagged Revisions - Flagged Revs messages

the last mentioned messages use the Upper Sorbian text instead of the Lower Sorbian:

  • revreview-lev-sightedTemplate:Msg/wrong parameter uses Upper Sorbian přehladana instead of Lower Sorbian pśeglědana
  • revreview-lev-quality ("⧼revreview-lev-quality⧽") uses Upper Sorbian kwalitna (I'm sure that's Upper Sorbian but here Lower Sorbian has the same text, so it seems that there isn't any difference)
  • revreview-lev-pristine ("⧼revreview-lev-pristine⧽") uses Upper Sorbian prěnjotna instead of Lower Sorbian spoćetna

Besides I don't find good that there are special messages for simple adjectives where just one grammatical form is possible. There are languages that have declension like Upper and Lower Sorbian. Regards, --Michawiki 22:09, 10 March 2009 (UTC)

I've just seen it's because I was using Upper Sorbian as GUI language for I switched to Lower Sorbian and then the respective words were in Lower Sorbian as it should be. Regards, --Michawiki 22:23, 10 March 2009 (UTC)
I've made the message names links so as to ease looking them up. --Purodha Blissenbach 06:39, 11 March 2009 (UTC)
IRCC the developer made some tweaks to the messages. Is it now ok or not? – Nike 14:15, 13 March 2009 (UTC)

Daddio skin

I have realized that new Daddio skin has been added to the software. It would be nice to have localization support for it, too. Thanks. --fryed-peach 06:50, 11 March 2009 (UTC)

Which part of it is not localisable? Do you mean the name of it? – Nike 14:13, 13 March 2009 (UTC)
Yes, its name on Special:Preferences. Maybe that on a default comment in .css and .js, too? --fryed-peach 07:34, 16 March 2009 (UTC)
Looks like we need to add them. – Nike 17:12, 18 March 2009 (UTC)
Taken out of core and now available as an extension. No longer relevant. Siebrand 16:25, 29 March 2009 (UTC)


Why is en:MediaWiki:Sharedupload/nds different from MediaWiki:Sharedupload/nds? Why doesn't it show a link to Commons? --Slomox:: >< 11:12, 11 March 2009 (UTC)

Likely to be . – 14:38, 13 March 2009 (UTC)
There were no updates since a month? --Slomox:: >< 11:05, 15 March 2009 (UTC)
Yeah, should be live now. Or not, dunno if it should be. – Nike 17:10, 18 March 2009 (UTC)
Fixed now. – Nike 08:19, 28 March 2009 (UTC)

Expansion depth limit exceeded

Error message here: "Merge account across wikis of {{Expansion depth limit exceeded}}" --Meno25 20:44, 11 March 2009 (UTC)

I don't see anything at there. – Nike 07:49, 12 March 2009 (UTC)

Look in the "Information about the group" box. Full text is:

Information about the group
Merge account across wikis of {{Expansion depth limit exceeded}} 

--Meno25 21:49, 18 March 2009 (UTC)

Works for us. Cannot reproduce. Siebrand 16:26, 29 March 2009 (UTC)

No used message

Message Mediawiki:Logouttitle is not used in current PHP code. Sp5uhe 20:03, 14 March 2009 (UTC)

Done Done mwr:49016. Siebrand 16:59, 29 March 2009 (UTC)

Fuzzy followed by whitespace

When Fuzzy marks are stripped for export, whitespace following them should be, too. Currently, messages cannot have leading whitespace, except, when sneaking through behind a Fuzzy mark. --Purodha Blissenbach 09:06, 16 March 2009 (UTC)

Message can and some need to have leading whitespace (only spaces, newlines are known to cause trouble) – Nike 12:56, 16 March 2009 (UTC)
egrep " => ['\"] " *En.php
'filename-prefix-blacklist'   => ' #<!-- leave this line exactly as it is --> <pre>
'upload_source_url'  => ' (a valid, publicly accessible URL)',
'upload_source_file' => ' (a file on your computer)',
'external_image_whitelist' => ' #Leave this line exactly as it is<pre>
  • Submitted new patch stripping only leading line-endings, vertical tabs, and NULs. --Purodha Blissenbach 08:29, 17 March 2009 (UTC)


This message should use PLURAL for parameter $1. --EugeneZelenko 14:05, 19 March 2009 (UTC)

Done Done This message uses addWikiMsg() to add it. It already supports plural. Siebrand 17:07, 29 March 2009 (UTC)


I believe, in Grouppermissions-sp-header ("⧼Grouppermissions-sp-header⧽"), the word "hover" in english, or the translations referring to "mouse" are problematic, because too much depending on browser specifics, which may vary. I've no better suggestion, however. :-(( --Purodha Blissenbach 02:33, 22 March 2009 (UTC)

You can refer to the tooltip concept. Siebrand 17:10, 29 March 2009 (UTC)

Gift received body

What are variables in Gift received body ("⧼Gift received body⧽")? --fryed-peach 14:18, 22 March 2009 (UTC)

Done Done Siebrand 16:23, 29 March 2009 (UTC)

Gender support needed

Abusefilter-edit-builder-vars-user-name ("⧼Abusefilter-edit-builder-vars-user-name⧽") does not have a user name parameter but is followed by a user name link when used. --Purodha Blissenbach 09:57, 26 March 2009 (UTC)

It is a query builder variable. Gender support does not make sense. Siebrand 17:11, 29 March 2009 (UTC)
Ok. Ok. I misinterpreted some documentation or comment text. --Purodha Blissenbach 23:05, 31 March 2009 (UTC)



stableversionsTemplate:Msg/wrong parameter says "View stable versions". Should that not rather be "View stable revisions" so as to use a consistent wording throughout the group of messages? --Purodha Blissenbach 09:47, 29 March 2009 (UTC)

Actually I wish they would consistently use "version" instead of "revision" in that context. The English word "revision" can also mean "review" as in "act/result of reviewing/revising", which is ambiguous. In Interlingua and (as far as I can see) all Latin languages this is even more problematic as "review" and "revision" are both translated as "revision". So I try to consistently translate something like "stable revision" with "version stabile" to avoid ambiguity. – McDutchie 13:53, 29 March 2009 (UTC)

We do not have a distinction between "revision" (as of history/revision, or r4711 of a program) and "version" - there is only one word, close to "version". We have a word similar to "revision" but that's meaning "fiscal check", "controlling" and the like. Instead of "a revision having been made" in the 2nd sense, we talk of "one has throughly looked/read through something", similar to inspecting, and since this has no other effect than enlightening the reader, we must also make explicit that, a record has been taken in the form of a value mark that was attached to that something. :-) Believe me, it's a lot of additional words. Maybe, we can lobby for using "version" in the english text consistently, and avoid "revision" (as of r12345) altogether inside MediaWiki? --Purodha Blissenbach 14:27, 29 March 2009 (UTC)

More candidates to use Ellipsis ("...")

MoredotdotdotTemplate:Msg/wrong parameter, Resetpass successTemplate:Msg/wrong parameter, IteminvalidnameTemplate:Msg/wrong parameter, WatchingTemplate:Msg/wrong parameter, UnwatchingTemplate:Msg/wrong parameter, ImportstartTemplate:Msg/wrong parameter, Ow conceptmapping helpTemplate:Msg/wrong parameter, Refreshspecial-slave-laggedTemplate:Msg/wrong parameter, Refreshspecial-reconnectingTemplate:Msg/wrong parameter, Recordadmin-needscontentTemplate:Msg/wrong parameter, Contrib-tracking-submittingTemplate:Msg/wrong parameter, Cite error references invalid parameters groupTemplate:Msg/wrong parameter, Boardvote introTemplate:Msg/wrong parameter, Boardvote invalidenteredTemplate:Msg/wrong parameter, Imstatus icq styleTemplate:Msg/wrong parameter, Revreview-submittingTemplate:Msg/wrong parameter, Readerfeedback-submittingTemplate:Msg/wrong parameter, Template:Msg/wrong parameter, Configure-setting-wgRawHtmlTemplate:Msg/wrong parameter, Configure-setting-wgAllowCategorizedRecentChangesTemplate:Msg/wrong parameter, Communityvoice-ratings-scale-status-sendingTemplate:Msg/wrong parameter. --EugeneZelenko 15:25, 29 March 2009 (UTC)

Let's not. The messages look ugly and novice translations get confused. Just put a real ellipsis in there for de source (English) message and be done with it. An English fallback with a localised ellipsis also looks stupid. Siebrand 16:14, 29 March 2009 (UTC)
You are right. I think it is the best to use the right ellipsis in mwr:48978 instead of the message. Please FUZZY only message with the 'wrong' ellipsis. Thanks. Der Umherirrende 17:12, 29 March 2009 (UTC)
I'm not fuzzying the change I made here. It's a very small issue that should be corrected in a review round. Less than 20 translation communities here are at that stage. Siebrand 17:50, 29 March 2009 (UTC)
1) We should have an {{int: }} equivalent using the same language as the msg it is being used in. Rarely needed, but it would solve the above namespace issue, and would allow the right ellipses to be inserted here.
Slightly more general: {{int2:message-name|lang-code}} which allows lang-code to be left out and thus 'inherited' from the language being in effect at the place of use of int2.
2) I agree with using plain ellipsis in the original messages. --Purodha Blissenbach 07:19, 31 March 2009 (UTC)


There is a request to have a Wikipedia in Votic. In someone may do the work. We only submit to SVN when more then 50% of the most used messages are localised. So as there is this request, I do ask for Votic to be enabled. Only to be submitted at 50%. Thanks, GerardM 11:04, 30 March 2009 (UTC)

Done DoneNike 20:26, 31 March 2009 (UTC)
  • "stupid question" (for the FAQ page) - Why are we waiting for 50% - avoid never continued tasks filling the svn repository? - any other reasons? Tx. --Purodha Blissenbach 07:04, 31 March 2009 (UTC)
Because anything less is not even useful? – Nike 07:18, 31 March 2009 (UTC)
I dunno. Thats a question: Users at the incubator, or any other striving new project outside the wmf scope, may feel very happy to see even the first little beginnings showing up at their wiki. Especially so, when some basics need to be discussed, such as consistent choices of one word out of a group of synonyms, or, for languages "untechnical by nature", such as vernacular, ancient, or some 3rd world languages, which words or expressions to strech to include special computerese/mediawikinese terms, e.g. file, user, namespace. Of course, this can all be had and done here on Only people need to be motivated to come here, too. When starting a new test Wikipedia, shortly before Betawiki began, and long before incubator, I realized that sending people to Commons for file uploads was not a good idea and not working well. So I am afraid that some may be hesitant to come here. Which in turn puts up he question: Why not let them stay there, and let them have all they need, there? --Purodha Blissenbach 07:39, 31 March 2009 (UTC)

Next archive page