Hi! Can anyone tell me, please, what to do with characters (Baltic fonts) which do not appear correctly in lv.wikipedia.com? I can see, Czechs have solved similar problem. Typing ā and ņ is quite silly, doesn't it? Especially because every third character in Latvian looks like this.:) Please, help me! I am starting Latvian Wikipedia, and it cannot develop until the problem is solved.
--- Anthere <anthere6(a)yahoo.com> wrote:
> --- Erik Moeller <erik_moeller(a)gmx.de> wrote:
> > We're now up to the latest Wikipedia software
> > version on the English
> > Wikipedia. Some changes I and others made in the
> > last weeks:
> > 1) There is a new feature called "oldest articles"
> > (colloq. "ancient
> > pages"). Currently this inevitably lists first all
> > the imported articles
> > from the phase I software that have not been
> > yet ever since.
> > Hopefully, as these become updated, this feature
> > will allow us to
> > systematically go through our old material and
> > sure it is in good
> > shape and up to date.
> > 2) Sysops will note that the page deletion feature
> > now auto-pastes the
> > content of pages that are smaller than 500 bytes
> > into the deletion comment
> > (only the first 150 characters). It also does so
> > the current revision
> > is blanked and the previous revision contains text
> > that can be pasted.
> > 3) The deletion feature now indicates if you are
> > about to delete a page
> > that has a history.
> > 4) The "New pages" list now shows the bytesize of
> > each page, making it
> > easier to pick nice, long articles for the Main
> > Page.
> > 5) Some minor layout stuff, some by me, some by
> > others. Notably, the ugly
> > "It was last modified" sentence at the bottom of
> > each page has been fixed.
> > Regards,
> > Erik
> Is it planned to make it available to other wikis as
> well ? 2 and 3 in particular
I think my question was missed. Probably because I
adressed it to the wrong list.
International people are wondering when the last
english features will be applied to other phase III
wikipedias. Is there anything we should provide you to
help there ?
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
The 'pedia seems very slow over the past couple of weeks, despite the new
What's causing the slowdowns? Is it just that the 'pedia is being overwhelmed
with traffic? Are there additional performance tweaks left in the software,
or is more hardware the only thing that can be thrown at the problem?
On Fri, 6 Jun 2003, Dante Alighieri wrote:
> I think Wikipedia is broken. Edits aren't going through. Someone confirm
> and alert the appropriate "authorities".
Confirmed and corrected, we are back online.
I'm afraid the /usr partition on pliny's hard drive filled up with
binary log files and the (way too verbose) mysql error report log.
Normally I clear those out every few days, but it seems I missed 'em this
week, and, well, it hit the edge for a few minutes.
I've cleared them out for now, but a more permanent solution would involve
moving stuff around on the disk to other partitions so it's not in as
much danger of filling up the vital areas with junk logs... And, of
course, automatically deleting the ones we don't need!
-- brion vibber (brion @ pobox.com)
[Note: This is crossposted to <wikitech-l> and <wikipedia-l> for continuity.
Replies should go to <wikipedia-l>, since it's a policy discussion.]
Axel Boldt wrote on <wikitech-l>:
>Erik Moeller wrote:
>>I have not seen your response to my
>>analysis that conluded that quotations are more problematic
>If I understood correctly, you argue that quotes are embedded in the
>text while images are kept in separate files, thus GFDL is not
>inherited by the photo but is inherited by the quotes. This is
>incorrect. Derivative work are required to be under GFDL; what
>constitutes a derivative work is defined by copyright law. The
>technical detail that text and images are typically kept in separate
>files is irrelevant; illustrating an article by adding a picture is a
>classical case of a derivative work. Moving quotes out of the main text
>and then "including" them somehow is a technical gimmick that doesn't
>change anything: adding a quote also creates a derivative work.
Including quotations would indeed be a technical gimmick,
and our server would provide a single HTML file, a derivative work.
That images are separate, however, is more than a technical detail;
it's an important feature of HTTP that's used in other ways.
Our copyright notice at the bottom of the page even refers only to "text";
a result of this feature is that the text is easily separated.
[Crossposted from <wikiEN-l> to <wikipedia-l>.
Since this feature, if implemented, would apply to all wikis,
replies should go to <wikipedia-l>.]
>Erik Moeller wrote:
>>[[Category:Sex]] [[Category:Sexually explicit]]
Not "meta-categories", but "meta categories".
A meta-category is a category about categories,
but a meta category is a category about meta issues,
which in our case means a category about Wikipedia.
(Just being silly and pedantic. Ignore me.)
>>each of these category pages would be editable, but always automatically
>>include a sorted list of the pages that link to the category ("what links
>>here"). It would also be nice if a text could be configured for each
>>category that is displayed on pages that are part of it, e.g.
>>[[Category:Stub]] -> This article is a stub article ...
>I think there is much in common between the two ideas, at least in terms
>of what we want the two visions would accomplish. I think there is
>probably a lot of room for reconciling the two. I'd need to give more
>thought to the way it might be done. I can give a few preliminary
I don't like the subject categories, but I like the meta categories.
If we write code that works well for the meta categories,
then we can always test the subject categories at that time.
> 1. Codes or words? Use both, but have a way of distinguishing which
>is being used, e.g. it is a word if the second character is in lower
>case. We would still need to find a way of accomodating the "NPOV"
Unless "NPOV" is the code and "Neutral point of view" is the word. ^_^
But you could always check for all-caps in "NPOV dispute".
Myself, I'd still say that words are best; we can keep them short.
> 2. Does "category page" mean a whole separate page? If it is,
>isn't a category box the same thing, only much tinier, and without the
>need to write the word "category" every time? Some articles will belong
>to several categories.
I'm pretty sure that "category page" means a page dedicated to that category.
Thus at the URL <http://en.wikipedia.org/wiki/Category:Stub>
one can find a page with an automatic list of all stubs,
below the boilerplate text that's printed on all linked pages (say).
And at <http://en.wikipedia.org/w/wiki.phtml?title=Category:Stub&action=edit>,
one can edit this boilerplate text (but not the list).
>Anyway, I'm sure there will be more to say on this.
--- Erik Moeller <erik_moeller(a)gmx.de> wrote:
> > Not checkboxes, which would indeed require so many
> that they would
> > become rigid and/or useless. I would propose
> searchable write-in boxes
> > where words and/or codes could be entered.
> This sounds a lot like my proposed [[Category:Foo]]
> scheme, only that you
> want codes instead of words for the categories. My
> scheme has the
> advantage that it can be built very easily on top of
> the existing data
> structures, with no extra input fields or changes to
> RC required.
> With this scheme, you would have
> [[Category:Sex]] [[Category:Sexually explicit]]
For *all* the very good reasons KQ has been
summarizing earlier today, I think this type of
categorizing is very bad. I understand the need some
feel to protect sensible eyes, but I believe this is
not the proper way. I think it will introduce POV in
an encyclopedia struggling to be NPOV.
As Ed (eh, Ed, where are you ?) would put it, when we
write an article, a good way is to write "xx said yyy
With categories, it will be "wikipedianUser says yyy
Plus, I think with filters, many many articles will be
more red than blue/grey. Very bad.
> and meta-categories:
> [[Category:NPOV dispute]]
> each of these category pages would be editable, but
> always automatically
> include a sorted list of the pages that link to the
> category ("what links
> here"). It would also be nice if a text could be
> configured for each
> category that is displayed on pages that are part of
> it, e.g.
> [[Category:Stub]] -> This article is a stub article
This, I agree with.
I can figure a [[Category:Copyright]] -> This article
is suspected of copyright violation
Then, when the violation is asserted, and a sysop
delete it, it goes automatically in the right
temporary database of copyrighted material, to be
permanently emptied on the first of each month.
PS : I "to" to the main list. Where this ever to be
implemented, it is likely to interest all wikipedias
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
Erik Moeller schrieb:
>>Not checkboxes, which would indeed require so many that they would
>>become rigid and/or useless. I would propose searchable write-in boxes
>>where words and/or codes could be entered.
>This sounds a lot like my proposed [[Category:Foo]] scheme
I even had the category thing implemented on the test wikipedia a long
time ago, but it was unpopular.
These category links would be similar to the language links (at least,
in my implementation), right? But, we are some time now to switch to a
central database managing the language links, as just putting the links
into the text is kinda chaotic.
So, maybe we should consider a meta page (Special:Meta) for articles, as
was suggested. This could contain categories, show the language links
from the central database etc.
Anyone against meta pages? If so, why? Otherwise, I might start
implementing a test version soon. (You have been warned!;-)
[Note: This is posted to both <wikitech-l> and <wikipedia-l>
to preserve continuity; replies should go to <wikipedia-l>.]
Tomasz Wegrzanowski wrote:
>>How others use the material is their problem, and their risk. We
>>shouldn't have to baby-sit them. Whatever license or copyrights are
>>applied to Wikipedia reflects a collective comfort level. The user is
>>still responsible for his own due-dilligence, no matter how conservative
>>we are on the matter.
>They're not "others", lot of "them" are Wikipedians.
>If everyone had to consult a lawyer before distributing free software,
>it wouldn't be half as successful as it is now.
This isn't entirely true; the more paranoid must still check the less paranoid.
But Wikipedia needs to make it easy by separating out the "fair use" pics
and not claiming any longer that they are being distributed under the GFDL.
As for brief quotations, well, I knew that the GNU licences
would come back to bite us someday, but I expected 50 years from now
(hopefully *after* current copyright law became impossible to maintain).
I never thought they would prove to be inadequate so soon!
Surely RMS thought of brief quotations, one hopes?