[Bug 24533] Enable & install whole reveiwer system or extensions on hindi wiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24533

--- Comment #3 from mayurkumar  2010-07-27 06:41:41 UTC ---
I asking to-
*install whole reveiwer system present in media wiki files at this link
-http://hi.wikipedia.org/w/index.php?title=%E0%A4%B5%E0%A4%BF%E0%A4%B6%E0%A5%87%E0%A4%B7%3AAllMessages&prefix=revre&filter=all&lang=hi&offset=Revdelete-show-no-access&limit=250
*Now if it is called flag rev system than install flagged rev in hindi wiki
with all its extensions & flagged protection too and Flagged Revs custom
configuration as well with  edit patrolling system. I have also given this
seperate bugs as bug 24535 and bug 24536.

   We will be thankful to bugzilla team for this assistance.

 With regards
  Mayur kumar

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24550] Allow svn usernames in bugzilla

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24550

Reedy  changed:

   What|Removed |Added

 CC||s...@reedyboy.net

--- Comment #1 from Reedy  2010-07-27 06:22:52 UTC ---
H. I suppose, look up svn commit (or MediaWiki.org) username, get email, if
email matches email of user in bugzilla, use it?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

Reedy  changed:

   What|Removed |Added

   Severity|major   |enhancement

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24551] Make changes to the Hungarian (hu) LimeSurvey translation

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24551

Reedy  changed:

   What|Removed |Added

   Attachment #7594|1   |0
   is patch||

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 15607] Implement the Interlanguage extension in Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=15607

--- Comment #43 from Nikola Smolenski  2010-07-27 05:57:14 
UTC ---
I could add the edit link, but I have no idea where to put it, how should it
work (only for registered users?) or how should it look like...

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24540] Logo switch on fj.wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24540

--- Comment #5 from Casey Brown  2010-07-27 05:45:40 UTC 
---
(In reply to comment #4)
> This logo does not follow the style of the other Wikipedia logos.

http://wikimediafoundation.org/wiki/Wikimedia_official_marks/Word_mark_creation

I don't think you actually speak the language, so it's best to ask the natives
how to translate the phrases first.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24540] Logo switch on fj.wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24540

JeLuF  changed:

   What|Removed |Added

 CC||je...@gmx.de

--- Comment #4 from JeLuF  2010-07-27 05:36:40 UTC ---
This logo does not follow the style of the other Wikipedia logos. Please use
the font that's being used for the other logo, have "Wikipedia" in your local
spelling as the first line below the puzzleball and the translation of "The
free encyclopedia" as second line in a smaller font.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24533] Enable & install whole reveiwer system or extensions on hindi wiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24533

Bawolff  changed:

   What|Removed |Added

   Keywords||shell
 CC||bawolff...@gmail.com

--- Comment #2 from Bawolff  2010-07-27 04:16:47 UTC ---
No - only file a bug in the extensions component if there is something wrong
with the extension. Since this is for enabling an extension (a configuration
change), it is in the right component (site requests). I believe shell bugs are
saved up and done at regural intervals, so this bug will probably be addressed
next time someone does the shell bugs.


I must admit I'm a little confused as to if you're asking for flagged revs
enabled or asking for edit patrolling enabled or asking for both. However I'm
just a random person who comments on these bugs, so it really doesn't matter
that I'm confused, only that the people who do shell requests understand you,
which if they don't they will eventually comment.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24331] Global Usage and Flagged Revisions / Pending Changes

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24331

--- Comment #8 from Aaron Schulz  2010-07-27 04:02:40 UTC 
---
Bug 17154 seems unrelated. That's about the links not updating sometimes when
they should.

The issue of the links being gone due to a page in a vandalized, blanked, state
when a commons admin happened to check for a deletion is by design.

The stable version not having tracking links in the global usage table is also
by design (implicitly). Doing so would require some tricks to avoid parsing.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24542] Create globalsysops-l mailing list to be used by global sysops and stewards

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24542

--- Comment #4 from p858snake  2010-07-27 03:54:18 UTC ---
Since you are already discussing it privately on the stewards list, why not
keep it there?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16459] user native getElementsByClassName

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=16459

entli...@gmx-topmail.de changed:

   What|Removed |Added

 CC||entli...@gmx-topmail.de

--- Comment #7 from entli...@gmx-topmail.de 2010-07-27 03:43:42 UTC ---
Another inconsistency: The original implementation returns an array. The native
implementation returns a live NodeList. The wrapper function returns that as-is
if strTagName is the wildcard, but converts it to an array if strTagName is a
specific tag name. That can be really confusing.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24536] Enable flagged rev in hindi wiki with all its extensions & flagged protection too and FlaggedRevs custom configuration

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24536

--- Comment #1 from mayurkumar  2010-07-27 03:20:35 UTC ---
should I file another bug at mediawiki extensions  or this bug is at the right
side because no reaction on this bug like others were reacted

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24535] Enable "mark as patrolled" feature in hindi wiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24535

--- Comment #2 from mayurkumar  2010-07-27 03:20:06 UTC ---
should I file another bug at mediawiki extensions  or this bug is at the right
side because no reaction on this bug like others were reacted

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24534] enable hide/show patrol edits in Special:recentchanges in hindi wiki with recent changes patrol

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24534

--- Comment #2 from mayurkumar  2010-07-27 03:19:46 UTC ---
should I file another bug at mediawiki extensions  or this bug is at the right
side because no reaction on this bug like others were reacted

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24533] Enable & install whole reveiwer system or extensions on hindi wiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24533

--- Comment #1 from mayurkumar  2010-07-27 03:17:01 UTC ---
should I file another bug at mediawiki extensions  or this bug is at the right
side because no reaction on this bug like others were reacted

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24542] Create globalsysops-l mailing list to be used by global sysops and stewards

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24542

--- Comment #3 from Milos Rancic  2010-07-27 02:54:57 UTC ---
Reasoning is simple: if it is about dealing with vandalism all over the small
Wikimedia projects, it is better to have a private list.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24542] Create globalsysops-l mailing list to be used by global sysops and stewards

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24542

--- Comment #2 from Laurence 'GreenReaper' Parry  
2010-07-27 02:29:52 UTC ---
Better for whom? :-) I must admit, I'm a little curious as to what matters are
to be covered on the list, and why there is perceived to be a need for privacy.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24542] Create globalsysops-l mailing list to be used by global sysops and stewards

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24542

--- Comment #1 from Milos Rancic  2010-07-27 02:21:14 UTC ---
After discussion at stewards-l list, we've concluded that it is better to have
the list with closed subscription and private archives.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24528] Dialogs broken on wmf4

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24528

--- Comment #4 from Monomium  2010-07-27 00:50:57 UTC ---
Created an attachment (id=7595)
 --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7595)
Screenshot of issue.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24528] Dialogs broken on wmf4

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24528

Monomium  changed:

   What|Removed |Added

 CC||monom...@gmail.com

--- Comment #3 from Monomium  2010-07-27 00:49:14 UTC ---
I disabled mwembed, working now without that, so you know...

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24527] default skin for german wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24527

--- Comment #3 from Erik Moeller  2010-07-26 23:37:28 UTC 
---
There was a thread on foundation-l where this matter was discussed prior to the
vote, where I've laid out some of our (WMF's) views on this issue:

http://lists.wikimedia.org/pipermail/foundation-l/2010-July/059711.html

Improving the user experience of Wikipedia for new editors is a matter of
continuing research, development, and conversation, and we'll continue to
engage in all three of those activities. But, for the reasons outlined in the
above message, we're not going to simply roll back the UI change (even if the
poll had produced an actual mandate to do so rather than a tie). 

I'm not at all meaning to discount the fact that many people in the active
editor community (in particular in the German Wikipedia) regard Vector as a
step back. As outlined above, the primary objective of Vector is to support new
users in becoming engaged in the editing process. I'm hopeful that the
conversation will now shift into a more constructive framework so that we can
best address the needs of different user groups.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24331] Global Usage and Flagged Revisions / Pending Changes

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24331

--- Comment #7 from Chad H.  2010-07-26 23:28:12 UTC 
---
(In reply to comment #6)
> Outside the scope of this, that's bug 
> 

Bug 17154, I meant to say :)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24331] Global Usage and Flagged Revisions / Pending Changes

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24331

Chad H.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #6 from Chad H.  2010-07-26 23:26:18 UTC 
---
(In reply to comment #5)
> Actually, even without FR, blanking a page (or the like) could lead to the 
> same
> bad-timing deletion mistake. Such edits (with or without FR) should be 
> reverted
> quickly though.

Outside the scope of this, that's bug 

(In reply to comment #4)
> (In reply to comment #3)
> > Thanks for the explanation.
> > I think that flaggedrevs should only update the links tables when a pending
> > revision is approved, so changing component to FlaggedRevs
> 
> That is already WONTFIXED elsewhere (breaking consistency, bots, and drains
> performance).

WONTFIX per that comment, bug 20813 and bug 15250.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #201 from V85  2010-07-26 23:02:33 UTC ---
For those of us who are less technical, but keen to see this bug resolved, is
there somewhere where we can submit alphabets, so that they may be added for
collation? I.e. where we submit the sorting order of specific languages for use
with {{sort:en}} (or whatever the mark-up will be)?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #200 from Philippe Verdy  2010-07-26 22:44:37 
UTC ---
Note that if your collator stub does not really compute true sort keys
(compacted in binary format and representing collation weights), it may return
spaces (U+0020), that is represented by byte 0x20 in the UTF-8 encoding. The
separator used must be lower than this encoded character, so the VARCHAR(N)
database field has to accept this character.

If it does not, you may offset all the UTF-8 bytes returned by your stub by 1
(because UTF-8 bytes never use the byte value 0xFF), so that you'll be able to
ue the byte value 0x20 for the separator (the UTF-8 encoded SPACE will be
stored in the sortkey field as 0x21 after it has been offseted).

This does not matter because sortkeys are opaque, so this is stimple to do in
the stub. The stored sort key field DOES NOT have to use the UTF-8 encoding
explicitly, it must just accept binary encoded bytes that can fit a non-Unicode
character. If the database wants you to specify a charset for this binary
sortable field, use ISO-8859-1, as long as the database will not alter the
binary order of ISO-8859-1 when computing ORDER BY clauses.

I really hope that we will always have the possibility of using VARBINARY(N)
fields allowing compact random byte values, because it will be much more
efficient for our use of opaque binary sortable sort keys (that are just
streams of bytes).

Be also careful about the sign of bytes (i.e. their range value), otherwise
byte 0x80.0xFF will sort before 0x00..0x7F in the order by clause. This should
be the case if the field is declared to use the ISO 8859-1 encoding with its
binary order.

Which SQL backends (and dialects) do you support in MediaWiki ? This may help
me understanding some development constraints. I know you support MySQL, but
are there simpler backends like BerkeleyDB, dBase files, or flat text files for
small projects supported only via some ODBC driver with a PHP interface ?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #199 from Philippe Verdy  2010-07-26 22:23:47 
UTC ---
>> (Note also that section headings ("first letter") will have to be 
>> "translated"
>> to correctly report the "first letter" of the Pinyin romanization, because 
>> the
>> page names listed will continue to display their distinctive ideographs ! The
>> only way to do that is to use the collation mapping exposed by
>> {{COLLATIONMAP:}})
>
>Surely the most sensible idea is just to disable the section headings
>altogether for CJK?

Don't need to do that.

The Collator instance returned by the factory for $locale="zh-latn" (which
sorts using Pinyin) just has to return an empty string for its map() method, as
long as this is a stub which can't safely map ideographs to Latin initial
consonnants of the Pinyin syllable.

Note that the syntax of the Latin Pinyin ampping should be quite similar to the
syntax used in Minnan as the Minnan syllables have more or less the same
structure as the Pinyin syllables. for ideographs that are not supported, in
the Pinyin romanization, there will be no substitution so they will sort at end
and will not start by a Latin letter.

Here also, it is possible to infer a common heading for all of them, such as
their radical component, or just the first ideographic radical encoded in the
DUCET with a non zero primary weight, or even the first stroke.

The first CJK stroke is:
31C0  ; [*10E0.0020.0002.31C0] # CJK STROKE T

But I should look at the exact sequence in the "zh" tailoring of the DUCET, in
the CLDR database.

There's a demo page for "zh-hans" collation here (in the ICU project which is
used by the Unicode's CLDR project as a reference implementation):

http://demo.icu-project.org/icu-bin/locexp?d_=fr&_=zh_Hans

The interesting part is the data for "Rules" which orders the examplar
sinograms, where the data for "Set" just show them in the numeric codepoint
order or as ranges of character with ascending numeric code point values.
But on both cases they just concentrate on the most common basic subset used in
GB2312, this is not the complete set defined in GB18030 and Unicode.

For actual transforms from Sinograms to Latin (Pinyin) there's this demo page:

http://demo.icu-project.org/icu-bin/translit

To see how the DUCET orders ideographs, look at:

http://unicode.org/charts/collation/

The first sinogram (non-stroke) defined with a non-zero primary weight in the
DUCET sequence is U+4E00 (一) at it seems that it provides a very convenient
geading for every sinogram that we can't sort or convert to Pinyin.

Note that in all cases all the sinograms are at end of the DUCET, just before
the unsupported/reserved/unassaigned characters.

The "zh-hans" is just moving all the other letters starting in the "Variable"
subset upward (in fact it just moves upwards the letters starting at Latin), to
fit the sinograms before them.

The "zh-Hant" collation is like "zh-Hans" but swaps some positions, according
to their expected radical, but also because they differ in thei stroke count.

Only about 31000 sinograms have known transiptions to Pinyin (this number is
progressing), all the other will then appear under the remaining heading group
starting by U+4E00 (一), except those in the "CJK-Extension blocks" that should
be listed under the heading U+3400 (㐀).

Most non-extension CJK have now a pinyin transcription, most CJK extensions
don't (but they are also the rarest character used, so there should not be a
lot of pages indexed there)...

>> For example in people's names whose page name is "FirstNames LastName" but 
>> that
>> we want to sort as if they were "LastName, FirstNames" by indicating only
>> {{DEFAULTSORT:LastName !}} (it should not needed to include the FirstNames in
>> the wiki text, as this sort hint will not be unique and the group of pages
>> using the same hint will still need to sort within this group using their
>> natural order). Even in that case, there's no need to bogously tack the 
>> cl_from
>> field in the stored field.
>
> How do you propose this be implemented?  We would need some character that
> sorts before all characters that can legitimately occur in a sort key.

This is exactly what UCA defines as a "tailoring". We have such a character
available that we don't use in pagenames and in sortkey prefixes: Control
characters.

Note that control characters are present in the DUCET, and they are NOT ALL
ignorable. The first of them is TAB (U+0009) and it is the first character that
we DON'T USE, and that has a primary weight in the DUCET and that is not
ignorable or null.

All the characters have null weights are listed wihin the NULL group, which is
immediately followed by ignorable characters.

TAB has a primary weight of 0201 in the DUCET (it comes far later, after all
the ignorables)

The first ignorable character has a primary weight 0021, so the primary weight
0001 is free to serve as the separator.

All we have to do is then to tailor the pr

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #198 from Aryeh Gregor  2010-07-26 
21:43:21 UTC ---
(In reply to comment #187)
> Drop this tacking immediately in the PHP code: the cl_sortkey is only intended
> to store the clear-text sortkey "hint" specified in {{DEFAULTSORT:sortkey}} or
> [[category:...|sortkey]] to override the sort order, and this clear-text
> sortkey is not really a true sortkey but a sort hint to override the default
> sort order. 
> 
> For example in people's names whose page name is "FirstNames LastName" but 
> that
> we want to sort as if they were "LastName, FirstNames" by indicating only
> {{DEFAULTSORT:LastName !}} (it should not needed to include the FirstNames in
> the wiki text, as this sort hint will not be unique and the group of pages
> using the same hint will still need to sort within this group using their
> natural order). Even in that case, there's no need to bogously tack the 
> cl_from
> field in the stored field.

How do you propose this be implemented?  We would need some character that
sorts before all characters that can legitimately occur in a sort key.

(In reply to comment #197)
> I note that you have started to define the Collator class as the Language
> class.

This is completely provisional and can easily be changed later.  As far as I
understand, I'm not the one who will work on it.

> But really, to test a complete implementation of the CollatorFactory, you'll
> need to be able to expose it in the two optional builtin parser functions that
> I described. As this can be clearly developped separately even if you start
> with a stub for the factory, and tested with the very basic Parser Functions
> installed on a test server.
> 
> So I maintain my position for the non-risky ParserFunctions (notably also
> because it will be simpler for an existing non-Wikimedia installation of
> MediaWiki to install the simple functions only, without upgrading to the new
> schema immediately, knowing that the factory can also be a basic stub as well
> on these installations).

Upgrading the schema will be handled by running maintenance/update.php, which
must be run on every update anyway.  We typically have a number of schema
changes in every release, and those always must be applied when deploying the
new code.  So this is not an issue.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #197 from Philippe Verdy  2010-07-26 21:01:11 
UTC ---
I note that you have started to define the Collator class as the Language
class.

Well I'm not sure that this should be the same class: a language has several
collators, even if a collator is for only one language (including a virtual
language like "root" which is the base of all localizations including English,
with lots of common properties that are shared in multiple languages derived
from root).

Also I note that the collator you define is a stub. Great for your development
in the SQL schema, but someone else must work in implementing the
CollatorFactory, using ICU, or a full PHP implementation, or only a stub,
depending on the PHP script path you'll require() to load this factory class.

Technically, collators also share lots of properties across several languages.
This is why it should be separated from the Language class.

May be the Language class can query the CollatorFactory about the list of
collators (i.e. their complete locale code, including options) that are
supported by that language, using an interface method of the loaded global
CollatorFactory instance.

This way, a stub factory, building a single Collator instance will still work
immediately.

Someone with expertise in Unicode collations will help you build the Factory if
you want a PHP-only implementation.

Someone else with ICU expertize could also work on its existing integration in
PHP (needs testing in the MediaWiki installation scripts for deployments) and
to use it in the CollatorFactory and in the Collator class.

The most tricky development is the Collator::map() function, because Unicode
does not describe the algorithm completely.

I know the principles and could offer help if you give some pointers where it
would be beneficial.

But really, to test a complete implementation of the CollatorFactory, you'll
need to be able to expose it in the two optional builtin parser functions that
I described. As this can be clearly developped separately even if you start
with a stub for the factory, and tested with the very basic Parser Functions
installed on a test server.

So I maintain my position for the non-risky ParserFunctions (notably also
because it will be simpler for an existing non-Wikimedia installation of
MediaWiki to install the simple functions only, without upgrading to the new
schema immediately, knowing that the factory can also be a basic stub as well
on these installations).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #196 from Philippe Verdy  2010-07-26 20:37:46 
UTC ---
Note that the CollatorFactory may fail to locate the specified locale for which
a collator is being requested. Additionally, several locales may share exactly
the same collator.

In all cases, the collatorFactory will return a valid Collator object, whose
locale can be identified: the Collator object returned by:

$collator = $wgCollatorFactory->get($locale, $level);

will have a property that will contain the effective locale code (normalized)
and an other property containing the collation level from which it was
effectively built. You should be able to access it simply with something like:

$effectiveLocale = $collator->locale();
$effectiveLevel = $collator->level();

after just getting the collator instance from the factory.

This may be useful to avoid storing duplicate equivalent binary sortkeys, or
simply to determine which effective locale to use in SQL select queries (to
retrieve the sorted list of pagenames ordered by a specified locale), when the
SQL schema will be able to store several sortkeys for the same page in the same
category.

The factory will also instanciate a collator with an effective locale and an
effective collation level only once, caching it in an internal array, for
repeated use.

This will save the complex preparation of tables, and will avoid building
tables for all supported languages (for example in Commons where lots of
languages may be desirable, weahc one with possibly several sort options, or
supported conversions to other scripts or script variants).

The factory however should probably be able to load the DUCET table associated
to the CLDR "root" locale completely and immediately when it is first
instanciated and stored in the global variable (there's probably no need to
test this each time vecaue of lazy initializations with null member fields);
and it should most probably build the default collator (for
$locale=$wgContentLanguage, and $collationlevel=1) immediately, storing it in
the first position of its member array of already prepared Collator instances.

But you may think the opposite, in order to speedup the server startup by some
(milli-)seconds or reduce the initial CPU/memory stress in the garbage collator
of PHP. However I'm not convince that the server will be ready faster, and the
extra tests that will be performed at each use of the $wgCollatorFactory->get()
method may impact the performance at runtime...

Note also the ICU uses the same approach of a CollatorFactory to build and
cache reusable Collator instances, because it's a proven good design pattern
for implementing and using collators.

A collator object may also be used to compare to texts without even generating
their sortkeys, or without mapping them, so it may help to include in the
Collator interface this method:

$collator->compare($text1, $text2);

that will return an integer (in other words, a Collator also implements the
Comparator interface), by parsing $text1 and $text2 collation element by
collation element up to the end at level 1, comparing their collation weights
only at theis level, before restarting with the next level. When the collator
was instanciated at level 1, the successive collation elements need not be
stored, but for higher levels, it helps if they are parsed only once and kept
in an indexed array that will allow faster lookup for the next levels in the
table of collation weights for these levels.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24528] Dialogs broken on wmf4

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24528

--- Comment #2 from Adam Miller  2010-07-26 20:02:31 UTC 
---
Related screenshot is here:
http://en.wikipedia.org/wiki/File:Dialogs_not_working.png

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24528] Dialogs broken on wmf4

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24528

--- Comment #1 from Adam Miller  2010-07-26 20:01:46 UTC 
---
Here's what I was able to figure out so far: 

Only occurs when both Twinkle and mwEmbed gadgets are enabled. Once they are
enabled, it seems like jquery ui is not loaded on the edit page.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #195 from Aryeh Gregor  2010-07-26 
19:50:19 UTC ---
By the way, I'm keeping track of progress here:

http://www.mediawiki.org/wiki/User:Simetrical/Collation

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #194 from Aryeh Gregor  2010-07-26 
19:49:15 UTC ---
(In reply to comment #190)
> Yes Language::firstLetterforList(s) maps more or less to COLLATIONMAP, but
> COLLATIONMAP is a more generic concept which reflects what is defined in
> Unicode standard annexes, which speaks about various mappings (including 
> collan
> mapppings, but also case mappings)

Which particular Unicode standards are relevant here?  It would probably be a
good idea for me to take a look at them.

> For some categories, it should be convenient also to be able to use longer
> substrings, containing more than one grapheme cluster (in Wiktionnary for 
> lists
> of terms belonging to a language, or in lists of people names, a category may
> need to be indexed and anchored with section headings containing the first 2 
> or
> 3 grapheme clusters, because the first grapheme is not discriminant enough and
> will remain identical an all columns of the disaplyed list on one page, and
> even sometimes on several or many successive pages : the first letter heading
> does not help, and is just an unneeded visual pollution)
> 
> For other categories that have very few contents, too many headings are
> frequently added that also appear as pollution. Being able to suppress all of
> them, by specifying 0 graphemeclusters in that category will better help
> readers locate the wanted item.

This is all beyond the scope of what I'm currently doing, but it should be
possible to add on without too much trouble as a separate project.

> Why do I think that exposing the functions as parser functions will be useful 
> ?
> that's because it allows the implementation to be tested extensively on lots 
> of
> cases, but only within a limited set of pages, long before the schema is
> developed, finalized and finally deployed.

This presupposes that the sortkey generation algorithm is settled upon before
the database changes are.  In fact, it's exactly the opposite: I've been
contracted to do the backend changes, and other people will figure out how
exactly to generate the sortkeys later.  Really, we could do the changes in
either order.

> Both functions will be deployable rapidly, even on wikis that won't want to
> apply the schema change (so they will continue to use a single collation order
> for ALL their categories, and will anyway be able to sort specific categories
> using another supplied locale matching the category name).
> 
> If you think about it, changing the SQL schema may be rejected at end by lots
> of people.

The schema change will be part of the core software and will not be an optional
update.  Anyone who doesn't want to accept it will likely have to stick with
1.16 forever, because we're not going to support the old schema.

> Exposing the parser functions will provide a convenient alternative
> that can be deployed much more simply, and with MUCH LESS risks, using the
> existing facilities offered by [[category:...|sortkey]] and
> {{DEFAULTSORT:sortkey}}, except that their parameter will be computed using 
> the
> exposed {{SORTKEY:}} function:
> 
>   {{DEFAULTSORT:{{SORTKEY:text|locale|level
> 
> or:
> 
>   [[category:...|{{SORTKEY:text|locale|level}}]]
> 
> both being generalizable through helper templates.

It's not particularly less risky.  It does encourage each wiki to hack around
the problem locally instead of pushing for a proper fix in the software.  You
shouldn't have to do DEFAULTSORT on any pages where the right sorting is
human-detectable -- it should only have to be for things like "Abraham Lincoln"
being sorted as "Lincoln, Abraham", which the software can't do automatically.

> (Note also that section headings ("first letter") will have to be "translated"
> to correctly report the "first letter" of the Pinyin romanization, because the
> page names listed will continue to display their distinctive ideographs ! The
> only way to do that is to use the collation mapping exposed by
> {{COLLATIONMAP:}})

Surely the most sensible idea is just to disable the section headings
altogether for CJK?

> My opinion is that the same category should be sortable using different
> locales, and that's why they should support multiple sortkeys par indexed 
> page,
> one for each specified locale. Some wikis will only sort on the
> {{CONTENTLANGUAGE}} by default, but the Chinese Wiktionnary will benefit of
> sorting automatically all categories using at least the default "zh" locale
> which is an alias for "zh-hans", plus the "zh-hant" locale for traditional
> radical/stroke order, "zh-latn"  for the Pinyin order, and "zh-bpmf" for the
> Bopomofo order.
> 
> The exact locale to which "zh" corresponds will be a user preference, but one
> will be able to navigate by clicking the automatically generated links that
> will allow them to specify the other collation orders supported specifically 
> by
> the category or by default throughout the wiki project.

This is doable if it's desir

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #193 from Philippe Verdy  2010-07-26 19:41:57 
UTC ---
Exemple of interface for you:

 '')
  $locale .= '-x-' . $options; // append sort options if any (like 'uc', 'lc')
$level = 1; //use collation level 1 by default

$collator = $wgCollatorFactory->get($locale, $level);

...

// use the collator object to compute opaque sortkeys (opaque binary string)
// to store in categories:

$sortkey = $collator->sortKey($text);

// optionally map it to plain-text, if the database can't store and
// sort VARBINARY(N) fields, but only VARCHAR(N) objects:

$sortkey = base32($sortkey);

...

// use the collator object to compute a heading on the fly from a pagename:

$collationElements = 1; // by default generate only 1 collation element

$heading = $collator->map($pageName, $collationElements);

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

Derk-Jan Hartman  changed:

   What|Removed |Added

 CC||hart...@videolan.org
  Component|General/Unknown |Site requests

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #192 from Philippe Verdy  2010-07-26 19:20:35 
UTC ---
Note that this is the minimum functional interface for the Collator class.
Other methods will be certianly needed to cache the already prepared collators,
or to cache the preloaded tailoring tables and the common DUCET.

In other words, the Collator::Collator() constructor is in fact probably using
the service of a CollatorFactory class that will cache the needed shared data.
This will save a lot of overhead and will be important for the performance.

This factory should NOT be used directly by the SQL schema extension, that MUST
only use the Collator::getCollator(locale, level) static function which will
use the CollatorFactory in order to instantiate the Collator object through its
constuctor.

The CollatorFactory will use ICU, most probably, via its already existing
PHP-extension interface module. But a basic PHP-only implementation is still
possible without using ICU immediately, or if MediaWiki must be kept compatible
with existing PHP servers that can't load such native extensions (using DLLs or
shared libraries or requiring to recompile/relink PHP itself) in their
installation.

The CollatorFactory should NOT prepare all supported locales. Only those that
are requested **on demand**.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 21576] Installation gives misleading error message on empty wikiuser password

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=21576

Bug 21576 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20627] Installation dialogue should be available in languages other than English.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20627

Bug 20627 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20781] Move 'mainpagetext' message to installer's .i18n file once it exists

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20781

Bug 20781 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20242] Installer demands DB credentials for SQLite

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20242

Bug 20242 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 19991] Provide default time zone selection in installer

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=19991

Bug 19991 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 19129] Make the installer handle storage engines better

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=19129

Bug 19129 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17394] Make the installer check whether it's installing an old version

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=17394

Bug 17394 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16902] Installer spewing warnings due to disable_functions

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=16902

Bug 16902 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 13409] Installer script prompts could use clarification

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13409

Bug 13409 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 13230] Split web-based upgrade from install

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13230

Bug 13230 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 11013] Installer database driver detection needs rewriting for robustness

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=11013

Bug 11013 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 10596] Please let installer auto-enable extensions bundled in a MediaWiki tarball

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=10596

Bug 10596 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 10541] Front / back end separation of setup script

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=10541

Bug 10541 depends on bug 20628, which changed state.

Bug 20628 Summary: New-installer branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20628] New-installer branch (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20628

Chad H.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Chad H.  2010-07-26 19:11:42 UTC 
---
Closing this since it's been merged to trunk.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #191 from Philippe Verdy  2010-07-26 19:07:34 
UTC ---
In all this discussion it appears that the development can be made in two
separate projects developped independantly.

You can continue to develop the SQL schema extension, provided that:

- you call a PHP function/method that will be developped separately in a
"Collator" class, to compute the collation sortkeys for each locale and
specified collation level.

- you call a PHP function/method that will be developped separately in a
"Collator" class, to compute the collation mappings for each locale and
specified collation level and maximum grapheme clusters, in order to generate
the headings on the fly in the category list

- you think about a HTTP query parameter that will allow to change the locale
(this parameter exists, it's "uselang", but another one will be needed
eventually to specify sort options like "-x-lc" or "-x-uc" (the "-x-" separator
will be used impliclty. So the HTTP query may contain: &uselang=fr&opt=lc).
These parameters will be used later when you'll be able to store multiple
sortkeys.


Separately, another project will implement the Collator class, that will load
the DUCET table, load the tailorings designed per locale or
locale+"-x-"+option, and prepare the table of collation elements and their
associated collation weights for each level. Then it will implement the
methods:

- Collator::Collator(locale, level=1) which instanciates a Collator object for
the specified locale string (language + optional options) and the collation
level (it does not need to prepare the full table of colaltion weights, just
those needed for the specified level). The default level will be 1.

- Collator::sortkey(text) which returns the opaque collation key (a binary
array of bytes) for the specified Collator instance.

- Collator::map(text, maxelements='') which returns the humane readable text
after applying the collation mapping associated to the Collator instance. It
will stop after returning at most 'maxelements' collation elements in the
remapped string, or will process all the text if maxelements is null or not
specified. For category headings, you'll give by default maxelements=1 (unless
another calue was specified when preparing a specific locale with the extra
option of {{SORTAS:locale|maxelements}} in the visited category page.


Separately another simple project will use the Collator class to expose them in
parser functions. In fact this third project will be very easy and fast to
complete, even if the Collator class is not fully developped with all its
options.

A very basic Collator class can be used to develop the parser function
extension that will expose:
-  {{SORTKEY:text|locale|level}}
   defaults: locale={{CONTENTLANGUAGE}}|level=1
- {{COLLATIONMAP:text|locale|level|maxelements}}
   defaults: locale={{CONTENTLANGUAGE}}|level=1|maxelements=

With it you can immediately deply it on a test wiki server, where you'll build
test lists in a "sortable wikitable". and you can continue building the
Collator class. to support various locales and all the needed options.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 22884] "localhost" doesn't work for $wgServer on Windows

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=22884

Chad H.  changed:

   What|Removed |Added

Summary|"localhost" is not resolved |"localhost" doesn't work
   |by mysql functions in   |for $wgServer on Windows
   |PHP5.3 on Vista |

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24133] generated LocalSettings.php should not be world-readable

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24133

Chad H.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||innocentkil...@gmail.com
 Resolution||FIXED

--- Comment #1 from Chad H.  2010-07-26 19:03:14 UTC 
---
Fixed in r69322. We don't write LocalSettings.php to the webserver at all in
the new installer.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 164] Support collation by a certain locale (sorting order of characters)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=164

--- Comment #190 from Philippe Verdy  2010-07-26 18:38:10 
UTC ---
Yes Language::firstLetterforList(s) maps more or less to COLLATIONMAP, but
COLLATIONMAP is a more generic concept which reflects what is defined in
Unicode standard annexes, which speaks about various mappings (including collan
mapppings, but also case mappings)

One bad thing about the name Language::firstLetterforList(s) is that it implies
that this should only be the first letter. In fact, for many locales, the
significant unit is not the letter, but the collation element (for exemple
digrams like "ch" or trigrams like "c’h").

For some categories, it should be convenient also to be able to use longer
substrings, containing more than one grapheme cluster (in Wiktionnary for lists
of terms belonging to a language, or in lists of people names, a category may
need to be indexed and anchored with section headings containing the first 2 or
3 grapheme clusters, because the first grapheme is not discriminant enough and
will remain identical an all columns of the disaplyed list on one page, and
even sometimes on several or many successive pages : the first letter heading
does not help, and is just an unneeded visual pollution)

For other categories that have very few contents, too many headings are
frequently added that also appear as pollution. Being able to suppress all of
them, by specifying 0 graphemeclusters in that category will better help
readers locate the wanted item.

The collation map also has several levels of implementations, which match
exactly the same levels as collation levels used to generate sort keys.



About sort keys now:

As sort keys are intended to be opaque binary objects, they do not qualify as
being used directly as a parserfunction, without being exposed by a
serialization to safe Unicode text, even if it means nothing for reader. That's
why I proposed a Base-36 mapping to plain ASCII which will still sort correctly
in binary order, and for use in sortable tables, but it could use any arbitrary
Base that sorts correctly using binary ordering, and that uses ONLY valid
Unicode characters.

The chosen base should be easy to compute, but all the standard Base-64
variants do not qualify (there's no warranty for the last two "letters" of all
base-64 variants). We could use Base-62 (using all 10 digits, and the 26 pairs
of Basic Latin letters), or Base-32 (simpler to compute but will generate
longer texts). The only intent is not really to make the string visible in
pages, but to help in the generation of accurate sort keys in sortable columns.

For now these sort keys are generated by templates as invisible text spans
(using a CSS style="display:none" attribute), but ideally, the templates used
in sortable tables that generate custome sortkeys should put them in some HTML
attribute that can be specified on table cells, and that the Javascript will
use directly. In my opinin, these opaque strings should be as compact as
possible, but still safe for use inclusing in pages, and directly usable by
simple Javascript without requiring any complex reimplemementation of UCA in
the Javascript code.


Why do I think that exposing the functions as parser functions will be useful ?
that's because it allows the implementation to be tested extensively on lots of
cases, but only within a limited set of pages, long before the schema is
developed, finalized and finally deployed.

In other words, it will not block the development of the schema update, as long
as we agree about what are the essential functions to support, i.e. their
interface that will be exposed (partly) in parser functions.

Also because I'm convinced that the exposed parser functions will not have this
syntax changed, and that what they return will be well known:

- The {{COLLATIONMAP:}} function is very well described and will effectively
return humane-readable text. Its formal implementation should follow the
standard Unicode definitions.

You can expose it at least in a test wiki where you'll be able to track very
easily the result and progress of its implementation (just create a page
containing test words in various languages, arranged in a Wikitable).

- The {{SORTKEY:}} function can be exposed as well (and tested on the same test
page for various languages, using the same list of words). Its result will be
opaque for humane and compact. It will be easy to assert that it generates the
expected sort order by using it in a sortable wikitable.


Both functions will be deployable rapidly, even on wikis that won't want to
apply the schema change (so they will continue to use a single collation order
for ALL their categories, and will anyway be able to sort specific categories
using another supplied locale matching the category name).

If you think about it, changing the SQL schema may be rejected at end by lots
of people. Exposing the parser functions will provide a convenient alternative
that can be deployed much

[Bug 24552] New: Wiki-email to store a hash of the message text

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24552

   Summary: Wiki-email to store a hash of the message text
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Email
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: ft2.w...@gmail.com


Can mediawiki store together with the hash of the recipient, a hash of the body
text of an email with white space removed (if over some minimum number of
characters)?

Rationale - while this would be effectively impossible to reverse back to text
(and therefore preserves privacy of email content), it means that a sender or
recipient claims in a harassment case can prove their account of the message
sent or received is accurate and the text cited has not been tampered, because
it can be hashed back to the same digest.

This is computationally trivial, has no impact on privacy (minimum number of
characters), and could be extremely useful in serious cases of dispute,
harassment, solicitation, sexual solicitation, grossly untoward suggestion,
etc, if one party claims the email text was as submitted and the other party
asserts it has been tampered with and is falsified. 

Basically without breaching privacy, it would allow a sender or recipient to
prove to WMF if needed that the actual content of an email is as claimed, or
had been amended.

It's unlikely to be needed much, but when it is, it's likely to be a serious
case and something that's valuable to have in place. By nature it does not
appear to risk privacy otherwise, because the hash could not be used to verify
a text without WMF help and cannot be converted back to text by WMF or any
person. It would purely protect the sender and recipient by allowing them to
prove or disprove email content in a serious matter.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 15607] Implement the Interlanguage extension in Wikipedia

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=15607

HenkvD  changed:

   What|Removed |Added

 CC||h...@glind.nl

--- Comment #42 from HenkvD  2010-07-26 17:58:36 UTC ---
What I miss is the possiblity to edit or link to the list of interwiki when you
are for instance on [http://enwiki.smolenski.rs/index.php?title=Los_Serrano Los
Serano on enwiki]. 
I woild suggest some kind of link or button at the In other languages box at
tah page.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24551] Make changes to the Hungarian (hu) LimeSurvey translation

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24551

Raimond Spekking  changed:

   What|Removed |Added

   Attachment #7594|application/octet-stream|text/plain
  mime type||
   Attachment #7594|0   |1
   is patch||

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24551] New: Make changes to the Hungarian (hu) LimeSurvey translation

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24551

   Summary: Make changes to the Hungarian (hu) LimeSurvey
translation
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Keywords: shell
  Severity: enhancement
  Priority: Normal
 Component: Site requests
AssignedTo: rhals...@wikimedia.org
ReportedBy: az1...@gmail.com
CC: gti...@gmail.com, bdamo...@gmail.com,
cbrown1...@gmail.com


Created an attachment (id=7594)
 --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7594)
Hungarian language file from Bence Damokos

Please update the translation file for Hungarian (hu) in LimeSurvey for the
upcoming 2010 Fundraising Survey. The new file resolves an issue with having
both formal and informal tones within the survey. Our testing deadline is July
27, 2010 (tomorrow), so if you could get to this today, that would be great!

The file that needs to be replaced should be in LimeSurvey's
/locale/hu/LC_MESSAGES/ folder. The replacement file is attached.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20069] Implement PHP syntax validity checking to upload results to CodeReview tests

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20069

Max Semenik  changed:

   What|Removed |Added

 CC||s...@reedyboy.net

--- Comment #3 from Max Semenik  2010-07-26 17:11:04 UTC 
---
*** Bug 24543 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24543] Commit hook for syntax checking

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24543

Max Semenik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Max Semenik  2010-07-26 17:11:04 UTC 
---


*** This bug has been marked as a duplicate of bug 20069 ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24188] Bold and Italic Icons in Vector toolbar to 'B' and 'I' in Malayalam

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24188

Adam Miller  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Adam Miller  2010-07-26 17:04:07 UTC 
---
I addressed the problem as I understand it in r69950. Hope that helps.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24493] Enhanced toolbar issues (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24493

Bug 24493 depends on bug 24188, which changed state.

Bug 24188 Summary: Bold and Italic Icons in Vector toolbar to 'B' and 'I' in 
Malayalam
https://bugzilla.wikimedia.org/show_bug.cgi?id=24188

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24543] Commit hook for syntax checking

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24543

--- Comment #2 from Chad H.  2010-07-26 16:59:38 UTC 
---
Pre-commit? Ugh...

For the same reasons as bug 21211, this would be annoying. Not opposed to the
idea in concept, but it needs some fleshing out.

Perhaps if we can come up with a non-blocking way to do hooks first.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24467] Simple email address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24467

Platonides  changed:

   What|Removed |Added

 CC||cb...@wikimedia.org,
   ||platoni...@gmail.com

--- Comment #4 from Platonides  2010-07-26 16:55:20 UTC 
---
What if they wanted to email OTRS instead?

That wouldn't be appropiate for a mailing list. And they would still need an
intermediate step in mailman. So wherever they find that url, they should
bookmark the list name.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24550] New: Allow svn usernames in bugzilla

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24550

   Summary: Allow svn usernames in bugzilla
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Normal
 Component: Bugzilla
AssignedTo: pdha...@wikimedia.org
ReportedBy: platoni...@gmail.com
CC: innocentkil...@gmail.com


The developer usernames are tied to the wiki usernames (code_authors table in
mediawikiwiki db), and the wiki usernames have associated emails.

It should be possible to CC or assign a bug to a svn username and get 'the
right thing done', either by translating to an username only at sending time or
at the first stage when translating (that would disclose emails, but since that
is for developers, that should be usbscribed in bugzilla, seems ok).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=671

--- Comment #55 from ABX  2010-07-26 16:25:37 UTC ---
(In reply to comment #54)
> I would say it could convert the first reflexive link in the
> intro section of the article body to a DFN equally well, therefore allowing 
> DFN
> is not necessary for this use case.  The advantage is that the link uses wiki
> syntax, not HTML syntax.

How would that work for wiktionaries, wikispecies, wikisources with OCR of old
encyclopedias and all other places where main definition is placed differently
than in pedia?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

--- Comment #6 from Maria Schiewe  2010-07-26 
18:22:23 CEST ---
It will be fixed by “perfect world” programmers enhancing their code with
WAI-ARIA, because to interact with an element you must know it’s interactive.
*smile*

As for the solution, yes, I think adding an  inside the  will solve the
problem. Still it would be neat to have an indication about the collapsing.
Normally, one could do this over the alternative text of the image, but here we
have a background image that can have no alternative text.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=671

--- Comment #54 from Christopher Yeleighton  2010-07-26 
16:15:37 UTC ---
(In reply to comment #51)
> * On other stuff:
> 
> --- Comment #48 from Christopher Yeleighton 2010-07-25 08:42:53 UTC ---
> > http://en.wikipedia.org/w/index.php?title=Newt_Gingrich&oldid=375340399
> 
> Why would we do that? The text is question isn't a link, so it shouldn't be
> marked up as one.  And doing so wouldn't fix anything, since there isn't
> anything in that syntax or its [mis]use that tells the parser "this is the
> defining instance", something that requires human judgment.
> 

The text in question is a relative link that happens to be reflexive.  The
engine detects that the link is reflexive so it renders the link as STRONG
(instead of A).  I would say it could convert the first reflexive link in the
intro section of the article body to a DFN equally well, therefore allowing DFN
is not necessary for this use case.  The advantage is that the link uses wiki
syntax, not HTML syntax.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

--- Comment #5 from Derk-Jan Hartman  2010-07-26 17:56:43 
CEST ---
It's not a perfect world. I agree that it is HARD to do for assistive
technology, but that IS where it primarily should be fixed. And it will,
because the web is getting more interactive by the day. The idea that only
interactive elements are capable of interaction is getting quickly outdated.

Now to get back on solving this. Adding a  element inside the  ?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

--- Comment #4 from Maria Schiewe  2010-07-26 
17:45:23 CEST ---
I don’t agree that this is a bug in the assistive technology. How should a
screenreader recognize that the h5 can be interacted with? By inspecting all of
the associated Javascript code? Hardly feasible. Here a non-interaction element
(h5) is used to build some interaction. That is no good style, the element is
misued. WAI-ARIA mark-up would offer a solution but isn’t supported by all
screenreaders yet—and not by older versions.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 367] Markup accessibility issues (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=367

Derk-Jan Hartman  changed:

   What|Removed |Added

 Depends on||23428

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

Derk-Jan Hartman  changed:

   What|Removed |Added

 Blocks||367

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24544] Completely inaccessible watchlist tab

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24544

Derk-Jan Hartman  changed:

   What|Removed |Added

 Blocks||367

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 367] Markup accessibility issues (tracking)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=367

Derk-Jan Hartman  changed:

   What|Removed |Added

 Depends on||24544

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24545] ImageMagick generated Thumbnails get messed up (wrong colors) in some cases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24545

Derk-Jan Hartman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hart...@videolan.org
 Resolution||WORKSFORME

--- Comment #3 from Derk-Jan Hartman  2010-07-26 17:38:17 
CEST ---
Tested this on Wikipedia. The problem does not occur on Wikipedia, which
indicates that this most likely depends on the version of ImageMagick that you
have installed. Consider upgrading to the latest and greatest...

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24544] Completely inaccessible watchlist tab

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24544

Derk-Jan Hartman  changed:

   What|Removed |Added

 CC||hart...@videolan.org

--- Comment #1 from Derk-Jan Hartman  2010-07-26 17:32:35 
CEST ---
If the image wasn't a background image, but a real  tag, the alt attribute
could be used.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

Derk-Jan Hartman  changed:

   What|Removed |Added

 CC||hart...@videolan.org

--- Comment #3 from Derk-Jan Hartman  2010-07-26 17:22:47 
CEST ---
This is a bug in screenreader software in my opinion. The onclick html
attribute should be avoided in favor of DOM hooks. If the screenreader software
then doesn't see it as a clickable element, then the screenreader software
really ought to be improved.

Not saying that it doesn't affect accessibility, just saying that screenreader
software producers have a responsibility as well here

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=671

--- Comment #53 from Michael Zajac  2010-07-26 10:03:29 CDT 
---
(In reply to comment #52)
> (In reply to comment #50)
> > Regarding use cases for the address element, I forgot to mention the best 
> > one:
> > to mark up a talk-page user sig.
> 
> This is invalid in HTML5:

The default sig contains a link to the home page of the writer. That is
relevant contact info. 

It's not as specific as one might want, since all contributors' addresses are
applied to the entire page body, rather than each to its own comment, but
that's a perfectly valid interpretation. From HTML5:

> If node is a body element
> The contact information consists of all the address elements that have node 
> as an ancestor and do not have another body or article element ancestor that 
> is a descendant of node.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 23428] Headers of collapsible (sub)menus in sidebar not accesible via keyboard

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=23428

Maria Schiewe  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||maria.schi...@wikimedia.de
 Resolution|FIXED   |

--- Comment #2 from Maria Schiewe  2010-07-26 
16:44:01 CEST ---
While this now allows users to collapse the menu, it still is not clear to the
user that he can do so. The element is still a heading level 5. No screenreader
user will suspect that he can interact with the heading to collapse a menu. You
must either insert some text indicating the possibility and/or use other
elements that are known to the user for interaction, i.e. a link, or set the
clickable attribute.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24467] Simple email address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24467

sunil  changed:

   What|Removed |Added

 CC||vss...@gmail.com

--- Comment #3 from sunil  2010-07-26 14:39:39 UTC ---
I too believe so.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

--- Comment #3 from Romaine  2010-07-26 14:29:54 UTC ---
The four users active have agreed on:
http://nl.wikisource.org/wiki/Wikisource:De_kroeg#Auteurs

Romaine

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

Raimond Spekking  changed:

   What|Removed |Added

   Keywords||shell

--- Comment #2 from Raimond Spekking  2010-07-26 
14:28:00 UTC ---
Please provide a link to the community consenous.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

--- Comment #1 from Romaine  2010-07-26 14:27:13 UTC ---
The talk-namespace with this namespace would be:

Overleg_auteur:


in line with other namespaces.

Romaine

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24549] New: New namespace for nl-wikisource

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24549

   Summary: New namespace for nl-wikisource
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: Normal
 Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: romaine_w...@yahoo.com


The small community of nl-wikisource requests a new namespace, just as other
wikisources have a similar namespace for authors.

Requested name: Auteur


Thanks,
Romaine

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16161] CodeReview's diff shows whitespace changes while ViewVC's doesn't

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=16161

Bryan Tong Minh  changed:

   What|Removed |Added

 CC||bryan.tongm...@gmail.com

--- Comment #5 from Bryan Tong Minh  2010-07-26 
14:22:35 UTC ---
Needs fixing in the PECL extension. In svn.c diff_options should be something
like {"-w", 0}.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16161] CodeReview's diff shows whitespace changes while ViewVC's doesn't

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=16161

MZMcBride  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||b...@mzmcbride.com
   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=18143
 Resolution|WONTFIX |

--- Comment #4 from MZMcBride  2010-07-26 14:16:46 UTC ---
This isn't a WONTFIX. It's an actual issue that needs to be addressed.
Re-opening.

Closely related to this issue is bug 18143. It's been added here as a see also.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16161] CodeReview's diff shows whitespace changes while ViewVC's doesn't

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=16161

MZMcBride  changed:

   What|Removed |Added

 CC||s...@reedyboy.net

--- Comment #3 from MZMcBride  2010-07-26 14:14:53 UTC ---
*** Bug 24547 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24547] Make CodeReview ignore whitespace diffs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24547

MZMcBride  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b...@mzmcbride.com
 Resolution||DUPLICATE

--- Comment #2 from MZMcBride  2010-07-26 14:14:53 UTC ---
This is essentially a dupe of bug 16161. I have no idea why bug 16161 was
WONTFIXed. I'm resolving this bug as a dupe and I'll re-open bug 16161.

*** This bug has been marked as a duplicate of bug 16161 ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24548] New: Insert link dialog problems

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24548

   Summary: Insert link dialog problems
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: UsabilityInitiative
AssignedTo: tpars...@wikimedia.org
ReportedBy: liang...@gmail.com
CC: roan.katt...@gmail.com, ngau...@wikimedia.org,
amil...@wikimedia.org


Browser: Iceweasel 3.5.8

Steps:

1. Navigate to
http://prototype.wikimedia.org/s-6/index.php?title=Main_Page&action=edit
2. Click in the textbox
3. Click insert link button
4. Put http://prototype.wikimedia.org/sandbox.6/Portal:Contents in the first
field. To an external web page is selected automatically
5. Click insert link. I'm prompted The URL you specified looks like it was
intended as a link to another wiki page. Do you want to make it an internal
link?
6. Click Internal link
7. The insert link dialog is on the screen now. Text in two fields is changed.
To a wiki page is selected
8. I cannot change neither of the two fields.
9. Click on To an external web page
10. It doesn't seem to be selected, but the text (and icon) at top-right
changes from "Page exists" to "External link"
11. Click insert link. An internal link is inserted

The bug appears in step 10.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24547] Make CodeReview ignore whitespace diffs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24547

p858snake  changed:

   What|Removed |Added

 CC||p858sn...@gmail.com
   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=18143

--- Comment #1 from p858snake  2010-07-26 13:54:40 UTC ---
Adding 18143 as a See also, its close/similar in requested description as well.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24547] New: Make CodeReview ignore whitespace diffs

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24547

   Summary: Make CodeReview ignore whitespace diffs
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: CodeReview
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: s...@reedyboy.net
CC: innocentkil...@gmail.com


http://www.mediawiki.org/wiki/Special:Code/MediaWiki/69443#c7789 onwards

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24543] Commit hook for syntax checking

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24543

--- Comment #1 from Max Semenik  2010-07-26 13:25:43 UTC 
---
For the reference: there is maintenace/checkSyntax.php which checks not only
for syntax errors, but also for other common problems, such as BOM's. When run
on working copy with --modified switch, it will check quickly only modified
files. It's mentioned at
, but that page is
not advertised enough.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=671

--- Comment #52 from Aryeh Gregor  2010-07-26 
13:24:29 UTC ---
(In reply to comment #50)
> Regarding use cases for the address element, I forgot to mention the best one:
> to mark up a talk-page user sig.

This is invalid in HTML5:

"""
The address element represents the contact information for its nearest article
or body element ancestor. If that is the body element, then the contact
information applies to the document as a whole.

. . .

The address element must not be used to represent arbitrary addresses (e.g.
postal addresses), unless those addresses are in fact the relevant contact
information. (The p element is the appropriate element for marking up postal
addresses in general.)
"""
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-address-element

 is actually a weird element, its name is very misleading.  A correct
usage can be found at http://aryeh.name/siteinfo.html, for example.  Most
usages in the real world are wrong per the specs.  It never meant just "an
address".  So on a wiki, with no  elements, it would only be
legitimate to use it to give contact info for the author of the whole page. 
Which is a very marginal use.  But in the end, probably almost no one will use
it correctly or incorrectly, so meh, whatever.

(In reply to comment #51)
> Right.  It may not be helpful in places like this to play devil's advocate,
> since the other side is liable to take it seriously and argue against the
> position. :-/

I wasn't consciously doing it, I just have an unfortunate tendency to argue on
principle.

> HTMLWG: Okay, I can concede on that, if your HTML5 proposal is rejected AND 
> you
> appeal the rejection AND the appeal looks like it might go somewhere.  I would
> not want us to postpone implementation of kbd and samp for a year or more
> otherwise, though.  Kind of a WP:SNOWBALL thing, really.  But, I've already
> agreed that if there's genuine uncertainty, they shouldn't be implemented.

I won't appeal any rejection -- I don't care enough and I doubt the appeal
would be accepted.  If anyone in charge of HTML5 is going to agree with me, it
will be Hixie, not the co-chairs.

> Definitely proper in HTML5
>  http://www.w3.org/TR/html-markup/address.html

Nope, definitely improper, see above.  It represents contact info for the
 or  it's in, not arbitrary contact info.

> Ick.  I wonder it we could actually expect editors to not put quotation marks
> in manually, or have MW work around it if they do?  Sounds problematic (and
> again a good reason to fork that one into its own bug number).

The idea is that they'll be auto-added in CSS.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 4521] Colon (:) & semicolon (;) shouldn't output as HTML definition list when used for indentation, boldfacing

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=4521

--- Comment #30 from Aryeh Gregor  2010-07-26 
13:13:25 UTC ---
I'd prefer (2).  There are plenty of times I've used this for an actual
definition list, and almost all of the abuses I've seen are cases where ";"
isn't used at all, which is very easy to detect automatically.  We should just
treat ":" without accompanying ";" as  or something, that's
enough to fix the large majority of the cases.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24546] New: Problems with transclusion of onlyinclude markup inside nowiki markup

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24546

   Summary: Problems with transclusion of onlyinclude markup
inside nowiki markup
   Product: MediaWiki
   Version: unspecified
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Templates
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: csolive...@gmail.com


Transclude, por instance,

Text 

where the code is outside a single markup  You
get Text in the target page, when you should get nothing.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24545] ImageMagick generated Thumbnails get messed up (wrong colors) in some cases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24545

--- Comment #2 from Daniel Hiepler  
2010-07-26 11:21:16 UTC ---
This is the original file, the thumbnails were generated from:
http://localhostr.com/files/431def/testcase.jpg

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24545] ImageMagick generated Thumbnails get messed up (wrong colors) in some cases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24545

--- Comment #1 from Daniel Hiepler  
2010-07-26 11:05:41 UTC ---
Created an attachment (id=7593)
 --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7593)
Generated with: "convert -background white -size 120 testcase.jpg -thumbnail
'120x' -sharpen '0x0.4' thumb_right.jpg"

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24545] New: ImageMagick generated Thumbnails get messed up (wrong colors) in some cases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24545

   Summary: ImageMagick generated Thumbnails get messed up (wrong
colors) in some cases
   Product: MediaWiki
   Version: 1.15.1
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: minor
  Priority: Normal
 Component: Images and files
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: dude-mw...@boogiepalace.hopto.org
CC: gpaum...@wikimedia.org, bryan.tongm...@gmail.com,
innocentkil...@gmail.com


Created an attachment (id=7592)
 --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7592)
Generated with: "convert -background white -size 120 testcase.jpg -thumbnail
'120x' -depth 8 -sharpen '0x0.4' thumb_wrong.jpg

I've found that ImageMagick/convert generates messed-up thumbnails from some
kinds of images (mainly truecolor, high-resolution but other kinds may be
affected as well).
The thumbnails show wrong color portions that might result from wrong (or no)
dithering. I tracked down the problem to the "-depth 8" parameter to convert in
"includes/media/Bitmap.php", without it, everything looks just fine.

A quick possible solution would be, to make this parameter optional. Maybe a
dedicated analysis of this bug could result in checking the uploaded
image-properties and selectively applying the "-depth 8" option to images where
it doesn't harm thumbnail generation.

Hope that helps.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20526] Resulting book from Wikisource still has interwiki links

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=20526

--- Comment #5 from Volker Haas  2010-07-26 
10:25:06 UTC ---
The problem seems to be that the API on wikisource returns an empty
interwikimap. Therefore interwiki links can not be detected.

See the difference:

* interwikimap on en.wikipedia
http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=interwikimap

* no interwikimap on vi.wikisource:
http://vi.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=interwikimap

==> The solution is probably to fix the configuration of the mediawiki. If a
correct interwikimap is returned by the API the interwiki links can be handled
correctly in the PDF.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 24544] New: Completely inaccessible watchlist tab

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=24544

   Summary: Completely inaccessible watchlist tab
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Keywords: accessibility
  Severity: normal
  Priority: Normal
 Component: Vector Skin
AssignedTo: tpars...@wikimedia.org
ReportedBy: dann...@email.cz


1) Inaccessible for visually impaired: There's no link text to be read. (The
inner span has display: none;.)

2) Inaccessible even for common users: If images are off, noone can spot
"(un)watch" tab. Again, there's no text to fallback.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l