Last modified: 2007-12-22 20:10:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12216 - Custom Names.php can't be used since 1.10.0
Custom Names.php can't be used since 1.10.0
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.12.x
All All
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
http://svn.wikimedia.org/viewvc/media...
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-05 21:56 UTC by Nicolas Brouard
Modified: 2007-12-22 20:10 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Use $IP instead of dirname(__FILE__) for compatibility to former custom Names.php (513 bytes, patch)
2007-12-05 21:58 UTC, Nicolas Brouard
Details

Description Nicolas Brouard 2007-12-05 21:56:22 UTC
I recently upgraded a few mediawiki servers and discovered that my customized (and different) files Names.php were no more taken into account. 

It means that I have a phase3 directory with a standard mediawiki distribution which is symbolically linked to a family of servers. One family is similar to a wikipedia family with versions in 15 languages. But I want to give access to old editions of this multilingual dictionary (published respectively 40 years for first editions and 20 years for second editions). Therefore, I want to use Names.php to assign 'en-i' => 'English first edition', 'de-i' => 'Deutsch erste Augabe', 'en-ii' => 'English second edition' etc. 

Each file 'Names.php' is different in order to facilitate the jump between various editions of the same language.

Thus I customize my local files (en-ii/w/languages/Names.php, de-i/w/languages/Names.php etc.) and there is no symlink to the useless phase3/languages/Names.php .

But since version 1.10.0, you hardcoded the path in order to speed up the search by setting:
 
  require_once( dirname(__FILE__) . '/Names.php' ) ;
instead of
  require_once( 'Names.php' );

And you (nickj) justified this by writing:
-----------------------
Revision 19835 - (view) (download) (as text) (annotate) - [select for diffs]
Modified Fri Feb 9 05:36:56 2007 UTC (9 months, 3 weeks ago) by nickj
File length: 49851 byte(s)

Prevent some unnecessary lstat system calls, generated by include or require directives.

This can be done either by:
* Using explicit full paths, using the $IP global for the installation directory full path, and then working down the tree from there.
* Using explicit full paths, using the "dirname(__FILE__)" directive to get a full directory path for the includer file. 
--------------------------

May I suggest you to use the first alternative, using $IP, instead of "dirname(__FILE__)" and to replace  the line 14 of file Names.php (27992):
  require_once( dirname(__FILE__) . '/Names.php' ) ;
by two lines:
  global $IP;
  require_once( $IP . '/languages/Names.php' ) ;

In fact, it will make the code more coherent with what is done below on line 731, where you can read:
    include_once("$IP/languages/classes/$class.deps.php");
which is a similar syntax.

Many thanks, in advance.
Nicolas
Comment 1 Nicolas Brouard 2007-12-05 21:58:49 UTC
Created attachment 4409 [details]
Use $IP instead of dirname(__FILE__)  for compatibility to former custom Names.php


I recently upgraded a few mediawiki servers and discovered that my customized (and different) files Names.php were no more taken into account. 

It means that I have a phase3 directory with a standard mediawiki distribution which is symbolically linked to a family of servers. One family is similar to a wikipedia family with versions in 15 languages. But I want to give access to old editions of this multilingual dictionary (published respectively 40 years for first editions and 20 years for second editions). Therefore, I want to use Names.php to assign 'en-i' => 'English first edition', 'de-i' => 'Deutsch erste Augabe', 'en-ii' => 'English second edition' etc. 

Each file 'Names.php' is different in order to facilitate the jump between various editions of the same language.

Thus I customize my local files (en-ii/w/languages/Names.php, de-i/w/languages/Names.php etc.) and there is no symlink to the useless phase3/languages/Names.php .

But since version 1.10.0, you hardcoded the path in order to speed up the search by setting:
 
  require_once( dirname(__FILE__) . '/Names.php' ) ;
instead of
  require_once( 'Names.php' );

And you (nickj) justified this by writing:
-----------------------
Revision 19835 - (view) (download) (as text) (annotate) - [select for diffs]
Modified Fri Feb 9 05:36:56 2007 UTC (9 months, 3 weeks ago) by nickj
File length: 49851 byte(s)

Prevent some unnecessary lstat system calls, generated by include or require directives.

This can be done either by:
* Using explicit full paths, using the $IP global for the installation directory full path, and then working down the tree from there.
* Using explicit full paths, using the "dirname(__FILE__)" directive to get a full directory path for the includer file. 
--------------------------

May I suggest you to use the first alternative, using $IP, instead of "dirname(__FILE__)" and to replace  the line 14 of file Names.php (27992):
  require_once( dirname(__FILE__) . '/Names.php' ) ;
by two lines:
  global $IP;
  require_once( $IP . '/languages/Names.php' ) ;

In fact, it will make the code more coherent with what is done below on line 731, where you can read:
    include_once("$IP/languages/classes/$class.deps.php");
which is a similar syntax.

Many thanks, in advance.
Nicolas
Comment 2 Niklas Laxström 2007-12-22 20:10:31 UTC
$wgExtraLanguageNames was added in r28212, which should accomplish the same thing.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links