Magnus wrote:
>For the naming conventions of cities, IMHO the
>important thing is that the different articles can be
>told apart ("Paris, Texas"). That Texas is in
>the US can be mentioned within the article.
I could not agree more. The whole idea of
disambiguation was to <i>differentiate</i> two
articles that would otherwise have the exact same name
and <i>not</i> to immediately give the average person
a geography lesson � this is information overload just
for a page title. Geographical and important political
information can, and should be stated in the first
line of the article. Technical matters such as ease
of linking and true disambiguation trump any overly
hierarchical naming scheme. Besides, there are already
hundreds of cities in wikipedia and probably thousands
of links to them and if you really wanted to give a
geography lesson you would probably want to list
section of continent too.
Our naming conventions state that names should be
chosen that have a <i>reasonable minimum</i> of
ambiguity. Therefore simply go up only to the level of
detail needed to differentiate one item from another
in preferably natural and mostly consistent manner
(consistancy <i>within</i> a particular country is
highly desirable).
For example: Americans are notorious for reusing the
same darn name for cities in several to a dozen
different states. Therefore, for the United States
[[city, state]] is fine. Most other countries don�t
have such rampant reuse of city names, so [[city,
country]] is fine unless there is a naming conflict
(or a noted exception: see below). Australia is a
matter to consider and could also be organized as
[[city, state]] � but only if the reuse of city names
is as bad a problem there as it is in the US states
(this goes for any other country as well).
Paris, Rome and a few dozen other cities are noted
exceptions � although we may eventually simply just
give these cities redirect priority so that [[Paris]]
redirects to [[Paris, France]] and the article
actually lives at [[Paris, France]] for nothing more
than consistency � but that would require some
tweaking of the software to make the existence of
redirects more obvious.
In short: KISS and follow the general trend already
establish by many other articles. With so many city
articles already in existence, it�s too late in the
game to start such a (re)naming rule � It might have
worked if it was started a year ago.
maveric149
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Could someone put on the upload page a note that this is not a file-sharing
system or a file storage area? I think people look for "upload files", find
our upload page, and upload things without realizing that this is an
encyclopedia.
phma
> One small problem here. What if there are two discrete entries
> (I'm struggling for an example here), one spelling of which has
> no diacritics and an equivalent spelling of the "same" word
> (yet with a diacritic) and a wholly different meaning?
That's no different from any other disambiguation job.
0
On Wednesday 19 June 2002 12:01 pm, Lee wrote:
> > If a name has diacritics, for instance [[Jose Ramos-Horta|José
> > Ramos-Horta]], avoid the diacritics when naming an article. If a
> > link has a diacritic, what page it links to depends on the
> > character set the browser is set to. A UTF-8 browser goes to what
> > looks to a Latin-1 browser as "Jos&itrema;&iques;&1/2; Ramos-
> > Horta", whereas a Latin-1 browser goes to an article whose title
> > has an invalid UTF-8 character.
>
> I think our general consensus is that there should be an article
> titled without diacritics, or otherwise Anglicized ("Goedel",
> for example), and that this article should be a redirect to an
> article with the real title, diacritics and all.
This would work in a perfect world in which the person making the
diacriticaly named article also made an ASCII redirect it, Lee. But
unfortunately this often isn't the case. Even worse is the fact that most
netcitizens don't know how to use their keyboard to make diacritics --
meaning most people searching Google won't use them and that linking directly
to these articles is unnecessarily difficult.
However, I proposed a similar anti-diacritics query on [[talk:naming
conventions]] some time ago but soon began to realize that this is a
technical issue that can be solved by the wikiware gurus. All that is needed is for the software to
treat the diacritic form and the ASCII equivalent the same. For example; é
and e could be treated as the same character for searches and for linking
(the Google issue might pose a problem though....). That way when somebody
searches for [[José Ramos-Horta]] by entering in Jose Ramos-Horta in the
wikipedia search engine they won't come up empty handed if nobody made an
ASCII redirect to the diacritic name.
Is this possible? Desirable? Or should we go with the original
anti-diacritics naming convention suggestion?
maveric149
> Does listing a user's contributions normally time out, even when
> bringing up an article doesn't?
The way it's implemented in the current code will often time
out, especially for some of us old-timers, because it always
fetches _all_ of a user's changes; every edit he's made to
every version of every article he's ever touched, so it's
likely to be a big result set. This is fixed in the new code.
0
>> I think our general consensus is that there should be an article
>> titled without diacritics, or otherwise Anglicized ("Goedel",
>> for example), and that this article should be a redirect to an
>> article with the real title, diacritics and all.
> This would work in a perfect world in which the person making the
> diacriticaly named article also made an ASCII redirect it, Lee. But
> unfortunately this often isn't the case. Even worse is the fact
> that most netcitizens don't know how to use their keyboard to make
> diacritics -- meaning most people searching Google won't use them
> and that linking directly to these articles is unnecessarily
> difficult.
That hasn't been a problem in practice; there seems to be a natural
urge among some folks to fix such things when they occur, usually
because one of the authors is obsessive about the diacriticals and
another is obsessive about Anglicization. If we have been slipping
up in our Anglicization task, we should simply pay more attention.
The more serious problem is the lack of standarization in HTTP POST
data, requiring the software to make assumptions that might be wrong
about the character set used for POST data. That's probably the
main reason we should be sure to have Anglicized titles, but it's
no reason not to also have native ones.
> However, I proposed a similar anti-diacritics query on [[talk:
> naming conventions]] some time ago but soon began to realize that
> this is a technical issue that can be solved by the wikiware
> gurus. All that is needed is for the software to treat the
> diacritic form and the ASCII equivalent the same. For example;
> é and e could be treated as the same character for searches and
> for linking (the Google issue might pose a problem though....).
> That way when somebody searches for [[José Ramos-Horta]] by
> entering in Jose Ramos-Horta in the wikipedia search engine they
> won't come up empty handed if nobody made an ASCII redirect to
> the diacritic name.
That would actually be quite easy; but it would also be wrong.
Some languages don't map meaningfully that way, or Anglicize by
other methods, and we don't want to make the search less useful
for people who _do_ know how to use their keyboards. The right
thing to do is make sure that ALL variations on any name appear
in the database, either as titles or in the text.
We actually did hash this out quite a bit, and I'm pretty convinced
that the present convention is the right thing. If some users
don't pay close attention to it, then help them out. We can always
add features to the search function later, but it would be missed
opportunity to throw away useful information when we gather it just
because some people have a hard time dealing with it.
0
On Wednesday 19 June 2002 12:01 pm, tarquin wrote:
> hello all.
> I'd like to volunteer for the moving of WikiProject & associated pages
> over to Wikipedia: namespace.
> before I do, though, could I ask for thoughts on a different name?
> I suggest something like "presentation schemes", to stand alongside
> "naming conventions"
How about simply [[wikipedia:projects]] (or the singular) for the main uber
article and then [[wikipedia:project {name}]] for the specific project? Any
ideas for showing hierarchies? Although this type of question really isn't a
policy one so we should continue this discussion at [[talk:WikiProject]].
> alternatively, should "naming conventions" be absorbed into
> WikiProjects? the original proposal is about naming schemes as well as
> consistent content presentation.
No I don't think this would be desirable. [[Wikipedia:naming conventions]] is
(more or less at least) a policy article and the WikiProject idea has never
been much more than a way for wikipedians to collaborate on a certain set of
related articles (which hasn't been used much BTW). Only part of what is
determined in a WikiProject is what to name articles -- but those names also
should conform to standard(ish) naming conventions.
In other words the WikiProject is really more informal and only enforceable
through bold editing and peer pressure while naming conventions are more or
less part of policy and are enforced in this light. Of course in a wiki the
line between the two types of enforcement is blurred -- but a distinction
should still be made.
I would like to hear what Manning has to say on this - he is the one who
originally developed the idea (correct me if I am wrong Manning).
maveric149
First, let me say that I wouldn't like to see a "namespace flood". For
lists, just say "List of ...". We should have a "List of lists", though, as
an "almanach main directory".
These lists all have "real" content, so they should stay in the article
namespace. The WikiProject pages might go to the wikipedia: namespace, as
they are of an organizational type.
The idea behing the log: namespace was to have logs that cannot be edited,
even by sysops, to keep track of their actions. Of course, with the later
addition of direct SQL access, the whole concept became flawed.
For the naming conventions of cities, IMHO the important thing is that the
different articles can be told apart ("Paris, Texas"). That Texas is in the
US can be mentioned within the article. The search function will find it
anyway, and as the "All articles" page is disabled, noone can browse through
the articles by name anyway.
Magnus
> I've noticed a excellent trend towards achieving consistency
> lately. The WikiProject was an attempt to instill some consistency
> back in the days when achieving that was (software-wise) far more
> difficult. As you pointed out it did not adequately include naming
> conventions.
> I think a namespace for such things would be beneficial. I actually
> don't care what the namespace, as long as it is easy to use.
> A "Wikiproject" namespace has a few arguments for it - it's
> obviously NOT an article topic (unlike "conventions" or similar).
> Also a lot of work has already been done using this name so
> changing it would take some editing.
I don't see any need for more namespaces for this or for "almanac"
entries. They're a great feature, but let's not just add them
willy-nilly without some forethought about organization and growth.
As I see it, the primary use of namespaces is to distinguish
"regular" articles from meta-stuff "about" wikipedia which the
software has to treat specially. In general, all meta stuff not
already in another namespace can go into "wikipedia:". If you want
to move the Wikiproject stuff under Wikipedia:Pojects or wherever,
that's a good idea. I was kind of in the process of cleaning up the
main namespace when I got sidetracked into doing the software,
but I'd like to get back into that.
Don't move the naming conventions page--it's tied in with the other
general policy pages and fits well. Of course, specific things
like ship names, cities, etc., could still have their own pages and
be linked to both from the projects page and from naming conventions.
A few other namespaces are quite reasonable; "User" has some
special features in the software, so that stays. Likewise
the corresponding Talk pages of the other namespaces (every
page needs to have talk about that page, and there are software
features there too). In the new codebase I got rid of "Log" and
moved those functions under Wikipedia: as well. I just didn't see
any need for it. Alas, I had to add a namespace ("Image") to do some
special features like link lists and history.
In general, I don't think new namespaces should be created without
a specific need for the software to treat them differently.
Currently, for example, the search function only searches in the
primary namespace. If we created a "almanac" space, for example,
we'd have to fix the software to search that as well, and that just
adds complexity for no benefit. I see no problem at all with
articles that today would be printed in an almanac. Just title
them clearly (like "List of...") and go for it.
0