huji(a)svn.wikimedia.org wrote:
> Revision: 37785
> Author: huji
> Date: 2008-07-17 12:02:34 +0000 (Thu, 17 Jul 2008)
>
> Log Message:
> -----------
> Putting 'whatlinkshere-barrow' in optinal rather than ignored list; such directional items may need to be translated in RTL languages.
>
It should not be translated, as its direction changes when the display is RTL,
as all brackets do (but not actual arrows). Compare (UTF-8 encoded):
A > A (A) A
א > א (א) א
These are the same characters respectively (except for A and א), in different
directions.
On Thu, Jul 17, 2008 at 7:47 PM, <brion(a)svn.wikimedia.org> wrote:
> Revision: 37776
> Author: brion
> Date: 2008-07-17 09:47:20 +0000 (Thu, 17 Jul 2008)
>
> Log Message:
> -----------
> Revert r37772 for now "(bug 14842) Don't show unified logout images for non-unified accounts."
> Seems to have some unrelated changes to logging with no explanation -- what's going on here?
>
Yes, it must have failed committing a few days ago or something
I tried to explain by amending the log message, but you apparently
don't have that enabled.
The reason for the logging changes was that these entries were
appearing in the log wrong, because "globalauth/lockandhide" is too
long for the logging table (it truncates at lockandhid).
See http://meta.wikimedia.org/wiki/Special:Log/globalauth :
# 04:18, 15 July 2008 Drini (Talk | contribs | block) lockandhid
--
Andrew Garrett
In my wiki installation (which is running on Windows/IIS6/MSSQL) I have
modified the finalCleanup method in Wiki.php to do this:
function finalCleanup ( &$deferredUpdates, &$output ) {
wfProfileIn( __METHOD__ );
$this->doUpdates( $deferredUpdates );
$output->output();
$this->doJobs();
# Now commit any transactions, so that unreported errors after output()
don't roll back the whole thing
$factory = wfGetLBFactory();
$factory->shutdown();
wfProfileOut( __METHOD__ );
}
rather than this:
function finalCleanup ( &$deferredUpdates, &$output ) {
wfProfileIn( __METHOD__ );
$this->doUpdates( $deferredUpdates );
$this->doJobs();
# Now commit any transactions, so that unreported errors after output()
don't roll back the whole thing
$factory = wfGetLBFactory();
$factory->shutdown();
$output->output();
wfProfileOut( __METHOD__ );
}
Basically, I am flushing the output before running anything from my job
queue. I frequently have a non-empty job queue, and have found that the
modification lets the browser see the page much faster than when I run some
jobs first. Is there any reason not to suggest this as a change to the code
base? It made quite a dramatic improvement on my wiki when I made the
change, although perhaps things are different with Linux/Apache/MySQL?
Hi, there,
May i ask the basic technical question? I want to use MySQL to deal with
almost 100 GB dumps from wikipedia dumps, but one of technical supportors
told me i can't use Windows system in my computer because there is 4 GB
limit for 32 bit CPU. Is that true?
If i still want to finish my study, what computer i have to get? Is there
some special requirement?
thanks again！
zeyi
On Wed, Jul 16, 2008 at 6:15 AM, <brion(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Revert r37741 for now "Changed getInternalLinkAttributesInternal parameters: now accepts Title object if available, passes to hook. Also reordered some code in makeKnownLinkObj so that said hook can mangle the Title object. Reordering should have no other side-effects."
> This seems a bit icky and inconsistent. If it's necessary to pass titles around here, it should be done consistently, with appropriate fixups and refactoring to the old spaghetti code.
In particular, if you want titles to be accepted, you shouldn't add
another parameter. This is PHP, not C -- parameters are untyped.
Just do something like this at the beginning of
getLinkAttributesInternal:
if( $title instanceof Title ) {
$nt = $title;
$title = $title->getPrefixedText();
} else {
$nt = Title::newFromText( $title );
}
But I don't see why the hook could possibly want to be passed both a
Title object *and* title text, since either one can be trivially
constructed from the other. Pass one or the other, not both. Passing
a Title object would be most consistent with the majority of hooks, I
think -- I'd just do
wfRunHooks( ... array( ... Title::newFromText( $title ), ... ) );
I don't think there's any point in worrying about whether a Title is
already available. This is not going to be a performance bottleneck.
Lately I've seen a lot of diffs to .i18n files that look like this:
- (50 lines with one number of spaces in them)
+ (51 lines with a different number of spaces in them, and one of the
lines is new)
I think it would greatly simplify change tracking if we used more
consistent spacing in the localization files, eg changing this:
+ 'Search' => array( 'Sichen' ),
+ 'Resetpass' => array( 'Passwuert zrécksetzen' ),
to this:
+ 'Search' => array( 'Sichen' ),
+ 'Resetpass' => array( 'Passwuert zrécksetzen' ),
While it's cute, and sometimes helpful, to align columns in files that
are manually maintained, this:
1) Has no benefit to localization done via BetaWiki
2) Obscures the actual changes made in a commit when the number of
columns gets bumped, making overall code maintenance more difficult.
-- brion
On Tue, Jul 15, 2008 at 5:13 PM, <brion(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Revert r37663 for now:
> "* (bug 13815) In the comment for page moves, use the colon-separator message instead of a hardcoded colon."
> "* So that this works properly, don't escape HTML entities in edit summaries. I don't see any good reason for them to be escaped there. Of course, this may result in old edit summaries displaying slightly differently if for some reason they included an entity, but in that case there's at least a 50% chance that they intended it to not be escaped in the first place."
>
> This breaks the ability to easily discuss entities in summaries such as "add ".
. . . then does the fact that we interpret entities in article text
break the ability to easily discuss them there? As I said, as likely
as not, people who are talking about entities were already entering
&entityname; anyway.
I did a bit of quick research, in the form of SELECT * FROM
recentchanges WHERE rc_comment LIKE '%&%' LIMIT 100 on enwiki.
The results can be classified as follows:
* Three were, in fact, discussing entities in their summary, as you
say, and were correctly not escaped.[1-3]
* The other 97 were *incorrectly* escaped. These included a number of
cases where the failure to escape would have caused outright errors,
not just ugly appearance.
** In a bunch of cases (like [4]), the & occurred inside an
external URL, and the URL would fail if copied, since it was
double-escaped.
** In a few other cases (all deleted revisions adding AFD notices, so
I can't link to them) the & was in a wikilink. Although I can't
see the results, my testing[5] indicates that in edit summaries this
causes the link to fail, again incorrect.
** And the remaining few dozen were things like /* Wrexham &
Shropshire Route */ (e.g., [6]), which I'm not sure are affected by my
change, but if they are it's positively: they look ugly, and they
don't work as links either.
So in short, 97% of the time it's more correct -- or if you disqualify
the /* section name */ ones, if this doesn't affect them, it's still
more correct at least 80% or so of the time. *And* on top of this it
allows localization of the colon. Can I recommit this?
[1] http://en.wikipedia.org/w/index.php?title=User_talk:Geestring&diff=22322686…
[2] http://en.wikipedia.org/w/index.php?title=Spam_(electronic)&diff=220390835&…
[3] http://en.wikipedia.org/w/index.php?title=Template_talk:Frac&diff=219821851…
[4] http://en.wikipedia.org/w/index.php?title=User_talk:Atomadams13&action=hist…
[5] http://en.wikipedia.org/w/index.php?title=User:Simetrical/Sandbox&diff=2258…
[6] http://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/W…
> Lately I've seen a lot of diffs to .i18n files that look like this:
>
> - (50 lines with one number of spaces in them)
> + (51 lines with a different number of spaces in them, and one of the
> lines is new)
>
> I think it would greatly simplify change tracking if we used more
> consistent spacing in the localization files, eg changing this:
>
> + 'Search' => array( 'Sichen' ),
> + 'Resetpass' => array( 'Passwuert zrécksetzen' ),
> to this:
>
> + 'Search' => array( 'Sichen' ),
> + 'Resetpass' => array( 'Passwuert zrécksetzen' ),
>
> While it's cute, and sometimes helpful, to align columns in files that
> are manually maintained, this:
>
> 1) Has no benefit to localization done via BetaWiki
>
> 2) Obscures the actual changes made in a commit when the number of
> columns gets bumped, making overall code maintenance more difficult.
>
> -- brion
>
Can be done. Will discuss with Nikerabbit tomorrow. This means that 'human
readable i18n' files will be a thing of the past. Nothing new to Betawiki
folk, though :).
Would you suggest a rebuild of all localisation files in one go to get rid
of your observed obscurity, or would you like it to trickle through over
time?
I suggest we make the proposed changes fter the 1.13 release (after
release, not branching, so that we can do a backport to 1.13 just before
release with the current code base).
Cheers! Siebrand
Hi All,
I am having troube to checkin- checkout my code.
On using the following command. It asks me for password.
I have set up a public-private key pair. Is this password the key password?.
As while setting the SVN account I did not mention about the password.
svn co svn+ssh://pmwx@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
Appreciate your help.
Thanks
--Viral
On Tue, Jul 15, 2008 at 12:03 PM, <dantman(a)svn.wikimedia.org> wrote:
> ** SkinSetupSiteCss to allow extensions to modify and add new stylesheets to load into the page. This one allows for fine positioning and can be very useful for things like an extension providing global css for a wiki farm.
> ** SkinGlobalVariables to allow extensions to add new global variables to export to the JS variables in the page.
Can't this all be done using the $wgOut functions such as addScript,
addStyle, and addScriptFile - if not, what is the difference?
MinuteElectron.