On Thu, Jul 3, 2008 at 4:02 AM, Gerard Meijssen
> There is no single way of informing people about something that might be of
> interest to them. This thread started as a thread to three mailing lists, it
> is now only visible to developers.
> This extension has been documented on Meta, there is info on Mediawiki.org
> .. it has been discussed on IRC. There have been commits. There will always
> be people that do not get the message. People that will say that the
> communication was not good enough because they did not hear of it, because
> it did not attract their attention. You did not consider the commit messages
> of interest, that is your problem it is not that this information was not
> there for you. And yes, there is too much information out there.
> On Thu, Jul 3, 2008 at 8:16 AM, Chad <innocentkiller(a)gmail.com> wrote:
>> On Thu, Jul 3, 2008 at 12:39 AM, Gerard Meijssen
>> <gerard.meijssen(a)gmail.com> wrote:
>> > [snip /]
>> > The notion that this is a first time that the Babel template has been
>> > discussed is flatly wrong. MinuteElection has discussed this on IRC on
>> > several occasions. Pathoschild acknowledges that it has been discussed
>> > the past but he chose to go his own way. In the mean time this
>> > provides a better mouse trap and as such it deserves to be implemented.
>> > Thanks,
>> > GerardM
>> The notion that a discussion on IRC can get the range of views and
>> insight a mailing list can is also flatly wrong.
>> It was _not_ brought up publicly (on mailing lists, etc.), and thus the
>> community lacked the chance to give input. I saw commit messages
>> go by for an extension, but I do not automatically go look into it
>> (many extensions are of no interest to me, I would not, for example,
>> pay attention to a commit to the YouTube extension). Had I known
>> this was coming, I might've been more inclined to follow along and
>> comment before now.
>> Wikitech-l mailing list
> Wikitech-l mailing list
To use a metaphor, it would be like you handing me a large
book and then faulting me when I hadn't read the one chapter
you wished to discuss. Now, is that my fault for not reading
the chapter, or yours, for not indicating it needed to be read?
(sorry about losing some of the lists, it can get confusing which
threads have gone where, for that I apologize)
On Thu, Jul 3, 2008 at 1:34 AM, Gerard Meijssen
> As I have to spell it out for you:
> - Wolof: 3,612,560 people
> - Swahili: 772,642 first language 30,000,000 second language users
> - Xhosa: 7,214,118 people
> - Zulu: 7,214,118 first language 15,700,000 second language users
zu Zulu 100% (52/52)
100% (52/52) 100% (52/52)
sw Swahili 100% (52/52)
100% (52/52) 100% (52/52)
xh Xhosa 100% (52/52)
100% (52/52) 100% (52/52)
wo Wolof 100% (66/66)
100% (66/66) 100% (66/66)
unfortunately the status hasn't been updated in a little while)
For those who are unware the Dejavu fonts are a family of high quality
truetype fonts (http://dejavu.sourceforge.net/wiki/index.php/Main_Page)
with a fairly wide coverage of unicode.
Dejavu does not yet cover all of unicode (the most notable big gaps
are the Chinese, Japanese, and Korean character sets). The primary
reason Dejavu does not yet cover everything is because quality is the
highest priority (well below being free). A comprehensive font which
is ugly or otherwise has poorly matched characters (incompatible
metrics and such) is not something that many people will want to use
if they have any choice. Most modern systems can substitute characters
from other fonts if the selected font has holes in it, so Dejavu
allows that to happen until it has quality replacements that fit
nicely with the rest of the characters.
Dejavu's focus on quality means that it's suitable for everyday use by
everyone with a supported language, and not just by extreme-polyglots
who are perhaps more tolerant of ugly print. Dejavu has been the
default font set on the current GNU/Linux distributions for some time
I'm sure the Dejavu folks would welcome contributions from Wikimedians
interested in improving the coverage and quality of the font.
It may also make sense at some point to declare it to be the 'standard
font' for the projects, and prefer it via CSS for improved consistency
as well as support for the panoply of bizarre characters that even
English Wikipedia utilizes. (at least for users who are willing to
download it and install it... at well over a megabyte for the complete
character set, sending it dynamically is pretty much out of the
question! ;) )
(Preferring something like the currently non-free code2000 font would
also provide better coverage of unicode... but on most projects doing
so would get you shot: that font is not visually appealing in the
> It is people who speak languages. It is people we aim to provide information
> As to the Mozilla Foundation; the point is that our aim is to provide
> information to all people. It is essential that the infrastructure is there
> to achieve it. Fonts are essential in this game. The Mozilla foundation is
> to provide functionality to people that are already on the web. In what we
> aim to do, we do not say that people have to be online in order to be part
> of our potential public.
Indeed. Fonts are important. But they are important to a great many
people outside of Wikimedia. Other projects like Fedora Linux, and
OLPC depend on good fonts even more than we do, so the bulk of the
work has already been done by others and is already freely available
without any action on our part.
What gaps remain must be filled, but that is work that should be
coordinated through the real heavy lifters in this space, and not
Wikimedia which does not have a past history of font production or
Hi, over at Not the Wikipedia Weekly we're planning to cover the proposed
Babel extension. The recording is scheduled for 2100 UTC today. Gerard
Meijssen will be on the panel and we welcome participants who represent all
points of view on the issue.
The discussion takes place via Skype (which is accessible at no charge).
Please visit the following link for more details.
On Wed, Jul 2, 2008 at 2:36 AM, Niklas Laxström
> On 02/07/2008, Casey Brown <cbrown1023.ml(a)gmail.com> wrote:
>> We try to use very few with our system on Meta-Wiki.
> It is still using one per language, which means hundreds of them. Now,
> which is easier: copying hundreds of templates periodically, or
> installing an extension that can be updated the normal way. Especially
> for wikies outside of WMF which do not use many bots, if any.
You still aren't understanding me... I'm *love* the idea of an
extension to do this, I would rather we install it/one with the best
features first (especially if it's Wikimedia-wide).
>> One of my main problems with the babel extension is that I don't think
>> it gets rid of the *huge* number of categories that need to be created
>> (otherwise you have ugly redlinks).
> There is already a switch to have less categories, requested by me for
> example. What comes to creating the category pages... this is the
> first time I see anyone bringing it up.
A boolean (true or false) indicating whether main categories
featuring all users who specify a level for that language should be
added to a xx category; defaults to true.
How are they added to the category? Ordered by ability, then
alphabetically... or just alphabetically?
>> The system on Meta-Wiki greatly
>> reduces the number of categories, but I've been told that the
>> extension's developer was completely against any changes to the
>> extension (I didn't hear it directly from him).
> It looks like you are spreading FUD about the extension AND the
> developer without checkking the facts first. I would be offended if I
> were the developer in question.
> Niklas Laxström
Please check *your* fact first. :-) I am *for* the extension, I just
wish it were tweaked to be more efficient. I'm surprised no one is
yelling "enwiki-centric" because the levels were in-fact based off of
enwiki... Furthermore, I put the information in parenthesis *so* he
wouldn't be offended, I have no reason to believe that what I told was
incorrect considering I heard it from a pretty reputable source.
Note: This e-mail address is used for mailing lists. Personal emails sent to
this address will probably get lost.
I forward this on behalf of Niklas as he is not subscribed to this list and
had it bounced.
---------- Forwarded message ----------
From: Niklas Laxström <niklas.laxstrom(a)gmail.com>
Date: Wed, Jul 2, 2008 at 8:36 AM
Subject: Re: [Wikitech-l] Implementing the Babel extension
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Cc: wikipedia-l(a)lists.wikimedia.org, Wikimedia Foundation Mailing List <
On 02/07/2008, Casey Brown <cbrown1023.ml(a)gmail.com> wrote:
> We try to use very few with our system on Meta-Wiki.
It is still using one per language, which means hundreds of them. Now,
which is easier: copying hundreds of templates periodically, or
installing an extension that can be updated the normal way. Especially
for wikies outside of WMF which do not use many bots, if any.
> One of my main problems with the babel extension is that I don't think
> it gets rid of the *huge* number of categories that need to be created
> (otherwise you have ugly redlinks).
There is already a switch to have less categories, requested by me for
example. What comes to creating the category pages... this is the
first time I see anyone bringing it up.
> The system on Meta-Wiki greatly
> reduces the number of categories, but I've been told that the
> extension's developer was completely against any changes to the
> extension (I didn't hear it directly from him).
It looks like you are spreading FUD about the extension AND the
developer without checkking the facts first. I would be offended if I
were the developer in question.
Wikitech-l mailing list