Talk:Extension default namespaces

Jump to navigation Jump to search

About this board

Dinoguy1000 (talkcontribs)

When looking through this page, I've noticed a tendancy for many extensions to add their namespaces starting at a multiple of ten, where no other extensions already had any namespaces in that block of ten numbers, thus effectively "claiming" the block. This seems like good practice to me; should we codify it as a general recommendation on this page?

If so, it can be retroactively applied to the extensions already documented here that don't align themselves witha multiple-of-ten namespace number; the only documented problem areas are the 48x and 80x/81x numbers (plus the 10x/11x, but that's to be expected given how low the numbers are). This could be done simply y reformatting the page to designate according to groups of ten numbers, instead of by extension, while more-or-less leaving the problem ranges alone.

(Note that this would be a really good time to point out extension-added namespaces that aren't documented here yet, regardless of whether they'd create more problem ranges or serve to reinforce the observed pattern. =) )

Legoktm (talkcontribs)
Dinoguy1000 (talkcontribs)

Thanks for the link; I've added all of the results of that which weren't already listed, as well as updating and adding notes as appropriate to what was already on the page. Interestingly, several extensions aren't in that result that I would expect to be, e.g. Proofread Page.

MGChecker (talkcontribs)

I think this idea has some value, as it allow more flexibility for these extensions in the future and makes this site more overseeable.

However, we have to put into consideration that this comes at a cost: We're exhausting our low numbers much faster. (While I just wanted to point 48x as an example, where this happened, I just saw what JsonConfig and Graph did and would like to lower the severity of this point.)

It's probably a good idea to provide a mechanism to formally get extension namespace numbers approved in the range between 20x and 99x (Criteria: Not reserved for other things, not unnecessarily confusing) to avoid unnecessary conflicts and confusing fraction like with the JsonConfig extension.

For design, we could use something like

Not counting the 3xx range, I get:

  • 25 taken
  • 2 conflicts
  • 52 free

Considering how much is free, I would consider 3xx as reserved by Wikia, with conflicts at 30x and 35x.

Dinoguy1000 (talkcontribs)

If the history of this page, and the link provided by Legoktm above, are any indication, extensions which define new namespaces are only rarely created, so the overall rate of namespace ID use should be very low, and in the long run may be balanced (or even entirely overshadowed) by archival of old/unmaintained/etc. extensions, so I'm not sure exhaustion of numbers is really much of a concern. Furthermore, while namespaces starting at 3000 are currently recommended to be reserved for sites instead of extensions, I find it pretty unlikely that any site following the guidance presented on this and related pages is going to use more than a thousand custom namespaces, and there are a handful of extensions already using namespaces starting at 5000/10000, so if we ever do manage to completely fill the <3000 numbers, we can always jump up and start on the 5000+ ones.

While Wikia have historically stuck with namespace numbers in the 300s, more recently they haven't been shy about using other numbers, including up into the thousands. More generally, they're obstinately sticking to an ancient version of MediaWiki (1.19), and as a result have to modify any extensions they want to use anyways, where they aren't just writing their own in-house extension (since modern extensions won't generally support such an old MW version), and they aren't afraid to change custom namespace numbers defined by these extensions for their own purposes. And looking more broadly, there have been rumblings that Wikia plans to move away from MediaWiki altogether at some point. So all in all, I don't think we should really worry about what Wikia does or does not do these days.

This post was hidden by Dinoguy1000 (history)
Legoktm (talkcontribs)

My main question is how many extensions have more than two namespaces (subject and accompanying talk)? And how common is it for an extension to add extra namespaces after already having two?

I have no objections to this proposal, reducing the potential for namespace conflicts seems like a good idea.

Dinoguy1000 (talkcontribs)

Per your above comment, the page should currently list just about all custom namespaces added by WMF-known extensions. The list could probably be made much more complete if namespace data was collected and made available on WikiApiary, though.

Reply to ""Reserving" blocks per extension?"
Vanished user Xorisdtbdfgonugyfs (talkcontribs)

Please provide at least one place where to report problems with the localized name of the name space.

Kghbln (talkcontribs)

May you elaborate? Which kind of problems?

Vanished user Xorisdtbdfgonugyfs (talkcontribs)

First, please provide a section that any reader can read what to do if has found a translation problem. At least inform the reader that can "talk" here...

I found a problem in Greek translation of TimedText namespace. (Ok, I am not sure if the problem is with the namespace translation but probably is). The following:

https://commons.wikimedia.org/wiki/TimedText:%C2%BFQu%C3%A9_es_Wikipedia%3F.ogv.el.srt

prints: Ελληνικά υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv

the right should be one of:

  • Ελληνικά: υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv
  • Ελληνικοί υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv
  • Υπότιτλοι στα ελληνικά για το βίντεο: File:¿Qué es Wikipedia?.ogv

Thanks.

Kghbln (talkcontribs)

I am not sure if we should still tell users that every namespace has a matching talk namespace that may be used to address issue etc.

Since your issue relates to the Extension:TimedMediaHandler it will be best to create a task on Phabricator to make sure the developers see it early on.

Vanished user Xorisdtbdfgonugyfs (talkcontribs)

First many hanks for the quick answer. But there is no way (even in phabricator, which was my second many-hours-serch) to find where to announce such a problem (till now I was used to use MediaWiki namespace to change -as a sysop- or its talk page to announce and maybe this was my problem at first).

With "At least inform the reader that can "talk" here..." was referring to this exact talk page(Talk:Extension default namespaces). Some users do not comprehend all.

We must have in: Extension default namespaces some explanation on how the localisation works on them. Even new sysops do not know everything. And many simple users willing to make corrections do not know where to search.

Kghbln (talkcontribs)

This page has nothing to do with the localization of default namespaces I'm afraid. This page tells programmers which namespaces are taken.

In case you would like to learn how namespaces are localized and translated you will want to have a peep here. I will add a note.

Reply to "localised names for namespaces"

Please define a serious range for user

10
189.100.56.101 (talkcontribs)

A site administrator need free and secure namespace ranges to use for your site... There are a big contradiction with "The namespaces in 100-199 are reserved for site-specific namespaces, and should not be used by extensions".

Please, if it is a serious standardization, express an ensured range or set of ranges, that not will change tomorrow. EXAMPLE: "dear admistrator, sorry, you can ensure after 2015 with {130-159, 150-159 , 180-199}"

Please say to extension programmers to move out from the reserved range.

Kghbln (talkcontribs)

This information is at the very end of this page. I added a note at the top to get the message across more visibly. Guess this is ok. Cheers

Loonybomber (talkcontribs)

The manual refers to starting at 200:

// Define constants for my additional namespaces.
define("NS_FOO", 200); // This MUST be even.
define("NS_FOO_TALK", 201); // This MUST be the following odd integer.

It seems natural to put namespaces that are not used for extensions in this area because it's not between 1-199 and conflicting with namespaces for well known extensions beginning at 300.

However, Extension_default_namespaces#Extension_default_namespaces.23ID_3000.2B states that custom namespaces should be above 3000.

What's the best range for systems administrators to place custom namespaces?

I'm going to try starting at 3000 now to resolve the Invalid or Virtual Namespace -1 errors when I try to create forms with Semantic and Semantic-Forms. After changing namespaces I won't forget to run maintenance/update.php and then run rebuild and update via Special:SMWAdmin.

hrm, first time using visual editor [[Evar]!] ... tried to cut and past code from main page and it wouldn't work:

Note Note: Namespaces using numbers from 3000 and higher are meant to be used by system adminiatrators to define their custom namespaces. Thus extension developers should not use this range.

It is confusing.

| using numbers from 3000 and higher.

MWJames (talkcontribs)

> I'm going to try starting at 3000 now to resolve the Invalid or Virtual Namespace -1 errors when I try to create forms with Semantic and Semantic-Forms.

I'm not sure what issue you have with SMW's default namespace but SMW NS range has been used fairly early before the whole NS number n....... came up therefore if you leave the NS as deployed you should not face any issue.

In case you want to use a different NS then you advise to read:

Kghbln (talkcontribs)

I have revised the manual. I do not see a connection with SMW either, however the tips MWJames provided should help you out of your misery.

Loonybomber (talkcontribs)

Thank you. There is so much to look into.

Yaron Koren (talkcontribs)

That "Invalid or virtual namespace" error message has nothing to do with custom namespace numbers - it's an error brought about by a combination of certain versions of ConfirmEdit (maybe the ones that come with MW 124 and MW 1.25) and Semantic Forms. I'm hoping to be able to find a patch to fix it; though I think with the very latest version of ConfirmEdit, it's no longer a problem.

Albert Ke (talkcontribs)

I just want to confirm that this is a 'SF' - 'ConfirmEdit' conflict that started to occur for me with MW version 1.25.1 (that includes ConfirmEdit 1.3). Removing confirmedit (although not something I wanted to do) solved this issue. I'm using SF 3.2-alpha (f6c8e0b) and SMW 2.2.1

Kghbln (talkcontribs)

See also this post. Both extensions should play now for MW 1.25 with their latest versions.

Loonybomber (talkcontribs)

Thanks Kghbln. The manual is much clearer.

I'm not qualified to chime in on the namespace issue; the namespace issues magically disappeared.  :)

Reply to "Please define a serious range for user"
Peachey88 (Flood) (talkcontribs)

I hope everyone knows there's nothing binding about this page. It's just a page for extension authors to list their custom namespaces in order to avoid conflicting. Declaring 500-599 will only be used for custom site namespaces and any extension using them is wrong is just silly. Like Jack points out, SocialProfile has been using its 500-range namespaces for quite some time, and there's nothing wrong with this. He should be allowed to add his namespaces to the list like every other extension. Looking at the discussion above, I hardly call that a consensus. It's barely even a discussion, coupled with the fact that this is a very very low traffic talkpage. I don't see any developers involved in the discussion, and I don't remember the discussion being advertised on wikitech-l or mediawiki-l as I would expect.

This post was posted by Peachey88 (Flood), but signed as ^demon.

Peachey88 (Flood) (talkcontribs)

Agreed, this page has always only been a guide, never a rule. It's intended so that extensions adding new namespaces can try to collaborate and avoid forcing people to override default namespaces all the time because of extensions always overlapping. Every extension that defines a custom namespace should always have some method of configuring the extension to use different namespace numbers. And sites can define whatever manual namespace numbers they want and force extensions they install to use numbers that fit around that. The idea that 500-599 should be site specific is ridiculous even at a logical level... 1000+ would make more sense, 2000+ if we have to. Personally I have a site namespace of my own sitting at 112-113. Btw here Manual = 100, Extension = 102, API = 104. Frankly the 100-199 range has always made much more sense to me for site-specific namespaces. SMW is just an oddity which can have a config option set or we can just use the free ones around it.


Personally the thought that we should do away with this whole hardcoded namespace thing has been lingering in the back of my head for awhile. We really need some way for an extension to request a namespace on a first-come first-served basis such that after a number is reserved another extension will always get a different number even if the previous extension was uninstalled.

This post was posted by Peachey88 (Flood), but signed as Dantman.

Peachey88 (Flood) (talkcontribs)

Wow... waitasecond, I even commented on just that right on this talkback 3 years ago. Btw, defining a range for Wikia to use without asking or even telling them feels like being the kid that draws a line in the sand taking 3/4 of the sandbox to himself then throws a temper tantrum when the neighbour's kid walks over it and tries to have fun with his other friends.

This post was posted by Peachey88 (Flood), but signed as Dantman.

Reply to "What's the big deal?"
Peachey88 (Flood) (talkcontribs)

Apparently my edit was reverted because of some conflicts. Like I wrote in my edit summary, the namespaces conflict with some other extensions' namespaces and site-specific namespaces, but I'd prefer if the other extensions would change their numbers because social tools have been using these namespace numbers since 2007 or so.

Having a site-specific range (500-599) is just silly IMO, sites can and should use whatever NSes aren't registered; who says that custom namespaces indexes can't start from 1000+? I'd like to change TimedMediaHandler's custom NS from 700 to 710 or something; that should be a relatively simple and uncontroversial change, I hope.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

Peachey88 (Flood) (talkcontribs)

I did the revert. I read your subsequent response on my talk page. Thanks for agreeing to discuss the issue. Please note that the reservation of range 500-599 was open to discussion for 11 months (see preceding section). There were no objections, so we decided to act. The range is now reserved. Manual:Using custom namespaces was altered accordingly. Without a general, prior agreement to withdraw the reservation, I feel it should remain in force. Otherwise, what is the purpose of a registration system?

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

Peachey88 (Flood) (talkcontribs)

I understand the point about the discussion regarding site-specific namespaces being open for almost a year, but the point is that I didn't read it as I don't actively monitor it, and I'm quite sure that many other developers didn't read the discussion either.


Kghbln suggested that the discussion about site-specific namespaces should be raised on the appropriate mailing lists, which in this case would've been wikitech-l, the development mailing list (yes, mailing lists are so Web 1.0 but they're also how we do things). Many developers, whether they're core, extension or third-party, are subscribed to that mailing list, so by posting there your message will reach the intended audience and you can claim consensus on your changes.


As for the question regarding the purpose of this page, it really depends. To be exact, while many developers might use this page, it still doesn't change what's in SVN for the time being, BlogPage is using namespaces 500 and 501, no matter what this page says.


Ignoring everything and anything related to site-specific namespaces and namespaces indexes 500-599, what about the other namespaces? While Wikia certainly has a lot of custom extensions and some of them do define their own namespaces, I feel that registration should happen on a per-extension basis instead of reserving a range to Wikia; are their developers even aware of the fact that they had such a reserved range registered on this page?


Extension:NagiosConfig, which has reserved namespaces 600-609, is marked unstable and the latest edit to the extension page has been done on 27 May 2011 and its source code isn't available; Extension:FanBoxes is older, it is marked as stable and it certainly works with MediaWiki 1.16.0, so I feel it should get the namespaces 600 and 601, as it already uses them in the code.


Considering that Extension:TimedMediaHandler hasn't been deployed yet on Wikimedia wikis, I don't think bumping its namespaces from 700 and 701 to something like 710 and 711 or something will be very controversial.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

Peachey88 (Flood) (talkcontribs)

I wish I could answer your questions, or point to someone who's responsible for the design of the registration process. I think that most of us are simply following the instructions at the top of the page: 'To prevent conflicts in new namespaces added by extensions, please "register" your extension's namespace here.'


If we take care to do that, then things should work out okay.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

Peachey88 (Flood) (talkcontribs)

I've changed TimedMediaHandler's namespace ID in r97550. Assuming it doesn't get reverted or FIXME'd within the next 5 days or so, I'll be changing it here and readding my changes back.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

Peachey88 (Flood) (talkcontribs)

Please do not alter the reserved range 500-599. It was duly registered by prior agreement and the changes you point to would alter it. You cannot act alone in this matter and disrupt the work of others. I recommend you speak to someone in authority. This is a clear conflict, and it arose because you failed to observe the rules in the first place.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

Peachey88 (Flood) (talkcontribs)

The "prior agreement" was based on the assumption that no extensions used that range, which as it turns out was incorrect. 500 was already in use by the extension before that "agreement" between three people occurred. I've checked Wikia's repository and it was indeed using namespace 500, before your attempt to "reserve" the range. This is not a "future" extension, it's a preexisting extension that has been cleaned up and added to the official Wikimedia repo.

This post was posted by Peachey88 (Flood), but signed as Reach Out to the Truth.

Carlb (talkcontribs)

The de-facto "prior agreement" was 0-99 reserved for MediaWiki internal namespaces (of which 0-15 are currently in use) and site-specific namespaces on 100+ since at least 2004 (MW 1.04 was limited to one-byte namespace numbers). In the half-dozen years which followed, many wikis were deployed with site-specific namespaces just above the internal ones or starting at 100+ like the instructions told the site admins to do.

Unless every wiki which deployed "by the book" using 100+ as site-specific is now expected to renumber all of its custom namespaces to some other range (something which we do not have automated tools to do, short of raw SQL UPDATE commands, as a proper namespace editor never did make it into MW 1.7+ core code) there should be no "reservations" of namespaces in this range to extensions. Quite simply, the designation of 100+ as the site-specific range pre-dates the changes to extensions like DPLforum to hard-code them to namespaces (there was nothing special about 110 or any other namespace number in the original 2005-06 implementation of DPLforum, this is a recent addition breaking existing sites).

If you want to "reserve" some block, use one which hasn't been assigned to site-specific namespaces since at least 2004, please.

Reach Out to the Truth (talkcontribs)

If those people want to install an extension that uses namespace numberss that conflict with their wiki's existing namespaces, they can configure or modify the extension locally so it uses different namespace numbers on their wiki. But changing it upstream would adversely affect way more users.

The only namespace numbers that can really be considered "reserved" are those that are already in use on a given wiki.

Carlb (talkcontribs)

The issue with DPLforum is that it was *not* hard-coded to any one specific namespace before July 2011; furthermore, once a hard-coded namespace was added, the one chosen was right in the middle of the most-used section for site-specific namespaces (by 2003 convention, 16-99 are for core MediaWiki expansion, 100-254 are free for site-specific use).

Some of us have had DPLforum deployed on high-traffic sites since 2006 (it was developed by user:Algorithm for Uncyclopedia in late 2005) and are now seeing configurations break because this hard-coded 110: is not the Forum: space on the wiki (prior DPLforum versions were manually configurable to any site-specific namespace) and in a few cases is already, predictably, being used for something else because that's where we've been told since 2003 to put site-specific namespaces, 100+

Upgrade DPLforum, watch wiki break in some manner because something was hardcoded after the fact (July 2011) into a space which should never have been used in this manner (the 100+ range allocated in documentation as site-specific, a convention which was in place about eight years prior).

If anything, extensions should not be hard-coding namespace numbers on the blind presumption that they aren't already in local use. At a minimum, there should be some means to override the namespace selection, either to point to a vacant namespace or to match a namespace already configured by the site for use with a prior version of the same extension.

The 2003 allocation of 100+ to be site-specific namespaces predates the after-the-fact 2011 hard-coding of 110: as DPLforum.

Using the extension default namespaces as a space where anyone can edit, claim any existing site-specific namespace as suddenly now belonging to one extension, then complain that it's somehow the fault of the system administrators of existing sites already using that namespace when things break is not the answer. Extension writers have to realise that their code has to be installable on sites where any given namespace, especially the 100+ site-specific area, is likely already in use and stop hard-coding namespace numbers in a non user-configurable manner.

Even the painfully-obvious "well known port" allocations in the TCP/IP world are presumed potentially in use (that's why you can put "Listen 8080" in Apache's httpd.conf if :80's already in use by another web server on your machine...) so why encourage the less flexible approach of hard-coding namespaces with no easy reconfiguration mechanism here?

Reach Out to the Truth (talkcontribs)

Oh. Well, no one was discussing DPLforum in this thread until you did. I make no judgments regarding the namespaces declared by that extension, nor do I wish to.

Reply to "Social tools' namespaces"

Reservation of numbers for site-specific namespaces 500 - 599

7
Peachey88 (Flood) (talkcontribs)

There is a note: "Site-specific custom namespaces are generally assigned in the 100 to 199 range. I would recommend staying out of this range for anything to be defined by an extension."

These numbers are however used by Semantic MediaWiki and Semantic MediaWiki Extensions. It would indeed be very useful to have numbers reserved for site-specific namespaces. According to http://www.mediawiki.org/wiki/Extension_namespace_registration numbers from 500-599 are still free. Would'nt it be a good idea to really reserve this range for site-specific custom namespaces?

This post was posted by Peachey88 (Flood), but signed as Kappa.

Peachey88 (Flood) (talkcontribs)

Why not. This would help providing wiki administrators with a reliable range not to be used by extension. However my attempt to at least keep them of the range 100-110 failed recently on Manual:Using custom namespaces. Cheers

This post was posted by Peachey88 (Flood), but signed as Kghbln.

Peachey88 (Flood) (talkcontribs)

is someone responsible for this process and can enter this reservation on this page (Extension_namespace_registration)?

This post was posted by Peachey88 (Flood), but signed as Kappa.

Peachey88 (Flood) (talkcontribs)
Peachey88 (Flood) (talkcontribs)
Peachey88 (Flood) (talkcontribs)
Peachey88 (Flood) (talkcontribs)
Reply to "Reservation of numbers for site-specific namespaces 500 - 599"

Sites using different numbers for the same extension

2
Peachey88 (Flood) (talkcontribs)

Do Wikia sites using 302 etc, in place of standard SMW's 102 etc, have any likely consequent problems?

This post was posted by Peachey88 (Flood), but signed as Robin Patterson.

Peachey88 (Flood) (talkcontribs)

Theoretically it should not happen, since extension developers now know that Wikia, which represents quiet a large "wiki universe". Choosing the early 300+ does not make sense.

This post was posted by Peachey88 (Flood), but signed as Kghbln.

Reply to "Sites using different numbers for the same extension"
Peachey88 (Flood) (talkcontribs)
Peachey88 (Flood) (talkcontribs)

No, since SMW is not installed on this wiki and a version prior 1.0 will not be installed in the future. Cheers

This post was posted by Peachey88 (Flood), but signed as Kghbln.

Reply to "102"
Peachey88 (Flood) (talkcontribs)

I'd be very hesitant using "non-absurd" numbers in extensions. Someone could easily be using the number 140 in their wiki configuration for an extra namespace. Using negative numbers or absurdly large numbers would be a better solution. Also, if namespace 140 = Deletion discussion:, does that mean 141 = Deletion discussion talk:? And if not, what is 141? Will it be reserved? The negative namespaces are negative because they don't have a talk counterpart, which is also something to consider when having extensions reserve numbers.

This post was posted by Peachey88 (Flood), but signed as MZMcBride.

Peachey88 (Flood) (talkcontribs)

Negative numbers are reserved for special case pseudo-namespaces (special and media), DO NOT USE THEM UNDER ANY CIRCUMSTANCES for actual namespaces -- things will break.

All non-pseudo namespaces in the current system come in [subject, talk] pairs such that subject mod 2 = 0 and subject + 1 = talk. If you violate these constraints, things will break.

Namespace numbers between 0 and 99 are implicitly reserved for MediaWiki's internal use, and no custom or extension namespaces should be assigned there to avoid conflicting with future additions in MediaWiki.

Site-specific custom namespaces are generally assigned in the 100 to 199 range. I would recommend staying out of this range for anything to be defined by an extension.

The 200 to 299 range is probably a good place to register extension namespaces.

I would recommend against "absurdly large" numbers as those would be annoying. ;) However something more like, say 2000 might be just fine.

This post was posted by Peachey88 (Flood), but signed as Brion VIBBER.

Peachey88 (Flood) (talkcontribs)

Why don't we create some sort of real installation, or at least store namespaces somewhere else? Then instead of attempting to reserve namespace ids which may already be taken by a custom content namespace, or conflict with an extension that didn't know about this page, or was hosted somewhere other than here and thus not listed, we could instead just have extensions grab a free ns id and reserve it internally. It doesn't have to be real complex installation, just some sort of install.php maintenance script, with a Special page counterpart for those without SSH. Just for small things like reserving ns id's.

This post was posted by Peachey88 (Flood), but signed as Dantman.

Carlb (talkcontribs)

The idea of extensions reserving any namespaces in the low-100's was an ill-advised move which should be abandoned as site admins have been told since the earliest MediaWiki versions (such as 1.4 and earlier, which had one-byte namespace numbering) that this was the range to use on the off-chance that MW's internal namespaces might expand into the 16+ range (they never have, the internal namespaces we had then we have now).

Extensions like DPLforum (which used to be installable on any manually-created namespace) are now going to $wgExtraNamespaces and registering some arbitrary number (110) themselves by automated means (as if they owned it outright) - even on sites where it is already in use. I just finished renumbering about a dozen wikis which had 'Forum:' elsewhere in the low-100's or on some number just above the MW built-in messages. A few had 110 already in use for something else, dropping visitors into the wrong namespace when they attempted to use the forums.

DPLforum was working perfectly well on all of these wikis since 1996 on some other namespace (various, MW 1.06 through 1.17, upgraded over the years) but the version currently in trunk (with MW 1.20) inserts 110=>Forum and if the original site had it somewhere else, things break.

The administrator installing these packages needs to have the ability to choose a namespace number (or at least not have one default to a number in the original site-specific range, with no check that those are already in use). Arbitrarily predefining one, especially one in the low-100's right in the middle of the range which had always been intended for site-specific namespaces, is asking for trouble.

DPLforum worked fine for years without forcing a selection of 110 as NS_FORUM. It should have been left that way.

Reply to "Notes"
B20180 (talkcontribs)

Hello; Have anyone can help me ?

I want to change Krung thep mahanakhon amon rattanakosin mahinthara ayuthaya mahadilok phop noppharat ratchathani burirom udomratchaniwet mahasathan amon piman awatan sathit sakkathattiya witsanukam prasit

in th.wiktionary and no.wiktionary into

กรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยามหาดิลกภพ นพรัตน์ราชธานี บุรีรมย์อุดมราชนิเวศน์มหาสถาน อมรพิมานอวตารสถิต สักกะทัตติยะวิษณุกรรมประสิทธิ์

because that is official full name but in this time have limit for Thai alphabet to change in full name.

Thank you. --B20180 (talk) 13:56, 19 January 2013 (UTC)

Nemo bis (talkcontribs)

I'm sorry, this is perhaps the fourth time I read your question but I've still not understood it. Could you explain better what you want to change exactly? What's that long sentence you quote?

B20180 (talkcontribs)

I and my friend try to change that page to กรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยามหาดิลกภพ นพรัตน์ราชธานี บุรีรมย์อุดมราชนิเวศน์มหาสถาน อมรพิมานอวตารสถิต สักกะทัตติยะวิษณุกรรมประสิทธิ์ but it have limit that can change to กรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยามหาดิลกภพ นพรัตน์ราชธานี บุรีรมย์อุดมราชนิเวศน... only.

so; have anyone can change that page to full name ?

Thank you. --B20180 (talk) 12:03, 21 January 2013 (UTC)

Kghbln (talkcontribs)

The maximum limit for a pagename is 256 bytes. I believe that you are crossing this limit and I am afraid that nothing can be done about it.

Reply to "Change the name in wiktionary"