Template talk:Expand language/Archive 2

From WikiProjectMed
Jump to navigation Jump to search
Archive 1 Archive 2

New named param 'section': feedback requested

Hello. I've mocked up a new version that replaces the boilerplate "This article..." with "This section...", under control of the new param, |section=. When section=yes (or any other legal YesNo value), the replacement occurs; otherwise it doesn't. It works in the single, and multi-lang cases. Code is present in the sandbox, test cases have been added.

I've been creating and modifying templates for some time; this would be my first use of template-editor permissions on a protected, highly-used template, and I would prefer to have some additional eyes on this, before I make the change in the template itself. Does anyone see an objection, or perhaps a better way to do it? Here is a diff between the live template (left) and the sandbox (right), and here are the test cases. Once approved, I'll make the corresponding change to /doc page. Thanks, Mathglot (talk) 09:49, 14 June 2020 (UTC)

Soliciting feedback by pinging top contribs (over 4% of text): @Calliopejen1, Trialpears, Rich Farmbrough, SilkTork, MSGJ, and Fuhghettaboutit:. Thanks (and ping, please), Mathglot (talk) 01:39, 16 June 2020 (UTC)
Mathglot, looks good from a technical perspective! Thanks for being careful and setting up proper testcases. I would usually wait a bit to make sure no one objects before adding features to protected templates, but since it's such a small feature and we've had at least two pairs of eyes looking over it I think you are good to go. ‑‑Trialpears (talk) 01:59, 16 June 2020 (UTC)
Trialpears, thanks! Since the pings are out there, and there's no hurry, I'll wait a bit for others to chime in who may wish to. I'm forgetful; somebody ping me if I forget to come back in a few days! Mathglot (talk) 02:47, 16 June 2020 (UTC)
The normal way of doing this, for cleanup templates, is to have {{{1}}} support "section", and to have a matching template called {{Expand language section}} which has the same functionality, usually as a wrapper. Other than that I have full confidence in your technical ability. All the best: Rich Farmbrough 06:48, 16 June 2020 (UTC).
Rich, thanks for your comment. I don't disagree, and there are numerous templates that do it that way. The ones that use |section=yes either are just variants, perhaps early ones, that should maybe be extended now to do it that way (otoh: if it ain't broke...), or, they have to do it that way, because {{{1}}} is already in use, as in {{Merge from}}, and we can't usurp it, or as in this case, where no positional parameter is defined. Further complicating the issue, is that {{Expand language}} isn't really intended to be used on its own, but only via invocation by any of a series of child templates ({{Expand French}}, {{Expand Spanish}}, and so on). I think there are dozens and dozens of them; frankly, nobody is really going to ever create {{Expand French section}}, modify {{Expand French}} to accept the |section= param, test both templates with new test cases, modify the doc for them both, and then do it all again for dozens of templates. Unless you can think of something, I think we're stuck in this case; there just isn't enough volunteer bandwidth for it. Mathglot (talk) 01:59, 17 June 2020 (UTC)
These templates used to support param 1 as section: See this apparently heavy-handed 2009 edit. All the best: Rich Farmbrough 15:32, 17 June 2020 (UTC).

I have no comment to make on the technical aspects. My concern with this template in general is that it should be on the talkpage or page notice rather than the article page, as it is not alerting people to an actual or potential fault, but is suggesting a potential source to help build the article (I say "potential" because in random checks I have done I often find that the other language article has so few or such poor quality references that it shouldn't used at all - simply copying in and translating would not be appropriate unless the sources can be checked). The find sources templates do the same sort of thing (arguably more usefully and effectively and more in line with Wikipedia's policies and ethos) as this template and those are placed on the talkpage. As such I would oppose this addition as it assumes that the rightful place for the template is on the article page, and builds in more arguments for keeping the template there. SilkTork (talk) 09:23, 16 June 2020 (UTC)

SilkTork, I understand your concerns, and I do recall a discussion about where the templates should appear, including (at least) one arguing for the article page, but down near the categories. I also see why the addition of a |section= param would seem to move things in the direction contrary to your preferred outcome. I'm not quite sure what to say about this, other than to try and separate the issues, deal with this one first on the (narrow, technical) merits, and that I'd be willing to revisit the whole issue of placement, as enough time has passed that consensus may have changed. If you decide to raise it, please {{ping}} me to the discussion. Thanks for adding your thoughts, Mathglot (talk) 02:06, 17 June 2020 (UTC)

 Done. Code change implemented in main template. Doc change coming soon. Thanks to everyone for your feedback! Mathglot (talk) 00:14, 19 June 2020 (UTC)

Downstream changes

I've started in on the knock-on changes required to fully implement the |section= param:
Updated:

Still t.b.d.: add the param code for the remaining language templates. Please update the list as needed.

Worksheet for managing 'section' param update for Expand lang templates

After you've updated the template, please change to {{checked box}} and sign.

I can do a handful now and again, but help would sure be appreciated! Thanks, Mathglot (talk) 08:16, 19 June 2020 (UTC)

Added ar cs et da fa fi hu no ro sl sk tr uk vn. Mathglot (talk) 18:02, 19 June 2020 (UTC)
Added Bosnian, Bulgarian, Georgian, Hebrew, Hindi, Indonesian, Kurdish, Latvian, Lithuanian, Malayalam, Tagalog, Tamil. Mathglot (talk) 03:01, 22 June 2020 (UTC)
Added Croatian, Greek, Kannada, Macedonian, Nepali, Punjabi, Urdu. Mathglot (talk) 07:41, 26 June 2020 (UTC)

Template-protected edit request on 3 July 2020

Please apply Special:Diff/963293142/965808749 to disable automatic template categorization on /sandbox subpages. For example, see categorization of Template:Expand French/sandbox and Template:Expand Spanish/sandbox. —⁠andrybak (talk) 14:58, 3 July 2020 (UTC)

 Done * Pppery * it has begun... 19:11, 3 July 2020 (UTC)

Expand vs. Further

@SilkTork:, I haven't forgotten the issue you raised above (perma), and I wanted to address it. If I understand correctly, you have two main concerns: one is where to place the Expand template, and the other is whether it's even appropriate to use it at all, due to "defect" versus "further improvement" considerations. The first issue has been contentious, and I don't wish to address that just now. In this discussion, I want to focus on the second issue.

I had a thought about a possible way to address the issue without a code change. My idea is to add a link and some text about the {{Further}} template to the /doc page. {{Further}} has no whisper of "defect" about it, and is also less obtrusive than a banner (I wonder if that isn't perhaps a third objection to the Expand template, in your view).

{{Further}} already supports interwiki links. They aren't used very much, but this may change. They can be very handy, both for translators who wish to expand an article, as well as for bilinguals who want to view the originals without having to scour the history for them (which doesn't always contain proper attribution anyway). See for example Offshoots of Operation Car Wash.

Ironically, the new |section= param here might be a driver of increased use of the {{Further}} template with an interwiki link. If we altered the /doc here, to suggest use {{Further}} template as an alternative in some cases, and added some text to {{Further}} documenting the use of interwiki links, would this help assuage your concerns about the use of {{Expand language}} any, in particular, that of the |section= parameter? If it does, we could disuss here what wording to use for this template, and have a separate discussion at Template talk:Further. (Alternatively, I see nothing stopping us from making a not-so-bold change to better document what already works there, without waiting for a discussion about it.) Your thoughts? Mathglot (talk) 20:53, 25 July 2020 (UTC)

That sounds reasonable, though I confess I'm not entirely clear what the finished template would look like on the page. SilkTork (talk) 21:18, 26 July 2020 (UTC)

Location of this and related templates within articles

For information, there is a discussion at Templates for discussion about where this and related templates should appear in articles, with a possible outcome that they should be placed only at or towards the ends of articles, and not at the beginning. Hallucegenia (talk) 19:23, 18 April 2021 (UTC)

Improving multiple language documentation

Hi Mathglot, just wanted to follow-up from the template discussion. I poked around and I think my confusion came from the fact that only (I believe) Template:Expand language can have the multiple language codes. I had assumed the daughter templates, like Expand Italian, could take the multiple language arguments, but they failed when I tried to use them. If either the main template multiple languages header had another sentence or the daughter templates had a single line to the effect of "You have to use Expand language to link to multiple language wikis", I think I would have been able to figure it out. —Wingedserif (talk) 12:22, 20 April 2021 (UTC)

@Wingedserif: thanks for adding your experiences here. That makes sense and should be easy to fix. The template itself is protected, but the doc page (Template:Expand language/doc) is not. This is a wiki; if you'd like to make an addition or change to the template doc to add that line, or some other wording that might have helped you earlier, by all means do so. As far as the daughter templates, I'll take a look later to see if they transclude bits of the doc, or if we'd have to add wording individually to each one. Thanks, Mathglot (talk) 19:51, 20 April 2021 (UTC)
Now that I look at it, there have been a number of changes made to the functionality of this template, which changed it from a template not to be used on article pages, to one that is designed for article pages. The documentation was not altered to keep up fully with those changes, as it should have been at the time those changes were made. In any case, we may need to make additional changes to the doc of this page to rectify that, beyond just the one issue you raised here. However, this type of additional change isn't on you, Wingedserif; I'm only mentioning it here while it's fresh in my mind so I don't forget, and to alert other habitual editors of the template of this situation. If you make just the one change based on the issue you first identified, that would be plenty. That said, you have as much right as anybody else to dive in and fix up the entire doc page based on the current state of the template code, if you feel like it. Thanks again for your comment above. Mathglot (talk) 20:12, 20 April 2021 (UTC)
The lacking documentation is probably largely on me (I added the multi-language support and some other minor improvements in early 2020). I I'll have a look and see what I can do. --Trialpears (talk) 20:19, 20 April 2021 (UTC)
I've gone through the docs and tried to improve it and make sure everything is documented. Don't have more time today, but I believe there should be some categorisation improvements to the template as well to prevent nonexsistent topic or fa categories to be added when used in the main template directly. When that is done basically everything should be possible to do using the main template without issues. With a solution like {{globalize/name}} it would be possible to add aliases to allow for things like "French" instead of fr which would make it possible to have one easy to use template for all languages. I'm not sure if that last step would be desirable though. --Trialpears (talk) 20:55, 20 April 2021 (UTC)
@Trialpears:, I can see that there is already code to prevent non-existent category generation per fa or bad topic, but I haven't run tests to see if they work or not. Maybe add some testcases, and we can work from there. Adding 'fr' or 'French' already exists in some templates, such as {{Needtrans}} and is pretty easy to do. I wouldn't bother with the code, though, until the active Tfd resolves itself. Mathglot (talk) 00:48, 23 April 2021 (UTC)
Mathglot The non-existent categorization code was not comprehensive and not fully applied for topics and FAs. It is now however. There is still some problems with missing categories for topic though which I may fix shortly (no promises though). I don't feel like this is the project I want to push for right now, but I could help out with implementation if you want to. --Trialpears (talk) 23:59, 24 April 2021 (UTC)

Starting with Wingedserif's comment and fix, I started to look at the doc, and realized it was inscrutable and incomplete. The most basic feature of the template, namely that it has two rather different purposes, for which only some parameters are used in each case, was completely ignored. (Not that any of the parameters were described before. I start chipping away, and in the end, all the little chips ended up amounting to a rewrite. Because of the double purpose, the standard set of template doc sections didn't really work well, so I came up with something different, which I think works; see what you think. I'm not done yet (categorization isn't completely described, and there are other problems) but I'm stopping for now. Jump in and lend a hand, if you feel like. Mathglot (talk) 00:52, 23 April 2021 (UTC)
I'm switching to the /howto now, and expanding it, adding some doc for stuff that isn't available for all languages, like |fa= and |topic=, and I'm trying a couple of ways of handling it. Mathglot (talk) 05:50, 27 April 2021 (UTC)

Comprehensive category ifexist checking

Hi, Trialpears, can you explain what you were going for in this edit? What functionality or fix do we have now, that we didn't have before? Also, if you meant to include all categories, what about the topic-defined subcats? Mathglot (talk) 11:07, 28 April 2021 (UTC)

Mathglot, it prevents the template from adding articles to nonexistent categories. Not all categories were checked to exist before this edit. I think I took care of the topic categories? --Trialpears (talk) 13:34, 28 April 2021 (UTC)
Ah okay, thanks. Because of the use of expensive parser function calls, this should probably be mentioned in the /doc somewhere. See the row template doc for an example of how I did it. Mathglot (talk) 19:39, 28 April 2021 (UTC)
Sorry kind of forgot about this. I've added a bit about the expensive parser functions. Shouldn't be a problem anywhere since this template is only used once and doesn't use a ridiculous number of them, but might as well mention it. --Trialpears (talk) 11:03, 1 May 2021 (UTC)

Recommendation of third resource tip for "machine translator" basis

The template already recommends DeepL and Google Translate. As a third starting-point, I believe the template should also mention Yandex Translate which is both notable and reliable in both my and others' experience. The quality for common languages such as e.g. German, French seems to, on average, range somewhere between DeepL and GT. YT does seem to have a higher rate of explicit mistakes like not translating certain terms; however I've had many cases where Yandex had the best tone overall. So, I believe "third time's the charm" here.--~Sıgehelmus♗(Tøk) 03:15, 14 May 2021 (UTC)

Improving documentation of daughter templates

The daughter template documentation has been expanded, in the sections on Parameters, Categorization, and especially in connection with the table of valid topics, and their associated subcategories. I've updated the /howto to include sections on Topics map to subcategories. The the rows in the the topic table are dynamically generated based on whether the category for the topic code exists. The |geo= code (Geography topic) is by far the most common subcategory and the most highly populated, so its associated subcat is used as a proxy for whether to mention topics at all for a given Expand <language> daughter template. Details at {{Expand language table row}}. Mathglot (talk) 10:17, 28 April 2021 (UTC)

Trialpears, I've completed the documentation upgrade for the daughter templates. Can you give it a once-over? Also, there's a white-space issue I haven't been able to fully resolve, although I can live with the current version. Contrast, for example, the "topic table" in the #Categorization section of the doc, as seen in Expand FOO templates that have many table rows and subcategories (such as {{Expand French}}, {{Expand German}}, and {{Expand Italian}}) with templates that have just a few rows/subcats ({{Expand Catalan}}, {{Expand Czech}}, {{Expand Estonian}}), and notice the white space above in each case. In the shorter tables, the extra white space above is rendered as one or more sets of paired <p></p> tags, each pair generating another blank line above. There's a strong correlation between the number of p-tag pairs, and the number of "missing" rows in the table, based on subcats that don't exist; thus, the shorter the table, the more white space above. The rendered topic table html structure in the generated page html looks correct to me, and I don't see how a "missing" row would generate a pair of p-tags above the whole table, because that would impl a two-pass compiler, I think, and I always assumed it was one-pass, but who knows.
In any case, like I said, I can live with the extra white space, and I wouldn't spend much time on this, but I admit to being curious what's going on here, as I'd like to understand what mediawiki is doing in this case. I should also probably mention that the use of direct html for the table was my second choice, and I first tried it with wiki table markup. I switched to an Html table after multiple attempts to fix an earlier white space problem were unsuccessful, and corrupted rows in the table itself. I finally abandoned the wiki table, and switched to html. You can find the evidence of my attempts to fix the earlier problem in the history of the table row generating template if you're curious.
I also gave a bit of thought to thinking how one could unite the main table at {{Expand French}} with the single-row table below it (for pacommune) but then decided fairly quickly it wasn't worth it, especially, because the French template may be the *only* template that uses a non-standard topic and subcat like this, although theoretically, any of the daughter templates could. If you think of a clever way to fuse the two tables, though, let me know. But the main thing is if you can just give the doc on the daughter templates an overall, global look, and see what you think. Thanks, Mathglot (talk) 19:37, 28 April 2021 (UTC)
@Trialpears:, managed to unify the table; was easier than I thought. It simply involves a /topics subpage of the daughter template, containing any supplementary rows that are needed. In the case of French, this is in Template:Expand French/topics. I also added another topics table column for cat counts, which I find useful. See {{Expand French}} as an example. Mathglot (talk) 09:30, 1 May 2021 (UTC)
That looks good! The French commune tree looks like a right mess though with direct in article cleanup categories and such. Not gonna bother with it though. --Trialpears (talk) 10:55, 1 May 2021 (UTC)
Indeed; I was hoping that exposing the numbers right in the doc, might serve both as a reminder to use the topic param, as well as spur someone perhaps to work on the categories. I have in mind another change that might catch editors right when they are adding the template, which is either something in preview mode, or something in the expanded banner (i.e., after they click 'show') which would list the ten topic codes, possibly with the article counts, and gently suggest they use the topic param if relevant to the article that has the banner. Mathglot (talk) 11:37, 1 May 2021 (UTC)
@Trialpears:, I ended up implementing something for the expanded banner, but cut it way back to just a suggestion to use 'topic' for cases where it's not already being used, and where the main category contains over 200 articles. There's a link in the prompt to the topic table for the language, so they can choose a topic from the ones already in use. Examples: Chamber of Deputies (Mexico) (shows the prompt); Province of Barcelona (no prompt: already uses 'topic'); Seget, Croatia (no prompt: doesn't use 'topic', but <200 articles in the main category). Mathglot (talk) 19:44, 13 June 2021 (UTC)
Mathglot That looks quite nice! If it wasn't already collapsed I would consider placing it as a preview notice instead, but only people deliberately expanding the banner would see it so that isn't a problem. Do you know if all major languages support the topic parameter? If not that should probably be ensured to avoid non applicable messages. --Trialpears (talk) 19:55, 13 June 2021 (UTC)
Not sure I understand the question 100%, but the way I read you, "yes", but also, "it doesn't matter", because I believe the current code will avoid displaying any non-applicable messages whether they support 'topic' or not. If you can think of some test cases that would produce the failure (or that would produce it if future changes break the conditionals that currently avoid that problem), can you please add them to the test cases page?
I'm agnostic about whether it should be a Preview message or not; I guess the reason I went with the expanded banner, is that for 99% of page visitors it doesn't matter, since they won't expand the banner (is there a way to get statistics on that?), and for the 1%, the banner is already pretty long, and if that scares them they'll back off, and if it doesn't we've lengthened the banner by 10% or so, and I thought that was pretty insignificant. Maybe we should do both, and add it to Preview mode as well, because that is seen by a different set of editors (and by "seen", I mean the 1% of non-banner blinded users that are really looking at the Preview). Mathglot (talk) 20:13, 13 June 2021 (UTC)
Add missing ping @Trialpears:. Mathglot (talk) 20:15, 13 June 2021 (UTC)
The case I was reffering to was the message being displayed on an instance of {{Expand Fooian}} but Fooian didn't have topic level subcategories. I don't see how that would be prevented in the current code but I think the best solution would just be to make sure all languages which may reasonably have 200 uses of the template also has topic categories. --Trialpears (talk) 20:42, 13 June 2021 (UTC)
@Trialpears: Ah yes; I remember coding something for that case and thought it was in {{Expand language}}, but turns out it's in the template that generates the /doc pages for the specific languages. Note the difference, for example, in the topic tables at {{Expand Spanish}}, {{Expand Catalan}}, and {{Expand Basque}}. The key in skipping the table in the Basque case, is a fact I noted about topic geo in the hidden comment at Template:Expand language/howto—search the wikicode for 'proxy'.
To address the issue you posed, we should just import that same condition into the test for whether to generate the 'topic' prompt in the expanded banner. I probably won't get to that soon, but feel free if you're so inclined. That will add one expensive parser function, but that shouldn't be an issue for any page other than a vastly expanded testcases page, and probably not even there. P.S. It's conceivable that things could evolve, such that the "geo-proxy trick" won't work perfectly at some point in the future for some language, but things change slowly and I think the proxy trick is good enough for now. I believe it works for all major languages, and possibly for all languages at present. If you find a counterexample, please add it to the comments. Mathglot (talk) 22:51, 13 June 2021 (UTC)

Merging all Expand language family templates

By dint of some changes I've made to the doc recently and several months ago, I've now persuaded myself that it is possible to merge all of the Expand language family of templates into one main template. The main differences between specific "Expand LanguageName" templates involve differences in the use of topic codes, topic names, and subcategorization, and a single suite of doc pages already handles this for all languages. Further changes of this nature, along with some config data in the right place (which could just be a few parallel subtemplates amounting to a long #switch statement with one case statement per language, and one subtemplate per field, or perhaps an {{Item}} data structure for everything, or even new properties at d:Q34770) to store and isolate the language differences, with a single top-level template replacing all of the Expand French, Expand Spanish, and other templates. (Besides making a merger feasible and fairly straightforward, if done correctly this would also facilitate porting the merged template to other Wikipedias, since all of the items needing translation would be isolated in one place, with the core template code ideally remaining identical across Wikipedias.)

There are some minor discrepancies in topics, such as Italian topic code 'transport' equating to topic name 'Transportation', whereas French 'transport' equates to 'Transport', but those can be dealt with via Category redirects at the outset. There will probably be various other little glitches of that nature in a merger this big, and I could be mistaken, but at this point I don't foresee anything that would be a deal-breaker to performing a merge. If designed correctly, I anticipate that this merger will be tedious, long, and somewhat involved, but not complex as far as design, construction, or code-reading issues. I expect it to be simpler than the current {{Expand language}} template, with a suite of supporting helper-subtemplates.

The current {{Expand language}} template has separate functionality which includes multiple languages, and that would not merge well with the others, at least not at the outset, and would probably have to continue as "Expand language multi" for a while, until after the dust settled from the first mega-merge, and it might not be practical to merge it with the unified single-language version.

I'm not going to get to this right away, or anytime soon probably, and I'm not even sure if it's worth doing, but I know it's possible, now. User:Primefac recently did something analogous to this, with the merger of the Template:Family name hatnote suite of templates (except for a couple of stragglers) all united in one template. Mathglot (talk) 08:10, 5 November 2021 (UTC) updated by Mathglot (talk) 20:27, 6 November 2021 (UTC)

This sounds like a great idea! I started attempting this ages ago and gave up because it was too hard. Calliopejen1 (talk) 02:51, 12 November 2021 (UTC)

Template-protected edit request on 6 March 2022

It seems that there is a bug in the code that generates links to Google Translate.

Problem: At Pinuccio Sciola, the "View" link leads to [1] which says "Can't translate this page". It seems that it has to do with the space between the words, and if you replace "+" there with "_", it works: [2].

Suggested fix: Replace {{urlencode:{{{otherarticle}}}}} with {{urlencode:{{{otherarticle}}}|WIKI}}. Whym (talk) 12:23, 6 March 2022 (UTC)

 Done. P.I. Ellsworth - ed. put'r there 20:57, 7 March 2022 (UTC)

Template-protected edit request on 4 March 2022

I propose editing the bullet points that talk about copyright attribution so that the otherarticle parameter is no longer required. Here is the new code for that, commented out so as not to break the page:

* You '''must''' provide [[Wikipedia:Copying within Wikipedia|copyright attribution]] in the [[Help:Edit summary|edit summary]] accompanying your translation by providing an [[Help:Interlanguage links|interlanguage link]] to the source of your translation. A model attribution edit summary is {{#if: {{Mw lang|fn=is_code|{{{langcode}}}}} | <code>Content in this edit is translated from the existing {{#language:{{{langcode|}}}|en}} Wikipedia article at <nowiki>[[:</nowiki>{{{langcode}}}<nowiki>:</nowiki>{{#if:{{{otherarticle|}}}|{{{otherarticle}}}|{{#if:{{Wikidata sitelink|lang={{{langcode|}}}}}|{{Wikidata sitelink|lang={{{langcode|}}}}}|Exact name of the article}}}}<nowiki>]]</nowiki>; see its history for attribution.</code> | (using German): <code>Content in this edit is translated from the existing German Wikipedia article at <nowiki>[[:de:Exact name of German article]]</nowiki>; see its history for attribution.</code> }}
* You should also add the template {{#if:{{{otherarticle|}}}|<code><nowiki>{{Translated|</nowiki>{{{langcode|}}}<nowiki>|</nowiki>{{{otherarticle}}}<nowiki>}}</nowiki></code>|{{#if:{{Wikidata sitelink|lang={{{langcode|}}}}}|{{Wikidata sitelink|lang={{{langcode|}}}}}|{{tl|Translated page}}}}}} to the [[{{TALKPAGENAME}}|talk page]].

-- Numberguy6 (talk) 18:07, 4 March 2022 (UTC)

 Done * Pppery * it has begun... 01:12, 20 March 2022 (UTC)

Nomination for deletion of Template:Expand Bashkir

Template:Expand Bashkir has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. -- 65.92.246.142 (talk) 02:40, 2 April 2022 (UTC)

RfC: Maintenance categorization

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Should the {{Expand language}} template (and as a consequence its 170 language-specific wrapper templates)...

  • keep categorizing articles in the general "Articles to be expanded" maintenance hierarchy or
  • remove the "to be expanded" categories leaving only language-specific maintenance categories?

20:13, 4 June 2022 (UTC)

Background

{{Expand language}} and its 170 language-specific wrapper templates place two types of hidden categories on articles when they're transcluded. The first is a general "to be expanded" category that falls somewhere within Category:Articles to be expanded and is typically dated such as Category:Articles to be expanded from July 2010. The catch-all Category:All articles to be expanded also falls under this hierarchy and is added to every page. The second type is a language-specific category somewhere within Category:Articles needing translation from foreign-language Wikipedias such as Category:Articles needing translation from German Wikipedia. Where specified, a topical sub-category may be used as the language-specific category yielding examples such as Category:Geography articles needing translation from German Wikipedia. Topical sub-categories are not part of the general "to be expanded" category hierarchy. --N8wilson 20:13, 4 June 2022 (UTC)

The "remove" option will impact at least the 28,000 articles. --N8wilson 11:41, 8 June 2022 (UTC)

Survey

  • remove - The Category:Articles to be expanded has over 144,000 articles. By rough estimate it appears that approximately 1 in 7 of these pages were added by {{Expand language}} or a language wrapper of it. For editors working exclusively in English and unable to translate between WP sites the addition of these foreign-language expansion articles amounts to maintenance clutter in the general "expand" categories. For multi-lingual editors that categorization is not an effective way to locate articles where their language skills may be applied; the language-specific maintenance categories do this much more effectively. For cases where both types of categories are really intended, {{Expand section}}, {{Missing information}} or {{Incomplete list}} can be added (hopefully when English-language source material is presumed to be available) alongside {{Expand language}} so that the article will be included in both hierarchies. --N8wilson 20:13, 4 June 2022 (UTC)
  • remove - I see no reason to disagree with the nom. I note that the Category:Articles to be expanded page does not even say that {{Expand language}} populates the category. -- asilvering (talk) 18:44, 6 June 2022 (UTC)
  • remove - As the nom describes: no additional help by this repetition for anyone doing maintenance. (I did not check the technical details, does the change do as described). -DePiep (talk) 19:38, 23 June 2022 (UTC)

Informal closure

Withdrawing formal RfC per #1, and #5 at WP:RFCEND and per DePiep's suggestion in the related edit request section. Moving forward per consensus here with the reversible edit request that has no visible impact on article space. --N8wilson 17:46, 24 June 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template edit request June 11, 2022

Pending closure and per consensus in the above RfC (Maintenance categorization) (opened 695 days ago) to remove the "to be expanded" maintenance categorization, please implement this edit from the template sandbox. The edit removes the following wikitext string and makes no other changes.

{{DMCA|Articles to be expanded|from|{{{date|}}}|All articles to be expanded}}

This is beingwas submitted before the closure of the related discussion in part to draw some more attention to that discussion which has received limited participation. (Though by a very technical reading, the change proposed here has been shown to be both uncontroversial and supported by consensus if only through WP:WEAKSILENCE.) --N8wilson 17:21, 11 June 2022 (UTC) Updated 20:52, 27 June 2022 (UTC)

I propose you close the RfC first, informally if I understand WP:RFC well. Since the edit reqeuested is simply reversable, this ER being bold is within good Wiki editing. -DePiep (talk) 19:46, 23 June 2022 (UTC)
Seems reasonable. I anticipated this being fairly non-controversial but given the scope of impact (28,000 - 69,000 articles) I thought it preferable to invite comments in case I was overlooking anything. The low participation above and minimal impact on visible article space pages gives me more confidence in the edit request. Thanks for the push. --N8wilson 17:49, 24 June 2022 (UTC)
Support. I see no tresholds for this Requested Edit. -DePiep (talk) 11:09, 26 June 2022 (UTC)
 Done * Pppery * it has begun... 19:57, 1 July 2022 (UTC)

Improving wording/usability

The Click [show] for important translation instructions. is rather awkward. Wouldn't it be better for the button itself to explain what it does intuitively, rather than having that information elsewhere in the tag? {{u|Sdkb}}talk 06:07, 22 October 2021 (UTC)

Bumping thread. {{u|Sdkb}}talk 06:58, 23 October 2022 (UTC)

Edit request 23 November 2022

Description of suggested change: Add a comma to the lines relating to Machine translation to the other languages (doesn't seem to appear on this template?) before "like" and after "Translate" for grammatical reasons. Currently it feels a bit awkward as it feels like "is" should be "are" since it mentions 2 machine translations, however it's just providing examples and excluding the examples it reads "Machine translation is a useful starting point for translations"

Diff:

Machine translation like DeepL or Google Translate is a useful starting point for translations
+
Machine translation, like DeepL or Google Translate, is a useful starting point for translations

Blaze WolfTalkBlaze Wolf#6545 19:09, 23 November 2022 (UTC)

 Completed. To editor Blaze Wolf: certain language codes must be used to make the text appear when [show] is clicked. See below where "hu" is the langcode used, as in {{expand language|langcode=hu}}:
P.I. Ellsworth , ed. put'r there 22:18, 23 November 2022 (UTC)
Ah alright. THanks! ― Blaze WolfTalkBlaze Wolf#6545 23:07, 23 November 2022 (UTC)
my pleasure! Paine  02:35, 24 November 2022 (UTC)