User:Rjanag/samplearticle
Test for updating the {{zh}} template's traditional-simplified ordering capabilities:
- simplified Chinese: 西贡市; traditional Chinese: 西貢市
- simplified Chinese: 中国; traditional Chinese: 中國; pinyin: Zhōngguó
In the current version of the template, the only way to make the above things get ordered traditional-first is to add a |first=t parameter in each one, like so:
*{{zh|s=西贡市|t=西貢市|first=t}}
*{{zh|s=中国|t=中國|p=Zhōngguó|first=t}}
I want to update the template so you can specify first=t in one place and have that set that preference over an entire page. One way is with this setup: basically, just create a subpage of the article/page in question (in this case, it's User:Rjanag/samplearticle/zhformat), and in that page write nothing but t or s. That is essentially a constant that the template uses to make its decision about how to display characters in a given page. (In code terms: it transcludes that subpage, using {{{{FULLPAGENAME}}/zhformat}}, and uses its value as the default value of the parameter |first=.)
Try going to User:Rjanag/samplearticle/zhformat and changing between t or s and saving the change; when you come back here and clear the cache, the order should switch.
Individual instances of the template within the page can still override the article setting by explicitly calling |first=t. For example, the template below should remain traditional-first no matter what you do to User:Rjanag/samplearticle/zhformat:
The main disadvantage of this scheme, of course, is that it requires creating a subpage for every article that wants to use it. This might be a turnoff for non-computer-savvy users (maybe I could try to design some wizard on the documentation page, with fields where they enter their article title and the ordering they want and then the wizard creates the subpage for them). The advantage of this scheme is that it keeps you from having to write |first=t a million times in long articles where traditional should be first (such as Taiwan and HK-related ones). Also, the current setup doesn't break any existing template transclusions (as far as I know), so even if this is implemented but never actually used, everything will still work fine.
Discussion
[edit]If anyone reading this is better with template programming than I am and knows of a more elegant way to do this without creating subpages, I would be happy to hear how. You can leave suggestions at the talk page or we can just discuss below this.
- Interesting idea. Minor point: subpages don't act the same way in mainspace (see WP:SUBPAGE). They'll show up as normal articles with a "/" in the title. You could instead make them all subpages of the template, like {{zh/format/{{FULLPAGENAME}}}}. Shubinator (talk) 02:26, 26 September 2010 (UTC)
- Ah, forgot about that. I don't have a problem with doing it that way; it makes the page harder for editors to find but I could find a place to leave a note I guess. Or maybe even create some template, similar to
{{SpecialChars}}templates, that shows up somewhere near the top of the article and says something along the lines of "transcriptions in this article are shown in [traditional/simplified] characters first, per the settings [[here]]", with a link to that article's template subpage. rʨanaɢ (talk) 03:26, 26 September 2010 (UTC)- The template idea is good; makes the process more transparent. Of course, make sure the templates behave properly if a vandal decides to use "first=FU" or the like. Shubinator (talk) 05:54, 26 September 2010 (UTC)
- True...what happens right now is that if the subpage says anything other than "t" it just defaults to simplified ("s" is vacuous but makes things clearer). rʨanaɢ (talk) 05:57, 26 September 2010 (UTC)
- That works. Shubinator (talk) 06:02, 26 September 2010 (UTC)
- True...what happens right now is that if the subpage says anything other than "t" it just defaults to simplified ("s" is vacuous but makes things clearer). rʨanaɢ (talk) 05:57, 26 September 2010 (UTC)
- The template idea is good; makes the process more transparent. Of course, make sure the templates behave properly if a vandal decides to use "first=FU" or the like. Shubinator (talk) 05:54, 26 September 2010 (UTC)
- Ah, forgot about that. I don't have a problem with doing it that way; it makes the page harder for editors to find but I could find a place to leave a note I guess. Or maybe even create some template, similar to
- I would like it better if whatever is first depends on which is first in the template, i.e. if "t=something" comes before "s=something," then Traditional is shown first. Asoer (talk) 05:40, 26 September 2010 (UTC)
- I don't think that's possible in a template, given the limitations of MediaWiki design; named and numbered parameters just don't mix like that, as far as I know. But
{{zh-full}}(which is actually multiple templates put together) has the functionality you are describing. rʨanaɢ (talk) 05:47, 26 September 2010 (UTC)
- I don't think that's possible in a template, given the limitations of MediaWiki design; named and numbered parameters just don't mix like that, as far as I know. But
- As described it seems there are a couple of issues with subpages: they are non-intuitive for editors and won't show up in page histories: what's to stop someone with a very particular idea about which should go first mass-changing or adding a bunch of pages and it not being noticed? Vandalism or inadvertent deletion might also be a problem.
- Could it be done using categories? I've done very little template programming but searching MW for things that might help I found this which I don't know if it's enabled here. It could be used with a hidden category, which would show up in changelists but not on pages and would also make it easy to find all pages using it for e.g. statistical purposes. The category could even be inserted by one use of the template, then picked up by others (that sounds like it shouldn't work though).--JohnBlackburnewordsdeeds 10:42, 26 September 2010 (UTC)
- That's a great idea. Having the setting be within the actual article page is what I originally wanted, but wasn't aware of any way to do it; this might be a solution. But will it work for all users, or only users who have this extension installed in their settings? rʨanaɢ (talk) 13:08, 26 September 2010 (UTC)
- I'm not sure. The maunal page suggests it's a local setting but it's not clear what "local" means in this context - per installation, or per site (as in when a server hosts multiple wikis) or per user? Search here on 'LocalSettings.php' and a lot of users have them, which suggests the latter. There should be a global settings - DefaultSettings.php from the above manual - which could be used instead. And the extension would still need installing if it isn't already.--JohnBlackburnewordsdeeds 13:42, 26 September 2010 (UTC)
- Yeah... I don't know much about this MW stuff either, but I think maybe it means it needs to be installed on a given wiki? So once it's on en-wiki (if it isn't already) maybe it will work or everyone... anyway, I'll try to make a mock-up here in a minute. rʨanaɢ (talk) 13:46, 26 September 2010 (UTC)
- Update: it seems this extension isn't enabled on enwiki yet. I left a message on VPT about it. rʨanaɢ (talk) 13:55, 26 September 2010 (UTC)
- I'm not sure. The maunal page suggests it's a local setting but it's not clear what "local" means in this context - per installation, or per site (as in when a server hosts multiple wikis) or per user? Search here on 'LocalSettings.php' and a lot of users have them, which suggests the latter. There should be a global settings - DefaultSettings.php from the above manual - which could be used instead. And the extension would still need installing if it isn't already.--JohnBlackburnewordsdeeds 13:42, 26 September 2010 (UTC)
- That's a great idea. Having the setting be within the actual article page is what I originally wanted, but wasn't aware of any way to do it; this might be a solution. But will it work for all users, or only users who have this extension installed in their settings? rʨanaɢ (talk) 13:08, 26 September 2010 (UTC)