Draft talk:Sound correspondences between English accents: Difference between revisions

This draft is based on a discussion at Talk:Sound correspondences between English accents. Any new comments about how best to edit the draft should be made on this page instead, unless common sense dictates that they should go there. Citation unneeded (talk) 08:35, 15 March 2025 (UTC)[reply]

I like the way this page divides Wells’ lexical sets into 4 categories and lists each one separately. It is useful to show the mergers and splits as this page does. Although, some scenarios are missing, e.g:

How can those cases be shown on these tables?

I dislike the use of red and green as this creates accessibility problems for colourblind users. To solve this problem, blue should be used instead of green. The shade of orange currently used is fine. Shading the entire box is better than only using a tick/cross. 1.126.105.202 (talk) 19:01, 7 August 2025 (UTC)[reply]

All excellent suggestions! I’ve carried out the colour one, and I’ve added the other two to my big ‘to do’ list.

Do you think you could provide citations for those? The existing system would show partial mergers using the yellow tick, but right now I’m just focussing on moving the information in the current version of the article to this one – not that I’d complain if you did. It’s just occurred to me that we need to do this for the CURE-THOUGHT merger in SSBE. I’ve added that to the list too.

I really want other people to feel able to edit this page – the template isn’t that hard to use once you get used to it (and will be much easier once I’ve finished filling it all in), but I think the ticks/checks are definitely user-friendly enough for anyone to add to, so feel free if you’ve got a source! ^{[citation unneeded]} (talk) 20:29, 7 August 2025 (UTC)[reply]

as it exists currently, the labels for each table on the left take up the majority of the physical space on the page, but they are just repeated information each time. to mitigate this problem, I think it would be beneficial if you create a single “abbreviations” table similar to your current User:Citation_unneeded/sandbox#New_order in the formatting section, and then have all the following tables use a few letters and a link for each left label.

it would look even nicer if you then made the full “accent” label column travel with scroll as “dia-phoneme” currently does on the main page, add a row above [realizations / splits / mergers] and merge the fourth-level headers into a single table, as your tables currently do not use the second dimension. keeping the third-level headers as separate tables is still a good idea to limit the width of the tables, but having only one set per table is very wasteful. verbal explanations of sets like you have above the trap table would be better somewhere else; either in their own article or in their own section of this article; it is not nice for a reader to split them up and hide them between pages of huge tables.

it would remain easy to visually keep track of which realizations belong to which sets even if the tables become very wide since the splits and mergers columns are very colorful (making a good boundary), and it would bring the emphasis back on the information being presented in the article rather than on the formatting of that information. Will Hendrix (talk) 22:58, 23 November 2025 (UTC)[reply]

Thanks for your excellent suggestions – I’m delighted that someone else has taken an interest in this page! I’ve outlined your points and responded to them accordingly:

• create a single “abbreviations” table in the formatting section, then have all the following tables use a few letters and a link.
  • The current page does this to some extent but it could definitely go further. Hopefully the more regional categorisation of accents will mitigate any potential difficulties in reading.
  • Could use something like {{If mobile|General American|{{Abbrlink|GA|General American}}}} if the abbreviations alone aren’t enough information for mobile users, but we’re probably safe to just stick with {{Abbrlink|GA|General American}}-style linking.
• make the full “accent” label column travel with scroll.
  • I’m not really sure what you mean here. It would be useful if the large regions were sticky, but I haven’t yet found a way to do that. Please let me know if you know about one!
• add a row above [realizations / splits / mergers] and merge the fourth-level headers into a single table.
  • The current third-level headers have a minimum of 7 sets in them, which means that combining them will create tables that are too wide (minimum 3 rows per set x 7 sets = 21 columns, which is too wide). We could probably split them up further though, and this wouldn’t be too much of an issue (say, 4 sets per table?).
• move verbal explanations to their own article or their own section on the table.
• With splits/mergers, it would still be visually easy to keep track of sets in a wide table and the emphasis would be on the information rather than its formatting.
  • This is true, but tall and wide tables remain annoying to navigate and edit. We should try to avoid creating tables that are both too wide and too tall. Scroll bars mean that a table can be either of these without issue, but when a table is both, reaching the bottom (horizontal) scroll bar becomes unnecessarily difficult. We should therefore try to make tables which will fit within most desktops’ windows, unless there’s a way to make the horizontal scroll bar sticky?

Thanks again for your suggestions. I really appreciate the fact that you’ve taken the time to outline them here. ^{[citation unneeded]} (talk) 03:36, 25 November 2025 (UTC)[reply]

no, thank you for starting this; as a lover of big tables and lists I always enjoy seeing pages like this getting an uplift.

> “accent” label column travel with scroll

in my head sticky columns and rows would work the same; apparently I was wrong. possibly something with nested tables would work? I couldn’t figure it out.

> 4 sets per table

I think that sounds like a good number. I put a testing table at the bottom, you can look at the history revisions to see what different numbers of columns would look like. 4 seems like a good middle ground, two tables per section

> sticky horizontal bar

shift+scroll works horizontally like scroll works vertically; so even if you don’t have a horizontal scroll wheel you can still scroll sideways. I do agree that tables should try to fit on a single screen; but screen resolution differences and user preferences with font size and sidebars makes so much variation that you can never make everyone happy.

–

putting multiple columns also made the header pretty thick with word wrap, would be nice if that got a little more compact as well. maybe something could be combined there? idk

Will Hendrix (talk) 07:56, 26 November 2025 (UTC)[reply]

now that I’ve had it all up together on my screen for a bit, maybe realizations / splits&mergers would be better as two tables? ie, instead of each section having one table with the first four words and one with the rest, if we have one table with the realizations and one with the colorful split/merger boxes it would prob look more put together. they both take up about half the size of the table so I think it would still end up looking pretty balanced, and that would solve the overcrowded header as well. it would also mean we could eliminate some of the duplicate columns, like the double trap-bath split. also centering things would prob look nice too. Will Hendrix (talk) 09:30, 26 November 2025 (UTC)[reply]