Jump to navigation Jump to search
NoteProblems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. Very old threads have been archived.
(The thread summarization feature is broken, see: Phab:T245109)


Thread titleRepliesLast modified
"WebAuthn" extension511:04, 1 November 2019
MediaWiki:Globalrenamequeue-email-body-approved-with-note214:36, 31 October 2019
Special:ContributionScores does not dsiplay accurate figures913:49, 29 October 2019
How to see all Czech translations that have not been yet translated to Slovak?420:04, 28 October 2019
TranslateUserManager516:20, 28 October 2019
username change request115:15, 24 October 2019
Typo in MediaWiki:Sanctions-empty?013:39, 22 October 2019
Incorrect Korean text in MediaWiki:Sanctions-row-button-execute/en001:11, 22 October 2019
typo in source MediaWiki:Sanctions-content-placeholder/en001:03, 22 October 2019
Translation right108:23, 21 October 2019 courses/fr022:33, 20 October 2019
[critical bug] MediaWiki:Withoutinterwiki-legend/fr : translation mixups: updates are going to the wrong page422:21, 15 October 2019
typo in Wikimedia:Whowrotethat-tour-welcome-description/en : "the the"217:12, 15 October 2019
[bug] Translate UI - wrong placement of circled accelerator keys220:33, 14 October 2019
An Error in, 10 October 2019
Deleting unused strings from translated language files515:13, 9 October 2019
Mobile version of main page112:59, 9 October 2019
Saving the translation failed121:22, 5 October 2019
Request username change111:38, 1 October 2019
MediaWiki:Leafletdraw-edit-toolbar-buttons-edit/en017:47, 30 September 2019
First page
First page
Last page
Last page

"WebAuthn" extension

Hello! I don't know any other place to post suggestion like this, but maybe you should consider installing WebAuthn extension as a complement for OATHAuth (2FA provider).


Rail (my talk | contribs)20:50, 28 October 2019

Interesting. Has it gone through a security review?

Nike (talk)17:48, 30 October 2019

I'm not really sure but I have found this ticket on Phabricator:

I don't see any other security-related ticket, tho. However, as far as I know, this extension will be used on WMF wikis do you can assume it's secure enough.

Also thanks for your reply,

Rail (my talk | contribs)19:52, 30 October 2019

I'd say that technically the extension is ready, but the user experience is in alpha stage, so the translation may be also alpha as long as it has not been tested; there will likely be more to translate and explain how this should work and what ot do in case of problems of configuration and why this new Auth method would be preferable or not to another (the Phabricator task explicitly questions about how to work with multiple libraries trying to do the same thing, how they can be unified using a replacable hook allowing to evaluate also the implementations in terms of effective security, performance, cost of maintenance, debugging in case of problems. Also the testbed is still not in place, and they wonder how they'll recruit testers with usable inputs (or if automated monotoring can generate better results). In terms of pure UX, the testbed will receive some comments, several proposals will be made, as well as A/B tests. How many testers will be needed will also condition how many languages will be needed for these tests (they probably don't want to support many languages for now, but have enough inputs for specific needs in some countries where other authentication methods (possibly using thrid party services) are not supported very well, or have no good support and fow which alternate less demanding methods may be needed, but also more training for their users.

Still in all countries, 2FA is not enough known and not generalized, many users complain about how the current methods are implemented, and they also fear about privacy risks this causes to them (notably in countries like China with very active user monitoring by authorities, or with extreme social/economical and criminal risks like Russia or Mexico, or legal risks like US, or countries where users have no other choice to conenct to Wikimedia than using foreign VPNs, or slow mobile connections, or shared Internet access, or whose emails are heavily monitored

As well there's a worldwide threat caused by malwares that attempt to steal people's identity, and 2FA will sonn be not enough, we'll need more factors in a very near future. But how we'll configure all these to work correctly together may become really complex for many people, that will finally opt to protect their privacy by delegating everything to a commercial service provider like Apple, Google, Facebook or Amazon, and tie all their existence to a permanent dependency to these big players, creating lifetime monopoles and splitting the world in distinct proprietary universes.

Verdy p (talk)22:39, 30 October 2019

I'll consider this. It's not on top of the TODO list so it can take a while.

Nike (talk)10:30, 1 November 2019

Awesome. Thank you.

Rail (my talk | contribs)11:04, 1 November 2019


Globalrenamequeue-email-body-approved-with-note uses $1 on both, the old and the new username. Shouldn't it use $1 for the first and $2 for the new one?

MarcoAurelio (talk)22:01, 29 October 2019

$2 is the proposed new name, it still does not exist under this name so it cannot be queried for gender. Both names refer to the same user currently named $1, who has the gender settings (these user settings will be applied later to the new name once it is applied; then $1 will no longer have its own settings, it may be deleted/hidden, or kept as a public redirect (possibly protected against deletion or modification of its user pages and talk pages). So this is the same gender of $1 which would apply to both names.

Note that the gender may be needed only in a few language for grammatical forms. If a translation does not need it, the GENDER marker must still be present but may containt empty text (in the English text, the text is the visible user name, not the gender itself, and there's no alternate gender variant of that name and no need to add any other personal gender particle which may be required in addition to the specific user names (I think these gender particles are needed only in some native African languages; in some Slavic languages, there are sometimes variations of user names depending on case on specific constructs, which are also dependant on gender).

Verdy p (talk)22:46, 29 October 2019

Thank you Verdy p for the very helpful explanation. Regards.

MarcoAurelio (talk)14:36, 31 October 2019

Special:ContributionScores does not dsiplay accurate figures


during the last few dates I noticed that on the page Special:ContributionScores for my User for Last 7 days (Top 50) the number of contributions is marked as following:

Rank Score Pages Changes Username

49 9 9 9 Robby

while on [1] you may see that I made at least 50 edits on 31 August till 2nd September.

So there seems to be something broken on this.

Robby (talk)22:33, 1 September 2019

49 or 50 edits, this is not a huge difference, and the statistics are not counted immediately; your last few edits were probably made after the statistic batch was run (so it counted only 49). Look at the statistics after 24 hours, you should see evolve it (but the count may still be off by the edits you made in the last few hours after the batch ran). Verdy p (talk) 23:35, 1 September 2019 (UTC)

Verdy p (talk)23:35, 1 September 2019

I've the same problem since the last days of August. I'm on 27th overall ranking but my changes are stopped on 38201 (and the scores is stopped too). May be there's a bug?

Joe Taras (talk)16:56, 2 September 2019

You are mistakken 49 is the rank not the number of changes or pages these were 9 and there is quite some difference between 9 and over 50.

Robby (talk)21:27, 2 September 2019

OK, but your actual statistics is not 50 but over 70,000. Still my comment remains valid: the statistics are not computed all the time continuously but with batches running periodically, so it's normal that it can ignore your most recent edits over the last shortest period. As well, the results depend on the activity of the job queue (which is very active on this wiki even if there's few edits, as the longest jobs are those created for SemanticWiki, some of them running for hours may lock temporarily not just some pages but also the updates of related statistics (which will be deferred). These statistics are not intended to be actualized in real time, they are just estimates. Computing them has a huge cost on the server, so they cannot be refreshed instantly, even if this is based on a live SQL request (which is already costly and quite long to reply for this page, because it has to lookup all existing users to sort them and then extract about 50 of them in each "top list"; the statistics however are quite accurate for least frequent users, but must frequent users are only roughly sorted, especially for the shortest period of 7 days). Note also that the computed statistics do not show the actual period of dates on which they were computed: the period may be off by more time than what you expect, and the "last 7 days" may be 7 days before the last run of statistics offline jobs which may have occured up to 7 days ago (possibly more of the database had long job lists, with some jobs taking several days to complete and deferring other pending Statistics jobs to run that, most probably, have lower priority than Semantic jobs and regular jobs built in MediaWiki).

This statistics page is not certainly the one to consult if you want to get your own personal edit statistics, that you can get using the live Mediawiki API:
For example:
The same for Joe Taras: (note: you must use the actual username, like in your user page, not the displayed username in your signature, and URL-encode it if needed in the URL) This gives a total on all periods. Computing this over a period is much more complex as it requires scanning your history, so this cannot be done directly with the live API. Doing that on all existing users (just to get the Top 50 lists) is even more complicate and costly.

Verdy p (talk)21:13, 3 September 2019

Ok for me. Usually I've checked my stats and I've seen updated. Maybe there's a lot of traffic. No problem. Thank you for your reply

Joe Taras (talk)21:53, 3 September 2019

Dear, I must return on this issue. I've understood the performance is important but, if we can't see the updated information about edit count and other, please remove some functionality from Translatewiki, as follow:

The page SupportedLanguages is unuseful because if I check information about an user the information are not update, as the following image:

User activity detail.png

The page Contribution scores is unuseful because is not update, as the following image:

Contribution scores detail.png

And these widgets

Widget on edit count.png

I'll wait for your response.

Have a nice day

Joe Taras (talk)09:59, 29 October 2019

How to see all Czech translations that have not been yet translated to Slovak?

Hi, I have one question. When I created my account here on, I was asked what languages I know. So I chose English, Slovak and Czech. I translate English messages to Slovak through the Translate window and sometimes I just look for Czech messages that appear on Slovak wikiprojects since Czech is a fallback language for Slovak and because we don't have many contributors in Slovak at the moment, there are many Czech messages appearing on Slovak wikiprojects. I want to first translate all of them to Slovak and then look at the others. However, I can only see English messages and translate them to Slovak (with the help of Czech). Can I somehow see only all to-Czech translated messages which don't have Slovak translation?

Luky001 (talk)13:04, 28 October 2019

Special:SearchTranslations should help, but why not focus on untranslated messages regardless of the status in other languages?

Nemo (talk)13:22, 28 October 2019

Special:SearchTranslations works only when you know the text of the translation but I need the very same interface as when I translate random messages from English to (language I choose). What would happen if I didn't choose English in the beginning? Then it wouldn't be able to show me English translations as the source. I want to achieve something like that, the source would be Czech. I thought I can change/add languages I know also after the registration but I haven't found anything in preferences...

Why translate Czech translations at first? Because I firstly care about what translations are (mostly) seen, then about the others which might not be seen that often. (As I said, Czech is a fallback language for Slovak and I first want to make sure that Slovak texts (not the Czech ones) are appearing on Slovak projects.)

Luky001 (talk)14:50, 28 October 2019

Right, I had forgotten that we didn't finish the part of the work which involved adding a different source language. The interface is designed to allow it, though, so if you have some programming skills it might be easier to send a patch for that than to use manual methods.

What makes you think that the strings translated into Czech are the most seen? After the group of "top"/most used messages is translated, we have the main Wikimedia messages group which offers plenty of suggestions. Some of those messages are very important, for instance the new search features and notifications which are very visible.

Nemo (talk)16:19, 28 October 2019

I don't have programming skills to do that so could you please recommend me somebody who would be able to help me?

Seeing those Czech messages on Slovak projects makes me think that they are most seen.

Maybe, if I can suggest something, if it is not too hard and time-consuming, adding an option to switch the source language would be a very useful thing (at least for me).

Luky001 (talk)19:58, 28 October 2019


Who is this user, and why he opens account which is IP address? See Special:Log/newusers.

Zoranzoki21 (talk)12:41, 20 October 2019

That IPv6 is "mine", very strange because I'm logged in here.

If you look for it, you'll see that it belongs to the IPv6 space allocated by for its fiber accesses (the IPv6 translates algorithmically into a regional location and default IPv4 address, normally, but this does not apply to me because my IPv4 (which is not shared by 4 users like it is by default in, which uses NAT by assigning them 4 distinct ranges of 13684 port numbers for TCP and UDP, instead of the classic 65536 port numbers) was allocated to another space where I have a dedicated IPv4 address not passing through NAT.

This is visibly a bug of the "TranslateUserManager" bot, loosing some data about user sessions when we are connected via IPv6, or when some subrequests are coming with different address. Or may be there's a bug in this wiki in its antispam systems, which incorrectly assume that an IPV4 cannot be used simultaneously by two unrelated users. Anyway this is also a privacy bug that should be signaled (it does not conform to Wikimedia policies), and fails to map the related IPv4 and IPv6. I can't explain why this happens, but sessions are incorrectly managed by the frontends of this wiki.

This may be related to recent bugs in this wiki, with failure in its front end caches, also loosing sessions, mixing queries, corrupting the frontend caches with unrelated translations, and not returning the expected data and making incorrect logs for user accounts that it could not get.

I've never opened any such account and in fact the log is wrong as there was no account created at all. All this comes from an internal bot on this wiki.

This bug is visible since last August 15. I never had my IP "logged" like this even if I used this wiki before and did not change my ISP settings or subscription and was active even before.

Verdy p (talk)21:17, 20 October 2019

Everyone sees their own ip. The users in those log entries no longer exist and those log entries should not be there.

Nike (talk)08:19, 21 October 2019

What do you mean ? We don't see the same things in logs ? How can you be certain we have the right to see "deleted" log entries? Just because at one time we are using the same IP ? Anyway I do see all these log entries (about 4-5 listed each day since August 15, not any one before, but I see them in the log just since a few day; I many have not noticed that before). So you say that these log entries "no longer exist", but then why do I see them ? Was there a bug that caused IP accounts being created for logged in users, then immediately deleted after logon, but recreated later and repeatedly ? This is clearly a bug: there should not be any account creation before we submit an actual edit (just reading the wiki or logging in should log nothing, or you have a serious privacy issue for RGPD).

Verdy p (talk)23:01, 21 October 2019

@Verdy p: The IP address I see is the one I'm using. It's not an IPv6 address. I agree it's a bug, and should be fixed, but there is no privacy breach when everyone sees their own IP address.

Jon Harald Søby (talk)08:23, 23 October 2019

I thought that everyone saw my IPv6 address in this page, which then does not doisplay the same thing for everyone. Anyway these entries are spurious, It reveals that there are effectively lot of logs being made for non-sense account creations by a bot, which then gets rapidly reverted. I suspect this occurs each time we connect on the site. But in fact I tried to disconnect and waited for some minutes before revisiting once, then wait for other minutes, and come back later to login: 3 actions are logged. Any visitor from any IP may have an IP account instantly created, and logged, even if that accoutn is not used at all for any write action, jsut simply visiting. This means that this site is easily attackable: you can have lot of logs filling your disks and the database, and the site won't resist at all. This may explain why the site is sometimes SOOO long to refresh itself and has many antique statuses that can take sometimes days to be reflected.

Verdy p (talk)16:20, 28 October 2019

username change request

Rename my account to "A Retired User". Thanks.

14:42, 24 October 2019

Done Done

Jon Harald Søby (talk)15:15, 24 October 2019

Seems that MediaWiki:Sanctions-empty should be worded "There is no sanction." instead of "There is not sanction."

Best regards,

AlNo (discuter/talk/hablar/falar)13:39, 22 October 2019

The source text to translate from English in MediaWiki:Sanctions-row-button-execute/en actually contains a Korean word (not sure if this really means "Execute" as an imperative verb, and no indication for the capitalization of the button). Please fix it, thanks. Verdy p (talk) 01:11, 22 October 2019 (UTC)

Verdy p (talk)01:11, 22 October 2019

Typo in English source for MediaWiki:Sanctions-content-placeholder/en. Please change sacntion to sanction. Thanks. Verdy p (talk) 01:02, 22 October 2019 (UTC)

Verdy p (talk)01:02, 22 October 2019

Translation right

Hi everyone! I'm from Georgian wiki. I'd like put some effort in wiki translation but as I figured I don't have rights yet. Can anyone help me out in getting this fixed? Thanks.

Rastrelli F (talk)10:11, 20 October 2019

I have given you the rights.

You are one of the few who signed up a long ago, before we had the new signup process, and didn't ask rights back then.

Nike (talk)08:23, 21 October 2019

This message cannot be correct in French: the adjective must be "actives" after "campagnes" (feminine), but "actifs" after "cours" (masculine).

The English source incorrectly assumes that adjectives are invariant. And the grammatical gender of nouns (like the replaced curse type) is variable depending on each language, do not assume they are simple to predict as this also depends on the choice of translated termes (ex. if instead of "cours", which is masculine with invariant number, we chose the synonym "leçon" or "leçons" in plural, which would then be feminine.

Note that even the plural, marked by the final "s" in adjectives "actifs" or "actives", may become singular depending on the number of campaigns or curses displayed. But as well don't assume that plurals are always fomed using a final "s". If needed pass a number parameter to allow us to use. As there's no number parameter, the unknown number is assumed to be plural (for most frequent cases except initially for a very new program or campaign which is still incomplete if it's limited to only one short course of about half an hour to complete or a single wiki page to read or review).

Please split this message in two versions, one per type, don't use such patchwork. And its not simple to find another way to translate a <adjective+noun> phrase (note also that the order is swapped to <noun+adjective> in French and other languages).

Verdy p (talk)22:24, 20 October 2019

[critical bug] MediaWiki:Withoutinterwiki-legend/fr : translation mixups: updates are going to the wrong page

Translations are sent to the wrong page. Trying to set them correctly, the submission is accepted, but when we refresh the page, we still see an unrelated message, not for this resource, and no change is applied (and no error ever displayed).

And if we look deeper, we see that what was submitted has in fact changed another page, creating a mixup, which then affects multiple other pages.

Very probably problem of index corruption (page or version ID's) in the database (I think there are duplicate ID's in some tables that should be unique), or a previous bad use by some prvilege admin of native SQL update.

As well the histories are mixed up across pages.

A maintenance should be performed to check the database integrity (notably check all table indexes).

It is also likely a problem of the background job queue, which seems to be stalled (recent changes are not fed correctly, statistics are out of sync, page counts are wrong...)n or its backlog of pending jobs is too large, or there's a lack of storage on the server.

Verdy p (talk)14:08, 10 October 2019

I just opened the page MediaWiki:Withoutinterwiki-legend/fr and it really shows the unrelated text, but clicking on "Edit" shows the text correctly.

Vlad5250 (talk)14:51, 12 October 2019

This was a real bug ( and is what is referenced by the site notice at top. It was affecting stince the beginning of month. The bug was a caching bug on the server. Still it affects some resources displaying incorrect "fuzzy" state (yellow icon) which seem to reoccur again. The issue was real and very strange. Its resolution is partial, as some other glitches are still occuring; the resolution seems to be non definitive because the impact is still not well understood. That's why the site notice at top remains.

Verdy p (talk)10:02, 13 October 2019

Quite certain that these issues started appearing since our deployment last Wednesday (8th Oct, 2019). We should not be seeing this issue on twn any more, but if you do, please ping on the Phab ticket or here.


Abijeet Patro (talk)06:22, 14 October 2019

Actually this started around September 24-26: many edits made after that date (or even reviews) were affected. And this continues even if caches were tentatively purged.

See for example with a new incorrect edit saved based on the wrong unrelated message:

As long as the new patch for disabling the use of Memcached (by Fuzzybot and other background jobs, including bots exporting data or importing data from external sources) is not applied here (it is still being tested by Mediawiki developers, hoping to find the effective origin of this bug), we still see those bad data. It seems that there's a design bug in how multiple APIs are working together across multiple services, multiple hosts, and in very different security contexts.

The dates of 24-26 September does not match the 8 October deployment. Something occured earlier that had unexpected impact. For now there's no clear isolation of the bug, and there are propably multiple levels of unchecked assumptions between the various components, maintained separately but with a sequencing of events that may have changed and were not supposed to be out of sync or occuring in different orders, because they were not covered by any existing unit tests.

However the bug seems related to a probable bug in internal memory management in PHP for "function closures" (a very tricky piece of code in PHP). The PHP engine effectively used may also have an effect (for example Wikimedia is currently actively working on coming back to PHP7 instead of HHVM, and the past switch from PHP/Zend to HHVM had already caused similar problems some years ago, because PHP is still not defined with very strict semantics). As well there are strange bugs in Memcached itself (still using unsafe assumptions about memory allocation made by C compilers, plus the effects of some deployed mitigations in processor firmwares, used to solve 90% of problems while also adding their own few % of problems).

Thanks Wikimedia works in improving the unitary tests and give more powers to linters to detect false assumptions. But there are tons of compiler/linter warnings to check now: some early solutions to detect them can cause some parts of the software to be simplified, changing the behavior that was previously just "unspecified" but worked as expected. Ideally MediaWiki should be tested by running it on very different architectures and OSes. This is not really the case, but it would help detect more unspecified behaviors and isolate more bugs, while enforcing better software quality by improved portability. However Mediawiki is highly develkoped now in terms of pure performance on the existing and very costly Wikimedia architecture.

But the bug T235188 is now proven to affect also Wikimedia wikis (including Commons, Meta-Wiki and Wikidata, but also some Wikipedias that use the translate extension for some local project pages or for running some tools or because they need to support pages with several orthographies when automatic transliterators are not reliable enough).

Verdy p (talk)22:21, 15 October 2019

duplicate word in Wikimedia:Whowrotethat-tour-welcome-description/en : "Activate the the tool from the sidebar. ..."

Verdy p (talk)17:02, 14 October 2019

I have submitted a pull request to fix this.

Jon Harald Søby (talk)12:16, 15 October 2019

The pull request has been merged now, so it will appear here next time the source messages are imported.

Jon Harald Søby (talk)17:12, 15 October 2019

[bug] Translate UI - wrong placement of circled accelerator keys

Translate UI- wrong placement of circled accelerator keys.png

Accelerator keys in circles displayed in the Translation UI are incorrectly placed. They should not collide with the editable text area where they obscure the text being edited. Ideally they should be placed just below the bottom of their border box, with enough margins, and not above the top border.

And the surrounding circles (actually boxes with large paddings and rounded corners) are too large, given they are also completely opaque: there's no need to have so large paddings.

Finally they should probably be visible only if the input focus is inside the text area, and probably only when we hold the [Alt] or [Super] key (depending on the browser's UI for its platform) to use them by pressing the displayed key (one digit or letter). Without this focus (flashing caret or current text selection) in the editable text area, the accelerator keys should have no effect and should then not be displayed at all. In fact most users will prefer clicking (or tapping on a tactile screen) the suggestion boxes to insert their suggested text into the text area at its current input position.

Now if you zoom in/out with the browser their placement is even worse. They are in fact absolutely positioned in the window instead of being relatively positioned, and their computed absolute position is completely wrong.

Verdy p (talk)01:53, 9 October 2019

They are only visible when one presses ALT. Sometimes they get stuck if we don't key keup event (such as when ALT+Tabbing to another window), but pressing ALT again will make them go away.

Nike (talk)12:55, 9 October 2019

No, they are permanently on screen... Pressing ALT or releasing it does not change the display. This was probably displayed on just a few browsers, but does not work in Google Chrome (the most widely used browser in the world) in Windows (though I don't think this behavior is just tied to Windows).

I found that the bug occurs sometimes after pressing ALT+TAB to switch to another application in Windows, and then returning to Chrome, also with ALT+TAB or with a click. The release event for ALT key is no longer detected, even when pressing and releasing ALT again, or it has no effect for objects already in the interface. Note that there are still multiple warnings displayed in the Developer console, including deprecated interfaces in several component libraries, related to jQuery unsafe/deprecated APIs ,or APIs in Mediawiki itself when they hook some event handlers; may be the same handler has been registered twice or registered in a "lazy" way, possibly the ALT release event is registered too late and not bound correctly in all closures, or this does not work with international keyboards (if the Alt key is confused with AltGr; it may also be incorrect detection of Chrome for Mac keyboards when we use Windows).

I've not seen such issues in other websites using jQuery, where we can safely use common Windows accelerators like ALT+TAB to switch between multiple open windows. And I have a very minimalist number of browser extensions (I have even disabled several extensions preinstalled by Google in Chrome for Windows, and not allowed Microsoft to install its own extensions into Chrome).

There's no such issue if I use Edge Beta (Chromium-based), which is using dramatically less memory than Chrome and is more power-efficient, and loads faster, I'm about to switch to Edge Beta if Microsoft ever releases it instead of its current home-brewed Edge which is an horror breaking many sites.

And anyway the fact that their position is very wrong and is even worse with browser zooming (where circles are going to higher positions when the text and boxes are shifted down when the zoom lever is larger) is a sign that jQuery or similar APIs are wrong, or make unsafe assumption.

Verdy p (talk)13:22, 9 October 2019

An Error in

When I am trying to translate that in Turkish, the error gives...

Failed to save translation: This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Protect sensitive pages #2

Are you guys going to fix it?

BaRaN6161 TURK (talk)09:20, 10 October 2019

Thanks for reporting. This abusefilter rule is only a workaround. The actual solution is to mark this message as "ignored", because it does not need to be translated.

Nemo (talk)10:08, 10 October 2019


BaRaN6161 TURK (talk)10:55, 10 October 2019

Deleting unused strings from translated language files

Hi guys,

I'm posting this here since you don't seem to be responding to @translatewiki mentions in GitHub pull requests...

The question is, is it OK to directly modify foreign language files (translated and committed by translatewiki) ? Would that have an impact or cause problems, and if so, what ?

Specifically, this relates to the following commits in the above-mentioned PR:


-- Damien10:08, 27 September 2019

If you delete the English strings (the source strings), the next export will take care of deleting the translations as well. As for changing translations, it's better to do it here on, because then the translators can see what you're doing and why.

Nemo (talk)10:27, 27 September 2019

Thanks for your reply.

Please note that the actual translations have not been modified at all. Changes to foreign language files are :

  • removed unused strings ==> From your reply, I understand is that by deleting the string myself, I'm only anticipating on what would do anyway, so that should not cause any issue. Is that right ?
  • moving strings around in the file (without changing anything) ==> I assume this has no impact, can you confirm ? (note, this was done to have consistent ordering of strings across all language files)
  • renaming a language string (i.e. not the translation itself, but the string's identifier) ==> this is the one I'm really not sure about. I would think yes based on what the FAQ says, but since it also mentions informing the staff...
-- Damien07:28, 3 October 2019

Hi Damien,

  • removed unused strings --> This should be fine but would recommend doing it only for the source language and not the foreign language files.
  • moving strings around in the file --> Again no issues here and should be fine.
  • renaming a language string --> This is also fine. Thanks for the ping regarding this. We will review and do the necessary renaming on our end, which is quite easy.


Abijeet Patro (talk)07:42, 7 October 2019

Hello Abijeet,

FYI the pull request has been merged a few minutes ago, feel free to do your magic at your next convenience.

Cheers, Damien

-- Damien08:32, 9 October 2019

Hi Damien,

This is done. Translatwiki now has and tracks the renamed language keys.


Abijeet Patro (talk)15:13, 9 October 2019

Mobile version of main page

I would like to know to set-up a mobile version of the main page on Currently it shows the whole main page, but I would like it to only display certain paragraphs. Any help would be very much appreciated (main page).

Servien (talk)23:53, 5 October 2019

I am afraid this is not the right place to ask for such help. Hopefully someone will post a reply pointing you to the right direction, as I don't know whether his is related to Mobile Frontend or something that can be done in the wiki itself.

Nike (talk)12:59, 9 October 2019

Saving the translation failed

I was trying to modify two pages content but I was prevented:

  1. MediaWiki:Mainpage/ary from {صفحة لولا} to {الصفحة الرئيسية}; I was prevented for the fllowing reason: Established main page translations cannot be changed directly as it would disrupt wikis using the old translation.
  2. the outdated translation of MediaWiki:Copyright/ary because I don't have the Permissions for editing of sitewide CSS/JS/JSON files.

What can I do to fix the above translations?

SADIQUI (talk)21:38, 4 October 2019
  1. You can't modify MediaWiki:Mainpage/ary because AbuseFilter 3 prevents edits from you, simply request changes on here (like you already did, so just wait until someone with the needed rights does this)
  2. Similar to above, simply wait until someone with the needed rights does your request action.
Tobi 406 (talk)21:22, 5 October 2019

Request username change

Rename my account from "A2093064" to "Xiplus". Thanks.

A2093064 (talk)04:32, 28 September 2019

It suggests that you can edit (or delete) layers, but really the corresponding button in VisualEditor's map dialog currently allows editing all geometric features present and there are no layers to edit. A layer in sense of managing geometric features is usually a group of features.

Pikne11:16, 19 December 2016
First page
First page
Last page
Last page