Last modified: 2013-12-04 17:29:21 UTC
There have been several cases in the past (e.g. https://gerrit.wikimedia.org/r/#/c/59575/2/GettingStarted.i18n.php) where we could have used a message (included in other messages) referring to one or more pages in the main namespace. I propose main-namespace-page. This should also have PLURAL support. Hypothetical use cases: 'Edit your first {{int:main-namespace-page}}' 'These {{int:main-namespace-page|2}} need improvements.' On Wikipedia, it would be article/articles. On Wikidata, item/items. On Wiktionary, entry/entries, etc.
(In reply to comment #0) > On Wikipedia, it would be article/articles. On Wikidata, item/items. On > Wiktionary, entry/entries, etc. How can it be in core then? nstab-main is it, except that it's capitalised and can only be singular. Given that "We're trying something new", I guess you can as well abuse it though.
Nemo, sorry, I wasn't clear what I was proposing. Core should just be: 'main-namespace-page' => '{{PLURAL:$1|page|pages}}' Wikipedia would then override it to: '{{PLURAL:$1|article|articles}}' Etc.
I think you're looking for key 'article' which has a default value of 'content page'. Content pages are not confined to the main namespace, as there can be multiple content namespaces.
I think it's possible that one specific to the main namespace might be needed, but we can cross that bridge when we come to it. For now, I'm okay with doing it for a content page. For wikis with only one content namespace (like my initial examples) the distinction is not necessary. That still leaves the issue of plural. PLURAL support can not be added to 'article' as far as I know, since then existing uses (not passing a number) will break. It looks like if there is no number passed in, it uses the second (or maybe last) case, which is plural in English. So I still think a new message is necessary.
Also, the casing is an issue, since the message should be usable as a normal word in the middle of a sentence (e.g. lowercase in English), which 'article' is not.
(In reply to comment #5) > Also, the casing is an issue, since the message should be usable as a normal > word in the middle of a sentence (e.g. lowercase in English), which 'article' > is not. Well, if you use {{int: you can as well use {{lc:{{int: I guess.
(In reply to comment #5) > Also, the casing is an issue, since the message should be usable as a normal > word in the middle of a sentence (e.g. lowercase in English), which 'article' > is not. That is an invalid use case from an i18n perspective. See the i18n documentation.
(In reply to comment #7) > That is an invalid use case from an i18n perspective. See the i18n > documentation. What part of the documentation? Do you mean it's not acceptable to compose a message like my initial examples? (In reply to comment #6) > Well, if you use {{int: you can as well use {{lc:{{int: I guess. That doesn't address the plural issue. Also, I'm not sure whether an lc is the best way to go about it (it might not work for some cases, in addition to some languages needing to remove it).
Substitution with arbitrary words in running sentences is always problematic. The only solution I see here is indeed using "You can do something to content page{{PLURAL:$1||s}}", where what you're trying to address is directly and explicitly in the string that is to be translated.
Alright, looks like this is not the correct approach. Marking WONTFIX.
Although the suggested approach was not correct I think a solution to this is much needed. Could we suggest a better implementation? In mobile in the watchlist view, rather than saying 'Pages in the main namespace' I would like to use the word articles... I'd effectively want to use it in the same way as I use {{SITE_NAME}} - very rarely but on occasion. could we have something like {{MAIN_NAMESPACE_NAME}} ?
As a translator, I aggree with Siebrand single words should not be used in complete sentences. But as discussed on design-l recently (see its archives around beginning of December 2013), these words can be useful in the context the word is used alone, as in the mobile watchlist (see the Jon’s capture http://imgur.com/Jiv0XPJ). I searched where the message nstab-main and affiliates are used, and it appears they are used only for the tabs (Title.php and SkinTemplate.php -- and FakeTitle.php). So these files could be adapted to be added the specific number for PLURAL use (1 in this case) and the message could then be used in a plural context. For information, some languages have very complicated rules for plural, see e.g. [[w:Grammatical number]] and [[w:Plural]]. For the lowercase/uppercase issue, I don’t see problems in using the {{lc:}} parser function, apart perhaps the context for some messages: the linguistic context must be the user interface language and not the content language of the wiki; but I guess this is the case in most interface messages. It must be noted that the current use of these messages in SkinTemplate.php has a fallback system, particularly for the talk tab: this can be namespace-specific or not (in the latter case MediaWiki:Talk is used). I am pretty opposed to distinguish the main namespace of the others since, as pointed in the discussion, some wikis could have many main namespaces. This is a specific case, but I find the best solution is to let the people use the namespace name they want in the messages and extensions (hence the use of the nstab messages), and the wikis which have many content namespaces have to adapt some messages in the way they want.
(In reply to comment #11) > In mobile in the watchlist view, rather than saying 'Pages in the main > namespace' I would like to use the word articles... I'd effectively want to > use it in the same way as I use {{SITE_NAME}} - very rarely but on occasion. Maybe "content pages"? Articles can be in the (Main) namespace, but they can also sometimes be in other content namespaces.
Content pages was suggested and a patch merged and shortly reverted. This is a horribly ambiguous word which means nothing to the average user, especially on Wikipedia where it really means "Articles".
(In reply to comment #14) > Content pages was suggested and a patch merged and shortly reverted. This is > a horribly ambiguous word which means nothing to the average user, especially > on Wikipedia where it really means "Articles". Your comment makes it seem as though "pages in the main namespace" means anything to anybody. Perfect is the enemy of the good.
(In reply to comment #15) > Your comment makes it seem as though "pages in the main namespace" means > anything to anybody. :) I guess [[wikt:Wikisaurus:webpage]] [[wikt:Wikisaurus:creative work]] don't help much. "Content" is not so nice, but it's often considered to be more understandable than technical terms, e.g. most say "free content" and not "free cultural works" and the like. Everything would be easier if all languages had an exact equivalent for the Italian "lemma", I suppose (even its pseudo-hyponim "voce" which is used to translate "article" would be better than "article"); English offers us only "entry" which is both too technical and missing the point. My synonym dictionary suggests "topic"/"subject"... "topic" is used in forums to mean "thread", it's a rather flexible word and conveys the concept of something that is in-scope/on-topic for the wiki. But that might be too brave a choice.
pages in the main namespace is also horrible. It only means a thing to us techies. I wasnt proposing it I was simply using a common bugzilla friendly language. I even said in my comment I wanted articles :p
