Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Tim Starling]

Here's what I'm taking out of this thread:

* Platonides mentions the case of power-users with tens of scripts loaded via
gadgets or user JS with importScript().
* Tisza asks that core onload hooks and other functions be overridable by user 
JS.
* Trevor and Michael both mention i18n as an important consideration which I
have not discussed.
* Michael wants certain components in the js2 directory to be usable as
standalone client-side libraries, which operate without MediaWiki or any other
server-side application.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Tim Starling]

Michael Dale wrote:
> That is part of the idea of centrally hosting reusable client-side 
> components so we control the jquery version and plugin set. So a
> new version won't "come along" until its been tested and
> integrated.

You can't host every client-side component in the world in a
subdirectory of the MediaWiki core. Not everyone has commit access to
it. Nobody can hope to properly test every MediaWiki extension.

Most extension developers write an extension for a particular site,
and distribute their code as-is for the benefit of other users. They
have no interest in integration with the core. If they find some
jQuery plugin on the web that defines an interface that conflicts with
MediaWiki, say jQuery.load() but with different parameters, they're
not going to be impressed when you tell them that to make it work with
MediaWiki, they need to rewrite the plugin and get it tested and
integrated.

Different modules should have separate namespaces. This is a key
property of large, maintainable systems of code.

> The nice thing about the way its working right now is you can just
> turn off the script-loader and the system continues to work ... you
> can build a page that includes the js and it "works"

The current system kind of works. It's not efficient or scalable and
it doesn't have many features.

> Having an export mode,  scripts doing transformations, dependency
> management output sounds complicated. I can imagine it ~sort of~
> working... but it seems much easier to go the other way around.

Sometimes complexity is necessary in the course of achieving other
goals, such as performance, features, and ease of use for extension
developers.

> I agree that the present system of parsing top of the javascipt
> file on every script-loader generation request is un-optimized.
> (the idea is those script-loader generations calls happen rarely
> but even still it should be cached at any number of levels. (ie
> checking the filemodifcation timestamp, witting out a php or
> serialized file .. or storing it in any of the other cache levels
> we have available, memcahce, database, etc )

Actually it parses the whole of the JavaScript file, not the top, and
it does it on every request that invokes WebStart.php, not just on
mwScriptLoader.php requests. I'm talking about
jsAutoloadLocalClasses.php if that's not clear.

>> Have you looked at the profiling? On the Wikimedia app servers,
>> even the simplest MW request takes 23ms, and gen=js takes 46ms. A
>> static file like wikibits.js takes around 0.5ms. And that's with
>> APC. You say MW on small sites is OK, I think it's slow and
>> resource-intensive.
>> 
>> That's not to say I'm sold on the idea of a static file cache, it
>>  brings its own problems, which I listed.
>> 
> 
> yea... but almost all script-loader request will be cached.  it
> does not need to check the DB or anything its just a key-file
> lookup (since script-loader request pass a request key either its
> there in cache or its not ...it should be on par with the simplest
> MW request. Which is substantially shorter then around trip time
> for getting each script individually, not to mention gziping which
> can't otherwise be easily enabled for 3rd party installations.

I don't think that that comparison can be made so lightly. For the
server operator, CPU time is much more expensive than time spent
waiting for the network. And I'm not proposing that the client fetches
each script individually, I'm proposing that scripts be concatentated
and stored in a cache file which is then referenced directly in the HTML.

I'm aware of the gzip issue, I mentioned it in my original post.

> ...right... we would want to avoid lots of live hacks. But I think
> we want to avoid lots of live hacks anyway.  A serious javascript
> bug would only affect the pages that where generated in thous hours
> that it was a bug was present not the 30 days that your
> characterizing the lag time of page generation.

Bugs don't only come from live hacks. Most bugs come to the site from
the developers who wrote the code in the first place, via subversion.

> Do you have stats on that?... its surprising to me that pages are 
> re-generated that rarely... How do central notice campaigns work?

$wgSquidMaxage is set to 31 days (2678400 seconds) for all wikis
except wikimediafoundation.org. It's necessary to have a very long
expiry time in order to fill the caches and achieve a high hit rate,
because Wikimedia's access pattern is very broad, with the "long tail"
dominating the request rate.

The CentralNotice extension was created to overcome this problem and
display short-lived messages. Aryeh described how it works.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla Weekly Report

[reporter]

MediaWiki Bugzilla Report for September 21, 2009 - September 28, 2009

Status changes this week

Bugs NEW   :  113 
Bugs ASSIGNED  :  12  
Bugs REOPENED  :  21  
Bugs RESOLVED  :  124 

Total bugs still open: 3875

Resolutions for the week:

Bugs marked FIXED  :  72  
Bugs marked REMIND :  0   
Bugs marked INVALID:  13  
Bugs marked DUPLICATE  :  27  
Bugs marked WONTFIX:  14  
Bugs marked WORKSFORME :  7   
Bugs marked LATER  :  5   
Bugs marked MOVED  :  0   

Specific Product/Component Resolutions & User Metrics 

New Bugs Per Component

Site requests   6   
General/Unknown 3   
Page rendering  3   
DumpHTML2   
FCKeditor   2   

New Bugs Per Product

MediaWiki   20  
Wikimedia   10  
MediaWiki extensions12  
mwEmbed 2   
MediaWiki Feature Request   1   

Top 5 Bug Resolvers

rhalsell [AT] wikimedia.org 21  
alex.emsenhuber [AT] bluewin.ch 19  
roan.kattouw [AT] gmail.com 19  
brion [AT] wikimedia.org17  
innocentkiller [AT] gmail.com   8   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimir.org Version MW

[Dan Collins]

On Sun, Sep 27, 2009 at 4:26 PM, Ferrer  wrote:

> Not displayed version of MediaWiki at http://wikimir.org Bug?
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

I personally see no issues with that wiki whatsoever,
http://wikimir.org/wiki/Заглавная_страница
loads
fine and 
http://wikimir.org/wiki/Служебная:Version
displays
version 1.15.0. What seems to be the problem?

-- 
DCollins/ST47
Stevens Institute of Technology Class of '13
Administrator, en.wikipedia.org
Maintainer, MediaWiki::Bot module
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Platonides]

Yaron Koren wrote:
> I do believe, though, that the thing that prevents a simpler storage format
> is the need for translation. Without it, a template parameter can be defined
> by a simple set of values: a label, a description, an input type, and then a
> handful of modifiers for the input type (like the list of allowed values, if
> it's a radiobutton or dropdown). If translation of different values is
> allowed, though, you really need the structure that XML provides, or else
> the whole thing devolves into chaos.
> 
> Most wikis won't require translation, though; and that includes most
> Wikimedia projects - they're in one language at a time. The one big
> exception is Wikimedia Commons, which also happens to be the proposed first
> usage of this template-call-editing system. And for that site, translation
> really is necessary (I think).
> 
> So, at the risk of complicating things even further - maybe it makes sense
> to have a split approach - one format that handles translation, another that
> doesn't? The non-translation format, given that it would be simpler, could
> even be embedded directly in the template - possibly within a
>  tag in the template, as Platonides suggested.

There could be , ,
...


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Issues on Wikireality.ru

[K. Peachey]

 For information about combating and handling spam in
MediaWiki, see 
and .

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikimir.org Version MW

[Ferrer]

Not displayed version of MediaWiki at http://wikimir.org Bug?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Abuse of CheckUser rights

[Ferrer]

Ok, thanks, I send mail to Foundation list and Ombudsman comission.

2009/9/27 Casey Brown :
> This is more of an issue for foundation-l than wikitech-l.
>
> On Sun, Sep 27, 2009 at 12:40 PM, Ferrer  wrote:
>> Also, checkusers in Russian Wikipedia abused the 'checkuser' rights
>> (for example linked to me unrelated edits from open proxy with
>> marasmic vandalism -- create marasmic attackpages-like topic on
>> «Request for Administrators» about Kalan, obviously with a view to
>> Kalan thought that I was a degenerat-pederast); who can I write about
>> this? Ombudsmans on Meta?
>>
>> Such decisions are very bad name in the wikiprojects.
>>
>> Ferrer.
>>
>
> Yes, complains about privacy policy violations or misuse of CheckUser
> should be addressed to the Ombudsman commission.  Information on how
> to contact them is available on Meta-Wiki:
> 
>
> --
> Casey Brown
> Cbrown1023
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Issues on Wikireality.ru

[Ferrer]

This mail is not spam, it's really issues on wikireality.ru with
spambot activity.

27 сентября 2009 г. 22:50 пользователь Brian
 написал:
> #mediawiki
>  I've been receiving wikimail spam from translatewiki suggesting to
> join an attack site
>  two different accounts - Ferrer and Участник Проектов
>  MaxSem: that's all Ferrer.
>  MaxSem: we're blocking on sight.
>
> On Sun, Sep 27, 2009 at 10:33 AM, Ferrer  wrote:
>
>> In http://wikireality.ru (very useful site about Russian WIkipedian
>> and wiki projects)  began to appear regularly party giving to the
>> userpages of bad external links, probably with the bot.         Can I stop
>> this?
>>
>> (MediaWiki 1.15 with Abuse Filter & Title Blacklist)
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Issues on Wikireality.ru

[Brian]

#mediawiki
 I've been receiving wikimail spam from translatewiki suggesting to
join an attack site
 two different accounts - Ferrer and Участник Проектов
 MaxSem: that's all Ferrer.
 MaxSem: we're blocking on sight.

On Sun, Sep 27, 2009 at 10:33 AM, Ferrer  wrote:

> In http://wikireality.ru (very useful site about Russian WIkipedian
> and wiki projects)  began to appear regularly party giving to the
> userpages of bad external links, probably with the bot. Can I stop
> this?
>
> (MediaWiki 1.15 with Abuse Filter & Title Blacklist)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Yaron Koren]

The idea of having the template specification be stored as something more
human-readable, and possibly more like wiki-text, certainly has its appeal
(at least, to those people who don't want wiki-text to be replaced by XML in
the first place!) It would be easier for users to create and edit; unless
there were a tool to edit the XML, and users always used that tool... I
really don't know whether XML or something simpler would be the better
solution in the long run.

I do believe, though, that the thing that prevents a simpler storage format
is the need for translation. Without it, a template parameter can be defined
by a simple set of values: a label, a description, an input type, and then a
handful of modifiers for the input type (like the list of allowed values, if
it's a radiobutton or dropdown). If translation of different values is
allowed, though, you really need the structure that XML provides, or else
the whole thing devolves into chaos.

Most wikis won't require translation, though; and that includes most
Wikimedia projects - they're in one language at a time. The one big
exception is Wikimedia Commons, which also happens to be the proposed first
usage of this template-call-editing system. And for that site, translation
really is necessary (I think).

So, at the risk of complicating things even further - maybe it makes sense
to have a split approach - one format that handles translation, another that
doesn't? The non-translation format, given that it would be simpler, could
even be embedded directly in the template - possibly within a
 tag in the template, as Platonides suggested.
I put together some ideas on how this could work, here:

http://usability.wikimedia.org/wiki/Template_forms#Specification_structure

-Yaron
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Abuse of CheckUser rights

[Casey Brown]

This is more of an issue for foundation-l than wikitech-l.

On Sun, Sep 27, 2009 at 12:40 PM, Ferrer  wrote:
> Also, checkusers in Russian Wikipedia abused the 'checkuser' rights
> (for example linked to me unrelated edits from open proxy with
> marasmic vandalism -- create marasmic attackpages-like topic on
> «Request for Administrators» about Kalan, obviously with a view to
> Kalan thought that I was a degenerat-pederast); who can I write about
> this? Ombudsmans on Meta?
>
> Such decisions are very bad name in the wikiprojects.
>
> Ferrer.
>

Yes, complains about privacy policy violations or misuse of CheckUser
should be addressed to the Ombudsman commission.  Information on how
to contact them is available on Meta-Wiki:


-- 
Casey Brown
Cbrown1023

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Abuse of CheckUser rights

[Ferrer]

Also, checkusers in Russian Wikipedia abused the 'checkuser' rights
(for example linked to me unrelated edits from open proxy with
marasmic vandalism -- create marasmic attackpages-like topic on
«Request for Administrators» about Kalan, obviously with a view to
Kalan thought that I was a degenerat-pederast); who can I write about
this? Ombudsmans on Meta?

Such decisions are very bad name in the wikiprojects.

Ferrer.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Issues on Wikireality.ru

[Ferrer]

In http://wikireality.ru (very useful site about Russian WIkipedian
and wiki projects)  began to appear regularly party giving to the
userpages of bad external links, probably with the bot. Can I stop
this?

(MediaWiki 1.15 with Abuse Filter & Title Blacklist)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Neil Harris]

Tei wrote:
> Or install the Unicode font that support it all.
>
> Maybe Wikipedia can do
>
> * {
>  font-family:  "name of font that wikipedia recomend","Arial Unicode",
> Helvetica, sans;
> }
>
> ..and provide somewhere a link to such "recomended font", if that font
> exist.  So, If a dude has that font installed, the page will use it,
> and If it don't exist, It will use "Arial Unicode", and If arial
> unicode don't exist,... It will use helvetica, and If helvetica don't
> exist, any available sans serif font.
>   

See http://en.wikipedia.org/wiki/Template:Unicode and its related templates.

-- Neil


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Gerard Meijssen]

Hoi,
The question asked in the first post is "What can I do to get more special
characters to render correctly in Chrome?". The answer that I supplied is
use Windows 7 because this will support such characters. This is certainly
true for the character given as an example.

Consequently, my answer is very much on topic. Not all operating systems are
equal in their support in their support of Unicode. Windows 7 apparantly
does a better job.
Thanks,
 GerardM

PS I am not happy with this fact but it just happens to be this way.

2009/9/27 Aryeh Gregor

>

>
> On Sun, Sep 27, 2009 at 7:01 AM, Gerard Meijssen
>  wrote:
> > I have been told off list that Windows-7 supports this character by
> default.
> > This is one valid reason to choose Windows-7 for your operating system.
> It
> > is also a challenge to other operating systems to be as good.
>
> The relative merits of operating systems are not relevant to either
> this topic or this list.
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Template editing

[Roan Kattouw]

2009/9/27 Steve Bennett :
> *falls to the ground and starts kissing your feet*
>
*refers praise to other people; I'm mostly just a code monkey there*

> Awesome. Timeframe? Screenshots?
>
Nothing just yet. Right now we're focusing on getting the Babaco
release deployed shortly. When that's done and the inevitable
post-deployment problems have settled down, we're gonna get cracking
at Citron features. We do have some mockups for Citron features at
http://usability.wikimedia.org/wiki/Babaco_Designs#BEYOND_BABACO ; for
a list of features per release see
http://usability.wikimedia.org/wiki/Releases .

> (Also, you're not actually calling them "stubs" are you? Confusing...)
>
No, fortunately not; I was just trying to come up with a shorter word
for "visual placeholder for table/template/ref syntax that's much
shorter than the actual syntax and that can be expanded and
collapsed". They probably won't be called anything at all: we don't
really need a name for them.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Aryeh Gregor]

On Sun, Sep 27, 2009 at 6:13 AM, Steve Bennett  wrote:
> Well, actually I was just using that character as a (fairly
> unimportant) example.

That's why I said "and related cases where isolated characters don't
display properly".

> Anyway, is there really no general solution to me coming across
> various articles with characters that render as boxes? You seem to be
> saying ("there's no font out there that really supports
> *all* of Unicode") that the only solution is to download and install
> the particular font that has the glyphs used by one particular
> article...but that will then leave other articles uncovered.

The solution is to not use poorly-supported Unicode characters in
articles.  No, there's no better solution.  It's just the same as
using fancy new HTML5 features that aren't widely supported, or
whatever.  That's the price of using evolving standards with multiple
implementations instead of a homogeneous one-vendor system.

> I'm amazed there isn't even a reference unicode font that has all the glyphs?

There's not any that I know of.  Go figure out how to propose the idea
to the Unicode Consortium if you like.

On Sun, Sep 27, 2009 at 7:01 AM, Gerard Meijssen
 wrote:
> I have been told off list that Windows-7 supports this character by default.
> This is one valid reason to choose Windows-7 for your operating system. It
> is also a challenge to other operating systems to be as good.

The relative merits of operating systems are not relevant to either
this topic or this list.

On Sun, Sep 27, 2009 at 7:17 AM, Tei  wrote:
> Maybe Wikipedia can do
>
> * {
>  font-family:  "name of font that wikipedia recomend","Arial Unicode",
> Helvetica, sans;
> }

Wikipedia will not set a default font for Latin-based scripts at any
time in the foreseeable future.  We need to respect users' choice of
default font wherever possible.  (For some languages' scripts this may
not be practical, but that's a separate issue.)  As far as I know,
most browsers these days will try to use any available font that has
the character in question if the specified font doesn't have it.  I'm
not totally sure about that, though.

It still doesn't solve the problem that some characters aren't
supported in almost any commonly-available font.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber  wrote:
> The field metadata can be fairly straightforwardly displayed and edited
> through a nice web interface. XML as such is simply a conveniently
> well-defined structured data tree format which can be used both for
> storing the field metadata in the DB and exposing it to the template
> invocation editor interface (whether client-side JS or server-side PHP
> or a custom bot-based tool speaking to our API).

Depending on what features are added, exactly, I'd imagine a
lighter-weight markup language would be more than sufficient.
Something where you can describe the syntax in less than a page and
write a correct implementation in half an hour or less would probably
be good enough.  Like maybe just newline-delimited key=value pairs, or
something like JSON at worst.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Tei]

Or install the Unicode font that support it all.

Maybe Wikipedia can do

* {
 font-family:  "name of font that wikipedia recomend","Arial Unicode",
Helvetica, sans;
}

..and provide somewhere a link to such "recomended font", if that font
exist.  So, If a dude has that font installed, the page will use it,
and If it don't exist, It will use "Arial Unicode", and If arial
unicode don't exist,... It will use helvetica, and If helvetica don't
exist, any available sans serif font.


On Sun, Sep 27, 2009 at 1:01 PM, Gerard Meijssen
 wrote:
> Hoi,
> I have been told off list that Windows-7 supports this character by default.
> This is one valid reason to choose Windows-7 for your operating system. It
> is also a challenge to other operating systems to be as good.
> Thanks,
>      GerardM
>
> 2009/9/25 Gerard Meijssen 
>
>> Hoi,
>> This specific character mentioned in the article is used to write the
>> Tanimuca-Retuarã language. This is specified in the article. itself.
>> Languages that need characters that are missing in fonts that are in general
>> use are not isolated affairs. In the end there is only one solution; we
>> should be part of a solution that allows us to show all characters.
>> Thanks,
>>      GerardM
>>
>> 2009/9/25 Aryeh Gregor 
>> 
>> >
>>
>>> On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen
>>>
>>>  wrote:
>>> > The notion that our editors should decide if a font is well enough
>>> > supported  is a bit off. It is saying "you cannot properly write your
>>> > language because ...".
>>>
>>> No, it's not.  We're talking about a specific article on the English
>>> Wikipedia about a single obscure character, and related cases where
>>> isolated characters don't display properly.  Nothing I said should be
>>> construed to have any bearing on radically different situations, such
>>> as an entire wiki whose language is poorly supported on common
>>> platforms.  While I appreciate that you take a great interest in
>>> technical topics related to internationalization, this is not such a
>>> topic.
>>>
...


-- 
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 9:55 PM, Michael Dale  wrote:
> ...right... we would want to avoid lots of live hacks. But I think we want
> to avoid lots of live hacks anyway.  A serious javascript bug would only
> affect the pages that where generated in thous hours that it was a bug was
> present not the 30 days that your characterizing the lag time of page
> generation.
>
> Do you have stats on that?... its surprising to me that pages are
> re-generated that rarely... How do central notice campaigns work?

They insert the notice client-side using JavaScript.  The HTML served
is thus always the same.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Gerard Meijssen]

Hoi,
I have been told off list that Windows-7 supports this character by default.
This is one valid reason to choose Windows-7 for your operating system. It
is also a challenge to other operating systems to be as good.
Thanks,
  GerardM

2009/9/25 Gerard Meijssen 

> Hoi,
> This specific character mentioned in the article is used to write the
> Tanimuca-Retuarã language. This is specified in the article. itself.
> Languages that need characters that are missing in fonts that are in general
> use are not isolated affairs. In the end there is only one solution; we
> should be part of a solution that allows us to show all characters.
> Thanks,
>  GerardM
>
> 2009/9/25 Aryeh Gregor 
> 
> >
>
>> On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen
>>
>>  wrote:
>> > The notion that our editors should decide if a font is well enough
>> > supported  is a bit off. It is saying "you cannot properly write your
>> > language because ...".
>>
>> No, it's not.  We're talking about a specific article on the English
>> Wikipedia about a single obscure character, and related cases where
>> isolated characters don't display properly.  Nothing I said should be
>> construed to have any bearing on radically different situations, such
>> as an entire wiki whose language is poorly supported on common
>> platforms.  While I appreciate that you take a great interest in
>> technical topics related to internationalization, this is not such a
>> topic.
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Witext syntax (was: Re: Proposal for editing template calls within pages)

[Steve Bennett]

On Fri, Sep 25, 2009 at 8:38 AM, Happy-melon  wrote:
> The 10% drove people off cliffs because it is, pretty much by definition,
> the horrible unexpected behaviour that is a *consequence* of not having a
> formal definition.  Writing a formal definition is not impossible if you
> require that it be sensible at the final reading.  The parser is, in many
> places, *not* sensible, and naturally those quirks are difficult to
> describe, but they're also undesirable overall.  A true move to a formal
> language definition involves action from both ends: writing a formal
> definition that follows the current parser in general, *and* being prepared
> to alter the parser to remove some of the more egregious deviations from
> expected behaviour.

I just wanted to state for the record that when we were talking about
this last time, the developers (Brion included) were actually quite
open to the idea of the semantics of wikitext changing if they weren't
widely used. In other words, it was ok to build a new parser which was
incompatible with the old parser, as long as that didn't break too
much existing wikitext ("too much" being in the order of 1 or 2% of
articles).

Another comment:
>The problem is the ambiguity with italics, (''italics''). So the
>current parser doesn't really make its final decision on what should
>be bold or what should be italic until it hits a newline. If there are
>an even number of both bold and italics then it assumes it interpreted
>the line correctly.

...
>I think this is part of what makes wikitext undescribable in a formal
>grammar.

Yeah, but from memory, using ANTLR's formal-grammar-breaking features,
this wasn't a massive problem. A small, annoying one, to be sure, but
not a killer. It does tend to mean potentially a lot of back-tracking
though, which is slow...

Steve

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Template editing

[Steve Bennett]

On Sat, Sep 26, 2009 at 3:11 AM, Roan Kattouw  wrote:
> We (the usability team) do intend to get 'content folding' (folding
> template calls and tables into stubs that can be expanded at will)
> done in the Citron (third) release.

*falls to the ground and starts kissing your feet*

Awesome. Timeframe? Screenshots?

(Also, you're not actually calling them "stubs" are you? Confusing...)

Steve

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Steve Bennett]

On Sat, Sep 26, 2009 at 3:18 AM, Aryeh Gregor
 wrote:
> No, it's not.  We're talking about a specific article on the English
> Wikipedia about a single obscure character, and related cases where
> isolated characters don't display properly.

Well, actually I was just using that character as a (fairly
unimportant) example.

Anyway, is there really no general solution to me coming across
various articles with characters that render as boxes? You seem to be
saying ("there's no font out there that really supports
*all* of Unicode") that the only solution is to download and install
the particular font that has the glyphs used by one particular
article...but that will then leave other articles uncovered.

I'm amazed there isn't even a reference unicode font that has all the glyphs?

Steve

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l