Hello
Could we have a per language MediaWiki:Subtitle implemented? like MediaWiki:Subtitle-ar or MediaWiki:Subtitle-es ?
Right now, If you switch to another language, You will see a partially translated subtitle (the word 'From' in a given language + untransliterated wiki name)...Which is, IMO, suboptimal.
There is no subtitle in commons, I assume because of that issue?
BTW it makes sense in multilingual wikis only :).
--user:alnokta
On 07/10/2007, Mohamed Magdy mohamed.m.k@gmail.com wrote:
Hello
Could we have a per language MediaWiki:Subtitle implemented? like MediaWiki:Subtitle-ar or MediaWiki:Subtitle-es ?
Right now, If you switch to another language, You will see a partially translated subtitle (the word 'From' in a given language + untransliterated wiki name)...Which is, IMO, suboptimal.
There is no subtitle in commons, I assume because of that issue?
BTW it makes sense in multilingual wikis only :).
If the "From" is being translated, then surely that means there is already a per language Mediawiki:Subtitle, it's just the $1 is being replaced by the wrong version of the wiki name. Sounds like a bug to me - report it to bugzilla.mediawiki.org.
Thomas Dalton wrote:
On 07/10/2007, Mohamed Magdy mohamed.m.k@gmail.com wrote:
Hello
Could we have a per language MediaWiki:Subtitle implemented? like MediaWiki:Subtitle-ar or MediaWiki:Subtitle-es ?
Right now, If you switch to another language, You will see a partially translated subtitle (the word 'From' in a given language + untransliterated wiki name)...Which is, IMO, suboptimal.
There is no subtitle in commons, I assume because of that issue?
BTW it makes sense in multilingual wikis only :).
If the "From" is being translated, then surely that means there is already a per language Mediawiki:Subtitle, it's just the $1 is being replaced by the wrong version of the wiki name. Sounds like a bug to me - report it to bugzilla.mediawiki.org.
No. The transliterated versions of the wiki name isn't in a specific place to get it from. I'm talking specifically about Meta-Wiki (and may be commons?) ..and you cannot edit the mediawiki:subtitle because it will override the different language variants hence the need of -xx or /xx ..so that each language can add localized version..
--user:alnokta
No. The transliterated versions of the wiki name isn't in a specific place to get it from. I'm talking specifically about Meta-Wiki (and may be commons?) ..and you cannot edit the mediawiki:subtitle because it will override the different language variants hence the need of -xx or /xx ..so that each language can add localized version..
In which case, doesn't that apply to the entire interface, not just the subtitle?
After a little more research, I'm a little confused. There is no Mediawiki:Subtitle, do you mean Mediawiki:Sitesubtitle? If so, that doesn't include the site title. I think you're talking about Media:Tagline, which can be set to whatever you like, you just have a manually input the site title in the appropriate language (using /lang if required). You can change the site title in other places with Mediawiki:Sitetitle.
As far as I can tell from looking at the code, all Mediawiki namespace pages can use the /lang form, there is no need to implement it for specific pages.
On 07/10/2007, Thomas Dalton thomas.dalton@gmail.com wrote:
As far as I can tell from looking at the code, all Mediawiki namespace pages can use the /lang form, there is no need to implement it for specific pages.
Some, for example the sitenotice, don't due to "aggressive caching". I don't know how many messages are like this. http://bugzilla.wikimedia.org/show_bug.cgi?id=8280 http://www.mediawiki.org/wiki/Manual:%24wgForceUIMsgAsContentMsg
cheers, Brianna
Brianna Laugher wrote:
On 07/10/2007, Thomas Dalton wrote:
As far as I can tell from looking at the code, all Mediawiki namespace pages can use the /lang form, there is no need to implement it for specific pages.
Some, for example the sitenotice, don't due to "aggressive caching". I don't know how many messages are like this. http://bugzilla.wikimedia.org/show_bug.cgi?id=8280 http://www.mediawiki.org/wiki/Manual:%24wgForceUIMsgAsContentMsg
cheers, Brianna
Why is it so? Isn't enough with the message cache?
On 07/10/2007, Platonides Platonides@gmail.com wrote:
Why is it so? Isn't enough with the message cache?
The message cache stores the raw text of messages. The issue there is that some messages, e.g. those used for the sidebar, site notices, etc. are subject to further processing which can be potentially very expensive - full parses on the site notice, for example.
These particular elements are cached themselves, but having multiple message sources processed and cached with the same key causes coherency issues.
A better solution would be to stop abusing messages for certain elements, e.g. for blacklists, whitelists, the sidebar, etc.
Rob Church
On 08/10/2007, Rob Church robchur@gmail.com wrote:
A better solution would be to stop abusing messages for certain elements, e.g. for blacklists, whitelists, the sidebar, etc.
Can you explain what this means? Do you mean the wiki users should stop abusing the messages somehow? What blacklists and whitelists?
thanks, Brianna
On 10/8/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 08/10/2007, Rob Church robchur@gmail.com wrote:
A better solution would be to stop abusing messages for certain elements, e.g. for blacklists, whitelists, the sidebar, etc.
Can you explain what this means? Do you mean the wiki users should stop abusing the messages somehow? What blacklists and whitelists?
What Rob is referring to here is the tendency of some developers (I've been an offender before) to use interface messages to let people configure things. For instance, my use of MediaWiki:autoblock-exempt, the use of MediaWiki:Spam blacklist, et cetera, et cetera.
As I was discussing last night with another developer, these are almost always better implemented, at least from an interface perspective, as extra special pages and database tables. Unfortunately, that's extra effort that a lot of developers aren't prepared to put in - as it will often involve schema changes, and certainly involves writing extra code.
As to what this has to do with MediaWiki:sitesubtitle, I have no idea - as that's certainly a localisable interface message, rather than configuration data related to MediaWiki.
On 10/7/07, Andrew Garrett andrew@epstone.net wrote:
As I was discussing last night with another developer, these are almost always better implemented, at least from an interface perspective, as extra special pages and database tables.
But adding extra special pages fragments the interface for configuration more. What would be best is making a Special:Config or Special:Controlpanel, with subpages, to allow any sort of configuration we might want to expose to users. The unified interface presented by most bulletin boards is something we should look to emulate, including a toolbox or other button to access the config page for those with the right to it. Ideally, I would see things like Special:Blockip and Special:Userrights being merged into this.
As for database tables, most configuration settings tend to be booleans or relatively short strings. Those probably belong in a single config table. Some configuration options are much more complicated and possible deserve their own table, but things like the sidebar should be stored in a single field. Are there any examples you were thinking of of things currently stored in messages that really deserve their own database tables?
On 10/9/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 10/7/07, Andrew Garrett andrew@epstone.net wrote:
As I was discussing last night with another developer, these are almost always better implemented, at least from an interface perspective, as extra special pages and database tables.
But adding extra special pages fragments the interface for configuration more. What would be best is making a Special:Config or Special:Controlpanel, with subpages, to allow any sort of configuration we might want to expose to users. The unified interface presented by most bulletin boards is something we should look to emulate, including a toolbox or other button to access the config page for those with the right to it. Ideally, I would see things like Special:Blockip and Special:Userrights being merged into this.
Yes, this would take away the "hacky" feel of the MediaWiki configuration inferface at the moment. As much as we try to improve each individual special page, the way it's presented to the user still feels ugly, hacky, however functional it may seem.
As for database tables, most configuration settings tend to be booleans or relatively short strings. Those probably belong in a single config table.
Yes, this is how I've implemented this at devanywhere - I have a "site_metadata" table, which has a varchar key and a BLOB value, and it's handy for all the stuff that, on MediaWiki, we put in LocalSettings.php, for instance enabling certain features, setting the site name, and all that kind of stuff.
Some configuration options are much more complicated and possible deserve their own table, but things like the sidebar should be stored in a single field. Are there any examples you were thinking of of things currently stored in messages that really deserve their own database tables?
Certainly. The autoblock-whitelist, the spam blacklist, the spam blacklist, the bad image list, the username blacklist, the list of disambiguation templates, perhaps the licenses list.
On 10/8/07, Andrew Garrett andrew@epstone.net wrote:
Certainly. The autoblock-whitelist, the spam blacklist, the spam blacklist, the bad image list, the username blacklist, the list of disambiguation templates, perhaps the licenses list.
The spam blacklist? That's a series of regexes, isn't it? What are you going to do, SELECT 1 FROM spamblacklist WHERE $url REGEXP sb_regex LIMIT 1? Somehow I suspect that would be considerably less efficient than the current method, horrible though *that* may be.
Other than that, I must admit, those are pretty reasonable candidates for inclusion in the database. It's a bit worrying to have so many tables used for so little, but it seems like the correct way to go.
"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20710081646l3ffda546j6ff82fb1944b2c09@mail.gmail.com...
On 10/8/07, Andrew Garrett
andrew@epstone.net wrote:
Certainly. The autoblock-whitelist, the spam blacklist, the spam blacklist, the bad image list, the username blacklist, the list of disambiguation templates, perhaps the licenses list.
The spam blacklist? That's a series of regexes, isn't it? What are you going to do, SELECT 1 FROM spamblacklist WHERE $url REGEXP sb_regex LIMIT 1? Somehow I suspect that would be considerably less efficient than the current method, horrible though *that* may be.
Other than that, I must admit, those are pretty reasonable candidates for inclusion in the database. It's a bit worrying to have so many tables used for so little, but it seems like the correct way to go.
Why is it worrying? Is it more worrying that site_stats?
- Mark Clements (HappyDog)
On 10/8/07, Mark Clements gmane@kennel17.co.uk wrote:
"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20710081646l3ffda546j6ff82fb1944b2c09@mail.gmail.com...
Other than that, I must admit, those are pretty reasonable candidates for inclusion in the database. It's a bit worrying to have so many tables used for so little, but it seems like the correct way to go.
Why is it worrying? Is it more worrying that site_stats?
Not really, which is why I think it's the correct way to go. I'm just not terribly happy about having a miles-long SHOW TABLES;, I suppose, from a sysadmin perspective.
So actually, why is MediaWiki:Sitenotice "aggressively cached"? Or at least why doesn't MediaWiki:Sitenotice/xx work. Given that it's not used in this configuration way.
cheers, Brianna
Brianna Laugher wrote:
So actually, why is MediaWiki:Sitenotice "aggressively cached"? Or at least why doesn't MediaWiki:Sitenotice/xx work. Given that it's not used in this configuration way.
The sitenotice is wiki-rendered and the rendered result is cached separately. Since it's shown on every page, we want to skip the wiki rendering overhead to minimize the performance impact.
Since it's assumed to be site-specific, and sites are (usually) assumed to be language-specific, only one point is used for the caching, so it wouldn't work properly with multiple languages.
On a site you run yourself, you could hack about a little to disable that caching without probably much performance problems, and putting 'sitenotice' in the content-messages-as-ui-language list would probably do it.
Note that I'm experimenting with a new site notice infrastructure for the upcoming Wikimedia fundraiser which will cache the notice separately (via the HTTP proxy caches), and will handle multiple languages more explicitly. (See extensions/CentralNotice for the last PoC code I posted.)
I'm not sure how suitable it will be for use on other sites, though.
-- brion vibber (brion @ wikimedia.org)
Thomas Dalton wrote:
After a little more research, I'm a little confused. There is no Mediawiki:Subtitle, do you mean Mediawiki:Sitesubtitle? If so, that doesn't include the site title. I think you're talking about Media:Tagline,
Ah yes..fasting == less sugar == mind wandering ;)
which can be set to whatever you like, you just have a manually input the site title in the appropriate language (using /lang if required). You can change the site title in other places with Mediawiki:Sitetitle.
As far as I can tell from looking at the code, all Mediawiki namespace pages can use the /lang form, there is no need to implement it for specific pages.
Thanks! that is what I was asking and it is already there :) .. *Sorry* for the trouble ;)
--alnokta
wikitech-l@lists.wikimedia.org