Template talk:rel-top

= Discussion =

Interface
This could use some improvement.

The way it is now, the reader sees a subheading “Derived terms”, and below it is a grey box containing bold sub-subheading text, “Derived terms”. If their window is wide, then the actual interface “[show ▼]” is far removed. This is redundant and somewhat opaque.

Instead of redundant headings, why not make the main heading the interface? Why surround it with a box at all? And why have a separate widget – as long as there is an indication of collapsed state, the entire heading could expand/collapse with a click. —Michael Z. 2009-05-06 15:48 z 

Not working for me outside N0
This template doesn't work for me on my user page, nor in Wiktionary space. Why might that be happening? How can it be fixed? DCDuring TALK 02:27, 24 September 2013 (UTC)
 * In fact, it doesn't work for me on its documentation page. It does seem to work in principal namespace. Has someone decided that is shouldn't be used outside of N0? Can that person be shot or exiled? DCDuring TALK 02:29, 24 September 2013 (UTC)
 * Some of my rel tables work for me and others don't...weird and annoying. Andrew Sheedy (talk) 04:17, 1 May 2019 (UTC)

RFD discussion: September 2019–October 2022
Hi, now that we got the and  working on the mobile frontend I suggest we retire the box-templates for derived and related terms that is not supported by a majority of users according to the vote in BP in 2018. If we need a new vote, please state so and I will create a proper one.

The following templates are proposed deleted: The consequences of this will be: WDYT?--So9q (talk) 22:11, 14 September 2019 (UTC)
 * 1) We will only have boxes left on the translations
 * 2) We will have to convert from the old box-templates to the supported rel3/col3 ones. This might be possible with a clever bot.
 * This does need a vote, because the BP discussion wasn't about getting rid of these templates. I would be against, because these templates have capabilities that and its sisters don't (nested lists for instance), and it's good to keep histories readable. — Eru·tuon 22:30, 14 September 2019 (UTC)
 * Oh, I had not thought about historyreadablility. Could you give an example of a nested list - I don't think I encountered one yet?--So9q (talk) 22:33, 14 September 2019 (UTC)
 * A nested list: . Another thing, lists with interspersed headings:, . Though they don't all look great, they convey extra information that a simple list of links does not. Perhaps there wouldn't be loss of information from the ones with interspersed headings if they were converted to by splitting them into separate lists with a header (title), but I kind of like the more compact format. — Eru·tuon 06:36, 15 September 2019 (UTC)
 * Currently, and  is being used in Han character entries for Korean, Japanese and Vietnamese compounds, so it is not possible to delete these two templates. The reason for using  is because  consumes Lua memory whereas  does not. See CAT:E for Han character entries that have already exceeded default Lua memory despite using.
 * As for and, , , these templates can be kept for historical reasons or deleted altogether. KevinUp (talk) 15:47, 15 September 2019 (UTC)
 * Ok, I understand.--So9q (talk) 18:27, 15 September 2019 (UTC)
 * Actually, I think the benefit of the top, mid, bottom templates in some of the Han character entries is that you can put anything inside them, including a linking template that invokes Lua only once (for instance, in 月). But they may be less memory-efficient than  if they contain many instances of templates that invoke Lua (for instance,  in 學). In general the fewer Lua invocations, the less memory. — Eru·tuon 20:30, 15 September 2019 (UTC)
 * Thanks for the clarification. I didn't realize could be less memory-efficient if it contains a large number of Lua-invoking templates. When I tried to use  instead of  for 學 I found that  used 4.04 MB compared to 4.49MB used by . Since it is possible to further reduce memory for  by using linking templates such as, it would not be wise to delete  and.
 * As for and, these two templates can be removed, because they currently do not work as a divider, unlike . KevinUp (talk) 23:14, 15 September 2019 (UTC)
 * If I understood correctly we are now ready to vote about deleting, , and . Additionally I would like to get rid of  and .  and  is used in about 4000 pages that will need to be (bot) edited and converted to e.g. col3 when there are more than a few terms. Anyone against deleting any of these?--So9q (talk) 11:18, 9 October 2019 (UTC)
 * Strong keep - we should deprecate templates which have been heavily used in the past rather than deleting them. It is very inconvenient when viewing a historical version of a page if you can't see any of the content because the previous version had used old templates. If we want to prevent people from using a certain template going forward we can orphan it and then add an abuse filter which prevents it from being added back. - TheDaveRoss  12:16, 9 October 2019 (UTC)
 * Yes, keep, there are times when you can't use col3 or whatever. Anyway, I hate the terrible presentation given by col3, and now prefer to use der-top3 etc. DonnanZ (talk) 14:23, 9 October 2019 (UTC)
 * Keep, per above keeps. I don't see any good in deleting these. Deprecation, filtering out new usage, redirecting maybe. DCDuring (talk) 00:58, 10 October 2019 (UTC)
 * Thanks for chiming in. I agree with the deprecation in favor of deletion argument. The argument of Donnanz about col3 being ugly has already been voiced during the vote mentioned above.
 * I then propose to delete and  as they have no function whatsoever (since  and  use CSS columns now) and deprecate the others (,,  and ). WDYT?--So9q (talk) 07:54, 10 October 2019 (UTC)
 * rel-mid and der-mid were necessary once, but are now redundant. I remove them when I come across them without any ill effects. So they probably can be deleted, but keep the others. DonnanZ (talk) 09:18, 10 October 2019 (UTC)


 * Kept as there's no deleters GreyishWorm (talk) 01:40, 7 October 2022 (UTC)