headers
bugzilla-daemon | 20 May 2013 07:55
Picon

[Bug 48630] New: Data model needs characters, not code points

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

       Web browser: ---
            Bug ID: 48630
           Summary: Data model needs characters, not code points
           Product: VisualEditor
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Unprioritized
         Component: Data Model
          Assignee: esanders <at> wikimedia.org
          Reporter: david <at> sheetmusic.org.uk
                CC: jforrester <at> wikimedia.org, roan.kattouw <at> gmail.com,
                    tparscal <at> wikimedia.org
    Classification: Unclassified
   Mobile Platform: ---

At present, the VisualEditor treats UTF-16 code points as if they were
synonymous with abstract characters. Here are two cases where this causes bugs:

1) UTF-16 uses a surrogate pair to represent each Unicode character above
U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character
represented in Javascript as "\uD860\uDEE2". In a plain textarea, this behaves
like a single character from the point of view of the user. However in the
VisualEditor, cursoring and backspacing requires two presses; and after
cursoring once, any text typed will go in the middle of the surrogate pair,
creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8,
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla-daemon | 20 May 2013 07:55
Picon

[Bug 48629] New: removal of non-print character from Special:RecentChanges (user creation log)=?UTF-8?Q?=20between=20account=20names=20=E2=80=94=20when=20grouped?=

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

       Web browser: ---
            Bug ID: 48629
           Summary: removal of non-print character from
                    Special:RecentChanges (user creation log) between
                    account names — when grouped
           Product: MediaWiki
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: Recent changes
          Assignee: wikibugs-l <at> lists.wikimedia.org
          Reporter: billinghurst <at> gmail.com
    Classification: Unclassified
   Mobile Platform: ---

In Special:RecentChanges the line that displays the grouped user creation log
has accounts like follows with the grouped listing followed by the individuals
when the twisty is opened.

In the grouped line, at the end of the account username and prior to each
semi-colon there is a non-print character.  This character can be problematic
when undertaking a copy and paste.

(what follows is spambot accounts)
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 20 May 2013 06:59
Picon

[Bug 48628] New: Provide replication lag as a database function

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

       Web browser: ---
            Bug ID: 48628
           Summary: Provide replication lag as a database function
           Product: Wikimedia Labs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: tools
          Assignee: marc <at> uberbox.org
          Reporter: tim <at> tim-landscheidt.de
    Classification: Unclassified
   Mobile Platform: ---

There should be a function tools.replag() (can MySQL tie functions to a
database?) that provides the replication lag in seconds, and maybe another
function tools.lastrepupdate() that returns "NOW() - replag()".

It should be a "SECURITY DEFINER" function that queries "SHOW SLAVE
STATUS.Seconds_Behind_Master" (cf.
mediawiki/core:includes/db/DatabaseMysql.php).  This is preferable to the
Toolserver method of querying recentchanges as it gives a more accurate picture
of the actual replication lag. 
http://stackoverflow.com/questions/1570776/how-to-access-seconds-behind-master-from-sql
has some information that this query should be possible, though not trivial.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 20 May 2013 06:45
Picon

[Bug 48627] New: Provide shortcut "sql" or similar to connect to the correct database

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

       Web browser: ---
            Bug ID: 48627
           Summary: Provide shortcut "sql" or similar to connect to the
                    correct database
           Product: Wikimedia Labs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: tools
          Assignee: marc <at> uberbox.org
          Reporter: tim <at> tim-landscheidt.de
    Classification: Unclassified
   Mobile Platform: ---

Toolserver has a utility "sql" that hides the lookup of the correct database
server to connect to and gives users the ease to just say "sql nlwiki" or "sql
nlwiki 'SELECT * FROM page LIMIT 1;'".

Source should be at
https://svn.toolserver.org/svnroot/puppet/trunk/puppet/modules/scripts/files/sql
(down at the moment), cf. https://jira.toolserver.org/browse/TS-1651 for a
small bugfix.

--

-- 
You are receiving this mail because:
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 20 May 2013 06:35
Picon

[Bug 48626] New: Provide wiki metadata in the databases similar to toolserver.wiki

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

       Web browser: ---
            Bug ID: 48626
           Summary: Provide wiki metadata in the databases similar to
                    toolserver.wiki
           Product: Wikimedia Labs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: tools
          Assignee: marc <at> uberbox.org
          Reporter: tim <at> tim-landscheidt.de
    Classification: Unclassified
   Mobile Platform: ---

Toolserver has the local table toolserver.wiki on all databases that provides
metadata about the wikis including the server the wiki's database is kept on:

| mysql> SELECT * FROM toolserver.wiki LIMIT 5;
|
+----------------+------+------------+------------------+------+---------+-----------+--------------+--------------+---------------+--------+-------------+
| | dbname         | lang | family     | domain           | size | is_meta |
is_closed | is_multilang | is_sensitive | root_category | server | script_path
|
|
+----------------+------+------------+------------------+------+---------+-----------+--------------+--------------+---------------+--------+-------------+
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 20 May 2013 06:27
Picon

[Bug 48625] New: Provide namespace IDs and names in the databases similar to toolserver.namespace

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

       Web browser: ---
            Bug ID: 48625
           Summary: Provide namespace IDs and names in the databases
                    similar to toolserver.namespace
           Product: Wikimedia Labs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: trivial
          Priority: Unprioritized
         Component: tools
          Assignee: marc <at> uberbox.org
          Reporter: tim <at> tim-landscheidt.de
    Classification: Unclassified
   Mobile Platform: ---

Toolserver has the local table toolserver.namespace on all databases that
provides the IDs and names of all namespaces in a wiki:

| mysql> SELECT * FROM toolserver.namespace LIMIT 5;
| +----------+------------------+-------+-------------------------------------+
| | dbname   | domain           | ns_id | ns_name                             |
| +----------+------------------+-------+-------------------------------------+
| | abwiki_p | ab.wikipedia.org |    10 | Ашаблон                      |
| | abwiki_p | ab.wikipedia.org |     7 | Обсуждение файла     |
| | abwiki_p | ab.wikipedia.org |    11 | Обсуждение шаблона |
| | abwiki_p | ab.wikipedia.org |     8 | Амедиавики                |
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 20 May 2013 04:45
Picon

[Bug 798] Many character sets don't work in texvc

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

--- Comment #32 from Tim Landscheidt <tim <at> tim-landscheidt.de> ---
(In reply to comment #31)
> OK, so the difference between mbox and text seems to have disappeared at some
> point. The problem is now that not all character sets are supported.

> Unfortunately LateX doesn't support full unicode. Perhaps we should consider
> switching to XeTeX ?
> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=xetex
> http://en.wikipedia.org/wiki/XeTeX

It doesn't make sense to address this before resolving bug 34038 first.  It'd
probably be relatively easy to convert some Unicode input into something LaTeX
renders correctly, but then the initial incentive to use LaTeX as a format --
i. e. freely transfer text between wiki and LaTeX documents -- gets lost
completely.

I think the question should be directed the other way, lifted of any past
efforts: If a British/French/Bengali/Arabian wiki author wants to enter a
formula, what formats a) ease that work and b) are well established?  If most
authors will use a formula editor, the format choice can be guided mainly by
technical considerations.  If we expect most formulas to be entered manually by
people unfamiliar with TeX, the latter would be an odd choice as its behaviour
can be as surprising as MediaWiki's wiki parser and a format that would
/define/ a formula instead of being /commands/ to a typesetter would clearly be
preferable.

Even a change to use XeTeX should IMHO be reflected by the use of a new tag
("<math-xe>" or something similar), so that we don't cause more headaches than
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 20 May 2013 02:52
Picon

[Bug 48624] New: MediaWiki:Mwe-upwiz-license-custom-url provides a broken link

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

       Web browser: ---
            Bug ID: 48624
           Summary: MediaWiki:Mwe-upwiz-license-custom-url provides a
                    broken link
           Product: MediaWiki extensions
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: UploadWizard
          Assignee: wikibugs-l <at> lists.wikimedia.org
          Reporter: tomasz <at> twkozlowski.net
                CC: mtraceur <at> member.fsf.org, nischayn22 <at> gmail.com
    Classification: Unclassified
   Mobile Platform: ---

The [[MediaWiki:Mwe-upwiz-license-custom-url]] message — which is visible when
you upload a file with UW, go to the third step ("Release rights"), select
"This file is not my work", and then "Another reason not mentioned above" —
provides a broken link.

Instead of the message that is available at [1], the link that appears under
"copyright tag" gets a suffix "deed.lang", for example deed.en-gb — which in
this case leads to a non-existing page [2].

This is true for all interface languages that I checked (en, en-gb, and pl),
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla-daemon | 20 May 2013 02:45
Picon

[Bug 48623] New: Add user-agent variable for abuse filtering

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

       Web browser: ---
            Bug ID: 48623
           Summary: Add user-agent variable for abuse filtering
           Product: MediaWiki extensions
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: AbuseFilter
          Assignee: wikibugs-l <at> lists.wikimedia.org
          Reporter: billinghurst <at> gmail.com
                CC: agarrett <at> wikimedia.org, nischayn22 <at> gmail.com
    Classification: Unclassified
   Mobile Platform: ---

One recent example of spam edits has identified the user agent

  http://code.google.com/appengine; appid: s~bagswish

in recent usage. It is reasonable to expect that such and similar types of
abuse is going to continue to occur, and where it is occurring then it would
seem an easy and convenient means to block such user-agent components after
they have been identified by checkuser process

Would be useful to have  variable_name  user-agent, and variable values, with
regex that could be applied.
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 20 May 2013 01:53
Picon

[Bug 48622] New: JavaScript UI fails if entity page data model contains unexpected DataValues JSON

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

       Web browser: ---
            Bug ID: 48622
           Summary: JavaScript UI fails if entity page data model contains
                    unexpected DataValues JSON
           Product: MediaWiki extensions
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: WikidataRepo
          Assignee: wikidata-bugs <at> lists.wikimedia.org
          Reporter: daniel.werner <at> wikimedia.de
                CC: wikidata-bugs <at> lists.wikimedia.org
    Classification: Unclassified
   Mobile Platform: ---

If on an entity page the JSON representing the entity contains some unexpected
values in a Snak's DataValues JSON, the UI will fail to initialize.

This can be the case for various reasons. Currently it is the case for Time
values where the JSON contains an unknown calendar model. Since the backend
doesn't check for known calendar models, it is easy to inject such data via the
API.
The Frontend should not fail but rather display a warning that a value was not
successfully unserialized.
(Continue reading)

Permalink | Reply | 4 comments |
headers
bugzilla-daemon | 19 May 2013 23:55
Picon

[Bug 48621] New: changing a Snak's time value from a valid to an invalid one will not disable Claim's "save" button

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

       Web browser: ---
            Bug ID: 48621
           Summary: changing a Snak's time value from a valid to an
                    invalid one will not disable Claim's "save" button
           Product: MediaWiki extensions
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: WikidataRepo
          Assignee: wikidata-bugs <at> lists.wikimedia.org
          Reporter: daniel.werner <at> wikimedia.de
                CC: wikidata-bugs <at> lists.wikimedia.org
    Classification: Unclassified
   Mobile Platform: ---

Changing a "time" value from a valid to an invalid value will not trigger the
"save" button to be disabled. When saving, the previously valid value will be
saved.

The reason for this is that the jQuery.valueview.experts.TimeInput instance
won't notify about the change from valid to invalid. Probably because the
jQuery.time.timeinput's "update" event only triggers when the value changes to
another valid value.

Note: this should be a bug in the "ValueView" extension which is not yet
(Continue reading)

Permalink | Reply | 3 comments |

Gmane