Victor Vasiliev wrote:

You need to gain a local consensus and then file a bug in bugzilla [1].

[1] https://bugzilla.wikimedia.org/

I understand. I'll try to make our local consensus. Thank you very much, Victor.

Huib Laurens wrote:

How do you want it changed?

I think that {{SITENAME}} is translated in almost projects. But in jawp it is not translated. It makes jawp a little strange.

For example, [[MediaWiki:Aboutsite]] have the default message "About {{SITENAME}}". But we have overwritten it by "ウィキペディアについて" （translated word from "about Wikipedia").

Jawp community needs to talk about this and it is better to select one word, the untranslated "Wikipedia" or the translated "ウィキペディア", I think.

Sorry for my poor English. Thank you.

---- [[w:ja:User:mizusumashi]]

2009/8/31 Domas Mituzas midom.lists@gmail.com:

Hello,

...

For example, [[MediaWiki:Aboutsite]] have the default message "About {{SITENAME}}". But we have overwritten it by "ウィキペディ アについて" （translated word from "about Wikipedia").

Performance-wise it is even better, if all main messages which have {{SITENAME}} get replacements with literals. Otherwise you're adding up 5ms of page load time to each page. :)

It would be good if that was documented ;-P

http://www.mediawiki.org/wiki/Manual:Interface/Aboutsite

I asked about this a while ago.

http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/00...

-- John Vandenberg

Hoi, Changing the messages in this way may be good from a performance perspective it really hurts the usability of our messages. Messages are localised at translatewiki.net and this is where we do require these messages. When messages are to have hardcoded strings as you propose you defeat the objectives of using a set of messages that are universally usable.

In my opinion your proposal has really nasty side effects so my question is how you want to ensure that we are not working cross purposes. Thanks, GerardM

2009/8/31 Domas Mituzas midom.lists@gmail.com

...

I asked about this a while ago.

http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/00...

...

:Aboutsite

asking on-wiki doesn't really makes much sense, as I don't read it ;-p

Anyway, we have to ensure, that most of wikis (at least top20 ones) have got ridden of curly braces and any other expensive parser stuff in these messages, as that costs them up to 10 milliseconds per pageview (if anyone writes a bot to do this automatically, I'd gladly run it with my global super duper privileges :)) :

aboutpage aboutsite accesskey-ca-delete accesskey-ca-edit accesskey-ca-history accesskey-ca-move accesskey-ca-nstab-main accesskey-ca-talk accesskey-ca-unprotect accesskey-ca-view accesskey-ca-watch accesskey-n-aboutsite accesskey-n-contact accesskey-n-contents accesskey-n-currentevents accesskey-n-featuredcontent accesskey-n-help accesskey-n-mainpage-description accesskey-n-portal accesskey-n-randompage accesskey-n-recentchanges accesskey-n-sitesupport accesskey-p-logo accesskey-pt-acaibeta accesskey-pt-betafeedback accesskey-pt-logout accesskey-pt-mycontris accesskey-pt-mytalk accesskey-pt-preferences accesskey-pt-userpage accesskey-pt-watchlist accesskey-search accesskey-search-fulltext accesskey-search-go accesskey-t-permalink accesskey-t-print accesskey-t-recentchangeslinked accesskey-t-specialpages accesskey-t-upload accesskey-t-whatlinkshere actions cite_article_link coll-add_page_tooltip coll-create_a_book coll-help_collections_tooltip coll-helppage coll-printable_version_pdf contact-url currentevents-url delete disclaimerpage disclaimers edit helppage history_short interaction jumpto jumptonavigation jumptosearch lastmodifiedat mainpage move mycontris mypreferences mytalk mywatchlist namespaces navigation nstab-main opensearch-desc optin-feedback optin-leave otherlanguages pagetitle pagetitle-view-mainpage permalink personaltools portal-url printableversion privacy privacypage randompage-url recentchanges-url recentchangeslinked-toolbox retrievedfrom search search-mwsuggest-disabled search-mwsuggest-enabled searcharticle searchbutton sidebar site-atom-feed site-rss-feed sitenotice sitesupport-url specialpages tagline talk toolbox tooltip-ca-delete tooltip-ca-edit tooltip-ca-history tooltip-ca-move tooltip-ca-nstab-main tooltip-ca-talk tooltip-ca-unprotect tooltip-ca-view tooltip-ca-watch tooltip-n-aboutsite tooltip-n-contact tooltip-n-contents tooltip-n-currentevents tooltip-n-featuredcontent tooltip-n-help tooltip-n-mainpage-description tooltip-n-portal tooltip-n-randompage tooltip-n-recentchanges tooltip-n-sitesupport tooltip-p-coll-create_a_book tooltip-p-interaction tooltip-p-logo tooltip-p-navigation tooltip-pt-acaibeta tooltip-pt-betafeedback tooltip-pt-logout tooltip-pt-mycontris tooltip-pt-mytalk tooltip-pt-preferences tooltip-pt-userpage tooltip-pt-watchlist tooltip-search tooltip-search-fulltext tooltip-search-go tooltip-t-permalink tooltip-t-print tooltip-t-recentchangeslinked tooltip-t-specialpages tooltip-t-upload tooltip-t-whatlinkshere unprotect unwatch unwatching upload userlogout vector-action-delete vector-action-move vector-action-unprotect vector-namespace-main vector-namespace-talk vector-view-edit vector-view-history vector-view-view views watch watching whatlinkshere wikimedia-copyright

Domas

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi!

Changing the messages in this way may be good from a performance perspective it really hurts the usability of our messages. Messages are localised at translatewiki.net and this is where we do require these messages. When messages are to have hardcoded strings as you propose you defeat the objectives of using a set of messages that are universally usable.

I'm suggesting doing that just on our wikis. Mediawiki users can have whatever expensive logic, I don't care that much :-)

In my opinion your proposal has really nasty side effects so my question is how you want to ensure that we are not working cross purposes.

Using {{ on common messages is no-go on major wikimedia wikis. Again, people can do whatever transformations they want at any level, except final mediawiki message logic that is on our site.

BR, Domas

On Mon, Aug 31, 2009 at 8:27 AM, Gerard Meijssengerard.meijssen@gmail.com wrote:

There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono.

These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is.

Slightly more burdensome localization makes the localizers' lives a bit more difficult. Running out of CPU means the site will crash. So, no, I don't think so. Of course, it would be nice if someone came up with a solution that everyone was happy with, but until then, performance *is* more important than localization convenience.

On Mon, Aug 31, 2009 at 10:17 AM, Gerard Meijssengerard.meijssen@gmail.com wrote:

Hoi, Thank you for the hyperbole.. Your representation insinuates that our systems will crash unless this change is implemented. Fact is that currently our messages are parsed. Thanks,     GerardM

2009/8/31 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com

...

...

On Mon, Aug 31, 2009 at 8:27 AM, Gerard Meijssengerard.meijssen@gmail.com wrote:

...

There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just

stating

...

that performance trumps our localisation is also very much a nono.

These are consequences and they have to be considered. Just breaking the

way

...

our localisation works in this way is at least equally unacceptable as

poor

...

performance is.

Slightly more burdensome localization makes the localizers' lives a bit more difficult.  Running out of CPU means the site will crash. So, no, I don't think so.  Of course, it would be nice if someone came up with a solution that everyone was happy with, but until then, performance *is* more important than localization convenience.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

In the WMF environment, I know a lot of instances of {{SITENAME}} have been changed to strings on a lot of the larger wikis. For the WMF, this is a good performance gain with little drawback to the users. Their sitename isn't changing anytime soon, so it doesn't really matter to use {{SITENAME}} or not.

For individual wikis elsewhere, {{SITENAME}} may be of greater benefit. This doesn't hold true for the WMF though, and that's what Domas is talking about.

-Chad

On 31/08/2009, at 9:27 AM, Gerard Meijssen wrote:

Hoi, There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono.

These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is.

You haven't explained exactly what impact this will have on localisation. Perhaps providing concrete disadvantages instead of vague topic areas will make your argument more convincing.

-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/

Hello,

While I appreciate Domas' search for more performance,

Please, I'm not looking for "more performance" here, we've been removing those tokens for few years already ;-)

There is also a constant flow of new localised messages and these can include the list of messages that has been shown earlier in this thread.

And? We will remove {{'s on live site. Messages will be localized.

What I am looking for is proper support.

Proper support for what?

The least is proper documentation and it can be expanded to a procedure that allows other wikis to benefit from the knowledge we have gained.

I have gained knowledge, that we cannot afford parsed messages within standard UI.

My overriding concern is that our language support is not sacrificed at the cost of a few cycles. Even when there are a lot of them.

FFS, WE WILL HAVE TRADEOFFS. If your concern is that we have to avoid tradeoffs and only your opinion matters, please, shut up, and unsubscribe. You failed to present what breaks if we reduce messages, and all you do is just blabber about some language support.

We do support languages, last I checked. What we don't support is flexible complex messages on our _live_site_. It is not just cost of cycles, it is ability to deliver pages to our users faster.

-- Domas

Domas Mituzas wrote:

Anyway, we have to ensure, that most of wikis (at least top20 ones) have got ridden of curly braces and any other expensive parser stuff in these messages, as that costs them up to 10 milliseconds per pageview (if anyone writes a bot to do this automatically, I'd gladly run it with my global super duper privileges :)) :

1) Copy that list 2) Prepend MediaWiki: namespace 3) Post to Special:Export 4) Automate it:

sed s/wiki$/wikipedia/ all.dblist > all.domains sed -i s/metawikipedia/metawikimedia/ all.domains sed -i s/commonswikipedia/commonswikimedia/ all.domains sed -i s/wik/.wik/ all.domains sed -i s/.wikimania([0-9]+)wikipedia/wikimania\1.wikimedia/ all.domains sed -i s/.wikimaniateamwikipedia/wikimaniateam.wikimedia/ all.domains sed -i s/foundation.wikipedia/wikimediafoundation/ all.domains sed -i "s/(strategy|usability|collab|advisory|grants|board|incubator|internal|chair|quality|exec|wikimaniateam|office|.*com).wikipedia/\1.wikimedia/" all.domains sed -i s/_/-/g all.domains sed -i s/arbcom-/arbcom./ all.domains sed -i s/-labs/.labs/ all.domains sed -i s/wg-en.wikipedia/wg.en.wikipedia/ all.domains sed -i s/media.wikiwikipedia/www.mediawiki/ all.domains

while read domain; do wget http://$domain.org/wiki/Special:Export --post-file=postdata.txt -O $domain.txt done < all.domains

6) Profit!!

Wikis using some kind of templating grep -l "{{" *|wc -l 255

Total usage: grep "{{" *|wc -l 732

Using parserfunctions grep "{{#" *|wc -l 28 (across 22 wikis: als.wikipedia.org bar.wikipedia.org ca.wikipedia.org commons.wikimedia.org en.labs.wikimedia.org en.wikibooks.org fa.wikipedia.org fa.wikiquote.org gl.wikipedia.org it.wikinews.org it.wikiquote.org meta.wikimedia.org ru.wikipedia.org simple.wikipedia.org sv.wikibooks.org tr.wikibooks.org tr.wikipedia.org tr.wikisource.org zh.wikibooks.org zh.wikipedia.org zh.wikiquote.org zh.wikisource.org)

grep "{{PAGENAME}}" *|wc -l 18

Used for namespace name: grep "{{ns:" *|wc -l 226

grep "{{localurl:" *|wc -l 5

grep "{{grammar:" *|wc -l 8

grep "{{plural:" *|wc -l 0

grep "&lt;nowiki" *|wc -l 0

Wikis with using all default messages: grep -L "<revision>" * | wc -l 273

Private wikis not read: grep "<html" *|wc -l 23

On Mon, Aug 31, 2009 at 1:01 PM, Happy-melonhappy-melon@live.com wrote:

"Platonides" Platonides@gmail.com wrote in message news:h7gok4$6vv$1@ger.gmane.org...

...

1. Copy that list
2. Prepend MediaWiki: namespace
3. Post to Special:Export
4. Automate it:

... 6) Profit!!

What's step 5?  :-P

"???", presumably.

On Mon, Aug 31, 2009 at 3:56 AM, Domas Mituzasmidom.lists@gmail.com wrote:

...

I asked about this a while ago. http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/00... :Aboutsite

asking on-wiki doesn't really makes much sense, as I don't read it ;-p

Anyway, we have to ensure, that most of wikis (at least top20 ones) have got ridden of curly braces and any other expensive parser stuff in these messages, as that costs them up to 10 milliseconds per pageview (if anyone writes a bot to do this automatically, I'd gladly run it with my global super duper privileges :)) :

In the long-term, wouldn't it be smarter to make some of these stable and quasi-stable tokens automatically cache in their evaluated state? For something like {{SITENAME}} there is little reason to be looking it up every single time the message loads, so why not teach Mediawiki to pre-evaluate that and similar items before putting it in the message cache? For the rare case that such things do change you'd need to make sure that the cache does get rebuilt periodically (or have someway to detect such changes and deliberately refresh the cache), but such changes are so rare that adding some lag on update might be acceptable.

-Robert Rohde

Domas Mituzas wrote:

...

For something like {{SITENAME}} there is little reason to be looking it up every single time the message loads, so why not teach Mediawiki to pre-evaluate that and similar items before putting it in the message cache?

There is little reason to keep {{SITENAME}} in Mediawiki: namespace too :) Generally, this could be handled by simple bot.

The point is, then it won't get automatically updates from translatewiki. I don't support having a different syntax for mediawiki messages, but {{SITENAME}} can get susbstituted with a simple preg_replace (a str_replace if we know there won't be tags).

Do note, we end up with other messages, where people want to use singular/plural for e.g. 'Categories'.

plural can be treated the same way.

2009/9/1 Domas Mituzas midom.lists@gmail.com:

Enwiki will be really really sad by not have pagetitle constantly translated by translatewiki :)

That's not the point. If a message is customized by replacing {{SITENAME}} with Wikipedia, updates to *that message* (not to the site name) from TranslateWiki (or changes to the message in MessagesEn.php , in the case of English) will not get through because the local customization containing the old version overrides it.

Roan Kattouw (Catrope)

Hello,

Domas suggested the top 20 wikis, but I think the top 10 of these should be the wikis where optimisations takes precedence over translations.

I restricted myself to top20 because I think there's more work to maintain more. Every wiki which does not have these messages fixed will be just slower. One could say that is also penalty for languages. Should we add sleep() to our codebase whenever we are on fast code path, to offset the need for others to have sluggish interfaces?

By the way, how did you come up with top10 number? Why do you think it is better, than, say, top20? Anyone else has any opinions? Should that be top5? Top20? Top100?

Cheers, Domas

Hello,

That's not the point. If a message is customized by replacing {{SITENAME}} with Wikipedia, updates to *that message* (not to the site name) from TranslateWiki (or changes to the message in MessagesEn.php , in the case of English) will not get through because the local customization containing the old version overrides it.

I understand that. That is the point, once it is overridden, it doesn't reintroduce faulty behaviors.

That is so sad - considering the amount of updates that go to those core messages constantly... ;-) I think both tagline and pagetitle and others will suffer greatly from this. And 'About' message really needs constant updating too :) Seriously, folks, you're enjoying the theory of localization so much, that you forget that there's actual practice out there.

Domas

So what exactly should be avoided? FlaggedRevs has some messages that appear on most pageviews and transclude other messages (such as http://translatewiki.net/wiki/MediaWiki:Revreview-quick-none/en ),

ouch.

should those be substituted in too?

yes.

What about constructs like {{PLURAL}} which don't require pulling the content of another message?

same.

Gerard Meijssen <gerard.meijssen <at> gmail.com> writes:

The plural construct is used when it is not clear how many items will be available. Consequently there is not much to be done about it. Also the effect of plural is not the same for every languages. Welsh allows for six ways of indicating a multitude.

Some of them may be rephrased, and some localizations do not really need them at all. Foe example, in Hungarian "<number> <noun>" constructs the noun is always in singular, so we've been using "{{PLURAL:$1|one|$1}} thingy" because the automated checks complain if they see no PLURAL, but on hu.wikipedia it could be replaced with "$1 thingy" without trouble. (I'm not sure there are actually frequently loading messages which have PLURAL, but it's worth checking.)

Like maybe: $1 thingy<!-- {{PLURAL}} not needed -->

? does that do it?

Robert

On Wed, Sep 16, 2009 at 4:32 PM, Roan Kattouw roan.kattouw@gmail.com wrote:

2009/9/16 Tisza Gergő gtisza@gmail.com:

...

Some of them may be rephrased, and some localizations do not really need them at all. Foe example, in Hungarian "<number> <noun>" constructs the noun is always in singular, so we've been using "{{PLURAL:$1|one|$1}} thingy" because the automated checks complain if they see no PLURAL, but on hu.wikipedia it could be replaced with "$1 thingy" without trouble. (I'm not sure there are actually frequently loading messages which have PLURAL, but it's worth checking.)

Ideally there'd be a better way to mark a message as "yes, I know this usually uses PLURAL, but this language doesn't need it here", that'd also save useless efforts by the parser in expanding PLURAL.

Roan Kattouw (Catrope)

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Wed, Sep 16, 2009 at 9:18 AM, Tisza Gergő gtisza@gmail.com wrote:

Some of them may be rephrased, and some localizations do not really need them at all. Foe example, in Hungarian "<number> <noun>" constructs the noun is always in singular, so we've been using "{{PLURAL:$1|one|$1}} thingy" because the automated checks complain if they see no PLURAL, but on hu.wikipedia it could be replaced with "$1 thingy" without trouble.

I'm pretty sure this warning can be suppressed on a per-language basis.

Domas Mituzas wrote:

Performance-wise it is even better, if all main messages which have {{SITENAME}} get replacements with literals. Otherwise you're adding up 5ms of page load time to each page. :)

I'm not very familiar at all with the new LocalisationCache system, but it seems to me that it might be possible (and useful, from a performance viewpoint) to pre-substitute some essentially constant expressions (which only depend on things like configuration variables in LocalSettings) in advance when the cache is populated.

I can think of at least the following magic words that probably could be so substituted:

* {{SITENAME}} * {{CONTENTLANGUAGE}}, {{DIRMARK}} * {{SERVER}}, {{SERVERNAME}}, {{SCRIPTPATH}}

Also, the following parametric parser functions could be pre-substituted if their arguments are constant (possibly after being themselves substituted):

* {{grammar:}}, {{plural:}} * {{ns:}}, {{nse:}}, {{#special:}} * {{localurl:}}, {{fullurl:}}, {{filepath:}} * {{urlencode:}}, {{anchorencode:}} * {{#language:}}

Actually, almost all parametric parser functions could potentially be constant-folded -- for the localization cache, I think it should be possible to do that even for {{int:}}. Furthermore, conditional parser functions like {{plural:}} and {{#if:}} could be folded as long as just their first parameter is constant.

There would, of course, have to be a configurable list of exceptions: for example, if secure.wikimedia.org shares its localization caches with the non-https versions of the wikis, then {{SERVER}}, {{fullurl:}}, etc. would have to be marked as non-foldable on Wikimedia wikis. In fact, it might be better to let the site maintainer specify a list of config variables that should be considered volatile, rather than of specific magic words, and just let the code implementing those parser functions check that list and mark various functions foldable or non-foldable accordingly. That way, server admins hopefully won't have to keep updating the exception list every time new magic words are added.

Alas, while this seems like an interesting project to me, and I'd very much like to try developing it, I'd also expect it to take more time than I'm likely to have available in the near future. Thus, I'm tossing this idea out for discussion and to see if anyone else might be interested in doing something like it.

On Wed, Sep 23, 2009 at 9:14 AM, mizusumashi mizusumashi@coda.ocn.ne.jp wrote:

I have proposed to change $wgSitename to "ウィキペディア" in Japanese Wikipedia.  A few users oppose itself.  The half of users support changing not the prefix of project namespace but only site's name, while others support changes of both $wgSitename and project namespace's prefix.

Leaving the door open to further change, can we set $wgSitename = "ウィ キペディア" and $wgMetaNamespace = "Wikipedia"?

You should file a bug report with the "shell" keyword:

https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia&keywords=...

You'll need a Bugzilla account. Provide a link to the relevant discussion in your report. Someone will get to it when they have the time.

stevertigo wrote:

See https://bugzilla.wikimedia.org/show_bug.cgi?id=18793 . Note that "ウィキペディア" is not the "canonical" term, so people may not want to provide such functionality. ;-|

-Stevertigo

Your answer is completely unrelated to mizusumashi request, which would have no problem to be fulfilled (assuming there's community consensus).

Don't confuse people with your own war (aka. bug 18793).

Platonides Platonides@gmail.com:

Your answer is completely unrelated to mizusumashi request, which would have no problem to be fulfilled (assuming there's community consensus). Don't confuse people with your own war (aka. bug 18793).

Hm. You are right. The tokens befuddled me.

-Stevertigo