YannickFran

I see you flipped the iPad table to match the iPhone one; I was hoping the reverse would happen, after flipping the iPad one a few months ago to make it much less wide. With versions on top, we only add one column per year, whereas with models on top, we'll add likely 3-4 wider columns a year, and it'll rapidly become unsustainable. Interested in your thoughts. DFlhb (talk) 21:03, 14 June 2023 (UTC)Reply

I don't really have an opinion either way. If solely the width is a problem, it could simply be solved by making the table container scrollable and making the first column sticky. I made the change solely to improve consistency with the iPhone version. I do however think that the grouping by model rather than by chip (and dropping the inclusion of the SoC regardless) makes much more sense and is easier to read. But this could work perfectly fine with the rows and columns flipped. YannickFran (talk) 13:19, 16 June 2023 (UTC)Reply

I think scrollability & sticky headers aren't ideal, especially on mobile. It's better to be able to see as much as possible at a glance.

I agree with grouping iPads by model; looks much nicer too. Though I wouldn't do that with the iPhone, since they're almost always released simultaneously, and iPhone & iPhone Pro are more variants than distinct product lines. DFlhb (talk) 13:27, 16 June 2023 (UTC)Reply

I'll reverse the table rotation change soon, with the updated structure.

IT was not my intent to split up de iPhone similarly across base/Pro/Max/etc. as I agree it doesn't make sense there. However, do you think it would make sense for pulling the SE line out of the mainline iPhones? I'll put some time today or tomorrow to inverse this table too. YannickFran (talk) 13:31, 16 June 2023 (UTC)Reply

I wouldn't separate the SE; just doesn't seem necessary, they fit pretty neatly in the chronology next to other devices. DFlhb (talk) 14:33, 16 June 2023 (UTC)Reply

Why did you restore the missing pages for Surface models obviously highlighted in red? Nobody has even hurried up and created the pages yet! 216.145.66.224 (talk) 02:26, 7 March 2024 (UTC)Reply

Please see WP:RED, there is no reason to delete red links unless there is a reasonable expectation that Wikipedia should never cover the subject of the link (not even as a redirect), much less the content that is a red link. YannickFran (talk) 22:47, 7 March 2024 (UTC)Reply

Why won't they ever hurry up and create those pages for those Surface models? 216.145.66.224 (talk) 14:46, 10 March 2024 (UTC)Reply

You keep spying on my edits. :( 216.145.66.224 (talk) 02:30, 7 March 2024 (UTC)Reply

I don't. You just happened to appear in pages I've followed, noticed the same IP making strange changes on multiple articles and then went to your edit history where nearly every edit you've made that wasn't on a talk page had been reverted, so I went to look which edits were not reverted and only found more edits that should be because you are entering very niche information in global texts or even just speculating. E.g. your recent edit to Microsoft text-to-speech voices - which, yes, I have now reverted too - to add "including Balabolka". It's unnecessary. The prior sentence already includes "anything that isn't Narrator", no point to further write down what "anything" may mean, especially when the article never mentioned it prior to that point (or after that). All of your edits are like that, and given the number of times people have had to come in and point that out on your talk page, I'm not the only one who takes issue with that. YannickFran (talk) 22:53, 7 March 2024 (UTC)Reply

You seem to follow a lot of tech related articles. 216.145.66.224 (talk) 14:49, 10 March 2024 (UTC)Reply

An automated process has detected that when you recently edited Microsoft Surface, you added a link pointing to the disambiguation page NPU.

(Opt-out instructions.) --DPL bot (talk) 06:06, 22 March 2024 (UTC)Reply

An automated process has detected that when you recently edited Samsung Galaxy Watch series, you added a link pointing to the disambiguation page HRM.

(Opt-out instructions.) --DPL bot (talk) 17:58, 29 May 2024 (UTC)Reply

Hi, @YannickFran. I started a discussion in the iPhone models article regarding an issue you brought up with the article table's inconsistency and flaws. I believe you should join since this could be of your interest. INFIYNJTE (talk) 23:46, 14 September 2024 (UTC)Reply

This is a general remark and not one that relates to any specific template or article. You, at every turn, have been reverting my edits without discussing my changes first and trying to validate your reversions of my edits by bringing up all kinds of outdated Wikipedia policies that aren’t enforced. Lots of these style guide policies are policies that are either outdated, no longer followed, or have no effect due to newer MediaWiki and Wikipedia changes; I’ve even seen good articles and featured articles that use Body text instead of captions because they allow more detail and explanations of a tables purpose. Using captions is bad when it comes to navbars. They are too small when put in a caption, text size changes or not, and are infrequently used. I’ve seen loads of tables that are content heavy and don’t use captions because the body text is pretty self explanatory for the tables purpose.

Anyways that’s not the conversation I’m trying to have. You, respectfully, need to cease the constant reverting. No consensus is in place for any template or article you have been reverting my edits on with the exception of the Hardware Support section on iOS version history. That is the extent that the consensus goes. Reverts shouldn’t be done without discussing first, as that is one Wikipedia policy that is actually heavily enforced when caught wind of it from Wikipedia administrators.

I’ve been on Wikipedia quite a long time, 12 years. At the start I was an awful editor, making stupid changes that held no value or straight up made an article worse, because I was a kid and didn’t know better. But when I began editing Wikipedia full time I put severe effort into trying to ensure that any edits I make are useful. The whole hardware support debacle is something I regret, so I’ve been trying to improve the state of how they’re displayed on the article to make them more visually appealing, and less complicated. Having captions aren’t necessary, especially in tables where the context is already heavily implied, or is detailed elsewhere in the article. Not to mention, having the navbar be as small as it was in the caption makes it hard to see, which is why I moved it to where I did. You can’t keep continuously reverting edits you disagree with without holding a discussion. You have reverted every single change I have ever made to these templates and quite frankly it is beginning to fall under the disruptive editing policies of Wikipedia.

So I am kindly asking you to please cease reverting edits you disagree with and instead start holding discussions, because reverting is a hostile action and isn’t a super nice thing to do. - Evelyn Harthbrooke (leave a message · contributions) 22:37, 18 September 2024 (UTC)Reply

Surely, you cannot be serious? Right? "You can’t keep continuously reverting edits you disagree with without holding a discussion", do you hear yourself? No discussion? There is an entire talk page proving otherwise. I have repeatedly asked you to discuss changes, you've repeatedly ignored these discussions (note how there are - right now - 3 comments from me addressing the various issues you've created, also note how you haven't discussed any of it). Every time you've been active (both in the version history article and now these support tables), you've chosen to revert the changes I've made outright and most of the time never even bothered to discuss that, even when other people like @George Ho told you you were wrong. You have never placed a single comment in that discussion that wasn't paired with one or more reverts (assuming your version wasn't already the latest), but plenty of time you've reverted things without ever making a comment. There are plenty of comments in that discussion from me however that do not correspond with a revert. Between the 3 tables and the iOS version history article, I've asked to take it to the talk page where I'd opened or commented on a discussion more than I can count on my hands... You've ignored pretty much all of them.

Your reverts to the support tables are a perfect example; the changes I've made did more than just restore the caption, but you've opted to undo all of it without zero discussion, despite openly being asked to (not to mention that your only reason for it is "I don't like it" and not an actual functional reason). The same with reverting back to "iPhone 2G". It's the same story over, and over, and over again.

If you ever bothered to check out the diffs, you'd even have noticed that nearly none of my reverts of you were straight up reverts, but actually incorporated your changes where they made sense. Example given: the 3 edits you've reverted right now.

bringing up all kinds of outdated Wikipedia policies that aren’t enforced ...you've got to be kidding me. Seriously? So we're now going to pretend that the policies that tell you to your face that you're wrong just don't apply anymore? Are you seriously going to pretend that MOS:ACCESS, MOS:COLHEAD, and MOS:TABLECAPTION have been thrown out of the window? There is nothing that "newer MediaWiki and Wikipedia" changes have done that somehow have worked to subvert basic HTML rules (I'd love to see you tell me exactly what work they've done to make body text get linked to tables). I'd love to see you provide proof for any of this, actually. We're exactly is it ever said that these policies not only no longer apply, but now should be actively worked against as you've been doing?

I’ve even seen good articles and featured articles that use Body text instead of captions because they allow more detail and explanations of a tables purpose. Thank you for making it absolutely clear that you have a fundamental misunderstanding of basic accessibility and how accessibility tools work (both for HTML in general as well as per Wikipedia's MOS more specifically).

Having captions aren’t necessary, especially in tables where the context is already heavily implied, or is detailed elsewhere in the article. I've already provided a plethora of technical reasons why that's not how that works here, so I'm not gonna repeat myself yet again.

"You, respectfully, need to cease the constant reverting." she said as she reverted changes on 3 different articles without showing any willingness to discuss despite having been asked to multiple times.

You're doing some incredibly heavy projecting here. Maybe practice what you preach... It certainly makes that apology ring hollow. YannickFran (talk) 23:24, 18 September 2024 (UTC)Reply

I care about accessibility, but most tables don't use captions; I've seen this thousands of times with regard to tables where they don't use captions because THEY ARE REDUNDANT. if they weren't we would see every single table in existence (including every single article involving television show season episode lists) adopting captions. But it is very clearly obvious that they aren't required nor is it Wikipedia policy to put captions in every single table. The only instances where I see table captions as necessary are when they belong to a pre-existing article section, such as on Russian invasion of Ukraine where the tables are better suited in that specific section and table captions are warranted. However I do not see them on most List articles, such as List of The Simpsons episodes, List of Law & Order: Special Victims Unit episodes, or List of Grey's Anatomy episodes, as a couple examples. Table captions are not always necessary or needed, and that's my understanding of Wikipedia guidelines. - Evelyn Harthbrooke (leave a message · contributions) 23:51, 18 September 2024 (UTC)Reply

Using the other stuff exists argument, eh? Again, what might work for your PC may not work in other PCs. Also, those examples you cited don't have titles of tables as headers in the middle of tables, even without captions. I certainly don't think tables lacking captions are reasons to change back from captions to such headers that are normally discouraged. George Ho (talk) 01:18, 19 September 2024 (UTC); edited, 01:19, 19 September 2024 (UTC)Reply

Discouraged on what grounds? - Evelyn Harthbrooke (leave a message · contributions) 06:39, 19 September 2024 (UTC)Reply

MOS:COLHEAD, despit being a guide/supplement. Unsure about Help:Table#Colspan and rowspan, WP:WHENTABLE, WP:HEADER... and MOS:DTAB; the latter three are guidelines, nonetheless. George Ho (talk) 08:31, 19 September 2024 (UTC)Reply

You've previously shown great concern about the accessibility of these templates, yet now you're going out of your way to make them objectively worse. Even if these policies no longer apply (which they still do), that doesn't mean that you now have to do the exact opposite. I seriously ask of you to self revert these latest changes you've made and to elaborate and address the concerns as leveled in Talk:iOS version history#Version support table accessibility. YannickFran (talk) 22:00, 19 September 2024 (UTC)Reply

Don't get me wrong, table captions are useful, but only when the context warrants them. As an example, I added "<iPhone model> color options" as a caption to the iPhone 5s and iPhone 6 color tables, with plans to add captions to the tables on the other articles. However, something as obvious as "this table lists supported iOS versions of this device type" doesn't need captions. And not everything revolves around accessibility, despite it being important. But it's not so important as to add table captions to tables with very clearly obvious context. Therefore, I will not be self-reverting my changes, as unnecessary captions don't serve any purpose, and I stand my ground on that. - Evelyn Harthbrooke (leave a message · contributions) 06:35, 20 September 2024 (UTC)Reply

You are reverting every single edit I make that touches *any* table or template in a way you disagree with, which is not how Wikipedia works. I have tried at every turn to be civil with you, I have tried my hardest, but fabricating never-held discussions and arguing accessibility based on non-existent Wikipedia MOS guidelines isn't very Wikipedian-like.

Let’s go through these one edit at a time:

1. My changes to the iPhone and iPod Touch supported OS release templates regarding merging cells and my use of the colspan and rowspan parameters. Each template call you make of the na, n/a, and ya templates basically creates its own wikitable inside of the wikitable, causing a significant increase in overall transclusions not to mention an insane increase in the HTML code that has to be created to render the page, increasing load times. No wikipedia policy discourages the use of colspan and rowspan parameters, and there has never once been a discussion regarding the use of those parameters in these templates, not once! I literally checked both the talk page and the templates existing revision history, these changes have literally never once been attempted. You reverted my changes over a made up discussion that was never even held. And your claims that a) they’re bad for accessibility and b) bad for readability are downright false. There is no precedent that points to merging cells being bad for readability or accessibility; to expand on this, I just viewed the MOS:DTAB guidelines again to be 100% sure that there is no guideline that mentions the aforementioned parameters, and there is indeed no guideline that discourages their use. The way I used the parameters was intended to ensure that the tables are still readable and I would argue that seeing a single "X" go across 15 versions instead of fifteen individual X's isn't bad for accessibility, in fact it improves it because less processing has to be done by the reader.

2. My changes on Android version history. There is no reason for API levels to be present on the page, and the headers align with both the overview, and the official naming scheme of all Android versions up until Android 10. Likewise there is also no reason for there to be a separate table for every single minor version of Android. No versioning history structure considers 2.0.1 for instance to require its own entirely separate section. It’s a minor release that has no reason for being in its own table with a single entry. It is in my eyes an abuse of wikitables, and has no reason to exist. These changes allow Android version history to resemble the way iOS version history behaved pre-table removal. The explanation for there being no reason to have the API levels be featured is because they are too technical that only a minority of potential readers (say, developers) will care about them, and they are basically an excuse to warrant an abuse of the wikitable syntax. No table with one entry has any valid excuse for existing; they should be merged with the tables for the major release. It was why I also got rid of the version numbers in the headings, but after more disagreement with the removal, I re-instated them.

Please think before fabricating never-held discussions, and stop reverting edits you disagree with, because it is endlessly disruptive and causes these templates and articles to be in a constant state of flux. None of my changes go against Wikipedia policy. You can't just mass revert my edits like this. I significantly disagree with your actions, and it is why I am personally saying that they're disruptive. Making up falsehoods is not constructive. You can give constructive criticism of my changes, and suggest changes, but you have constantly and consistently reverted every single one of my edits to the templates and now you are reverting my changes in article space. You have been the only editor I have had this much difficulty with in terms of getting along with them. Please learn to be more civil, and stop violating Wikipedia policy by immediately reverting my edits without having a discussion. It should be noted that I am completely and fully open to having a discussion, but only if it won't escalate into hostilities and attacks. - Evelyn Harthbrooke (leave a message · contributions) 18:11, 15 October 2024 (UTC)Reply

Are you serious? For starters, I do not "revert every single edit you make" (you on the other hand, have consistently undone and/or removed any changes I and others have made to the iOS version history article). Second, the changes you've made to the version overview tables do in fact go against Wikipedia's accessibility policies. This discussion has been had before when people were trying to appease your inclusion size complaints, and it was - rightfully so - pointed out by other editors that the exact changes you've made now are an accessibility nightmare. So please, tell me again how I am "fabricating discussions". And for the record, what you did is literally an example in the accessibility guidelines for how not to do it. I'll let you self-revert these ones for today.

As for the Android version history, that you don't care about API versions and/or think that's only relevant to developer doesn't mean we should just remove it. It is relevant information. A lot of people don't care about a lot of things on Wikipedia, we might as well just stop editing all together by that logic. As for removing the actual version numbers from the titles; that is just needlessly obfuscating and something we very explicitly don't do for article in similar situations, e.g.: macOS version history. Here's a kicker; not every versioning system works the same. This isn't iOS. Apps compiled to run at API level 25 (which is Android 7.1), won't run on Android 7.0. That's why people split these versions up; because for all intents and purposes - despite their seemingly small version change - they aren't the same target OS and aren't forward-compatible versions of the OS, unlike any n.X release of iOS for example. We don't do this with Windows either, despite all of them being called "Windows 10" or "Windows 11". The good news is, the article actually articulates that distinction through noting the API levels, the bad news is, you removed all information about it. Wikipedia is supposed to be a source to learn new things, not to write down everything you personally understand and remove all the rest. And that was in the end the reason why I undid some of your changes; you removed content and information. You may have noticed that I left all template related changes in tact, it's because I - unlike you - actually check what has been changed and cherry pick to make sure all changes I agree with don't get reversed, instead of blatantly reverting everything. Because I agree with those; that was what I was working towards over the past week anyways. Removing the templates was always the goal. But it was being done slowly so it could be easily undone if anyone would protest. But of course, you knew I was working on that, after all, that's why you began editing that article in the first place. (In the time it took me to write this, someone else also reverted your changes yet again, and you - yet again - reverted them too (edit warring much?), do you ever stop to think that maybe you're in the wrong?)

You seem to be under the impression that people can only revert edits if they break policy or guidelines. That's not how that works. People can also revert changes because they are just bad, introduce incorrect information (which I guess does go against policy), obfuscate information or remove information.

Look, it is painfully clear that every time someone does something that you don't agree with no matter how many people oppose you, not only do you take that as a personal insult (it's why we're here yet again after all), but you also go out of your way to pick fights with them, call them "biased" and "toxic", and accuse them of targeting you. You've done it with me, you've done it way back when the iOS version history tables were removed by consensus the first time around and you continued to insist that they had to be restored, you're doing it right now with the various version table templates removal requests, and you're doing it here yet again with me. I'm not having interactions like this with anyone else on this platform. The only constant in all these situations is you. Maybe take a step back and think about that for a second.

And if you really want to talk about disruptive editing, have you seen the revision history of the iOS version history article? You know, the one where you're constantly adding, then removing, then re-adding tables, constantly remove content others have added because you don't agree with it (based on no policy or guideline, I might add) or because it is "encouraging editors to basically copy vertbatim" (despite the fact that for the sentences I've tested, none are), or where you're removing content just to restore it because you want to "check post-expand include size" (you know there are tools for that while editing, right?)? That article is one giant unstable mess thanks to the edit's you're making. If you're wondering why people don't bother anymore helping out on that article, I can tell you why: no matter what people put on there, sooner or later you will remove it for no apparent reason.

While we're at it... Remember how you are accusing Gonnym of "targeting" you and how they have "a bias against [you]" (where have I seen that before)? In regards to that targeting thing, I couldn't help but notice how over the past few weeks you keep popping up on articles and templates that you've never edited, these articles only have one thing in common: right before you started editing them, there was an edit or discussion comment made by me. It keeps happening over and over again. How peculiar, no? Some people would call that targeting. Of course you're free to edit whichever article you want, but when I read that, I thought "well that's some heavy projecting". But I digress...

Anyways, you've gone out of your way to revert changes (notably, that one was also specifically made to work towards solving issues you raised) and remove content others added earlier based on absolutely nothing, with no reason whatsoever other than what seems to be "I don't like it" and "I think this may invite problematic edits in the future" (which isn't a reason to do that, if a future edit is problematic, we deal with *that* edit). And now you come here and accuse me of "mass reverting your changes"? Seriously?

I am completely and fully open to having a discussion No you're not. If that was the case, you wouldn't have reverted anything and we would now be on the Android version history talk page discussing content as per WP:BRD or any other kind of consensus cycle, we wouldn't be here. You'd also have taken an effort to check the history of the support tables to see that we already tried those changes (I'm think this was even mentioned in the original discussion back in May 2023 on the iOS version history talk page) instead of coming here and accusing me of lying. Furthermore, you also wouldn't ever have felt the need to open clearly hostile discussions like these (the answer - by the way - is nobody, welcome to Wikipedia, where people can add information without anyone having to ask for it first). If you were open to a discussion, you wouldn't have come here to escalate it by attacking me instead. but only if it won't escalate into hostilities and attacks Great! Reminding me, of the 2 of us, who's called the other biased and toxic? Again; practice what you preach. YannickFran (talk) 20:32, 15 October 2024 (UTC)Reply

Okay, how on earth am I somehow targeting you by editing articles and templates I don't usually edit? That's actually attacking me and assuming I have some sort of vendetta against you or like I am going after everything you edit. One, I do not, and two, I am allowed to edit any article I want. What articles I edit or do not edit has absolutely nothing to do with you; Wikipedia is an open platform where anyone can edit what they want assuming they have the ability to edit it. You are once again misinterpreting my intentions and it has absolutely nothing to do with projecting or anything of that sort. And no, people can't just revert edits whenever they want. For the most part, for changes to be reverted, they actually do have to go against policy or guidelines. My changes aren't bad.

And for the record, I actually didn't know you were working on Android version history, that is not why I at all began editing that article, and I have edited it in the past, if you would have bothered to check my contribution history. I wanted to retire the use of the Android version table template anyways, as I went to edit it and I noticed that it was using a dedicated template instead of regular wikitables, so I decided to replace them. However, there are numerous issues with that article as a whole: a) it is basically a changelog (violating WP:NOTCHANGELOG) and b) the article was abusing the use of tables. There does not need to be a table for every single minor Android version in existence (why on earth does there need to be a separate table for 2.0.1 Eclair for example, when it is part of 2.0.x Eclair), and that is an issue I have long had with that article but only decided to make the change with the move to regular tables. The behaviour of Android API levels are the exact same as an app developer targeting iOS 18.1 instead of 18.0, for example. The only thing the API level indicates is the version application developers target. There is no difference at all, and I know this as I actually developed for Android in my spare time for a while, before I migrated to iOS in 2020. However, my knowledge still applies as Google has never touched the way Android version targeting works, so this isn't a reason for API levels to exist, as Google doesn't make the API levels known at a surface level, e.g. in the Play Store.

You're the only editor I have had issues with, so maybe step back and take a look yourself at your editing behaviour and methods. I reverted Gonnym's edit removing the auto-hide, and they effectively instantly proceeded to file an TfD discussion... that is why I took it as retaliation for reverting their edit, but maybe it wasn't the best route to take, but then in the TfD they proceeded to effectively attack me and accuse me of actively wanting to and intending to go against the Manual of Style which was quite frankly not the case at all... Sometimes I forget about the guidelines but I can't check the style manual every single time I make an edit but it is never me intentionally going against it. Despite all this I have no issue with them as an editor. I have no issues with any other editors on the platform. You are the only editor I have constant issues with to the point where we have been in constant back and forths since 2022/2023, not to mention you are also the only editor who has filed a complaint about me on the Administrator's Noticeboard. In addition, me filing those template removal requests, or agreeing with their deletion, isn't me somehow being disruptive, it is a simple fact of reality that changelogs and version histories that are not in prose have no place on Wikipedia if they are blatant changelogs, and per Gonnym's reasoning, there is no reason for templates that are effectively just simple tables to exist in template space, when they could very easily exist in article space with the article the template is on. And adding templates to articles to try and stop them from being deleted, when they have no reasonable reason to exist on a given article (see your attempts to add the supported iPod touch iOS versions template to iPod Touch, despite it not providing any tangible benefits over the existing templates already in place), is unreasonable.

For the record, yes, effectively the entirety of the content someone added to the iOS 18.0 table was effectively copied verbatim from Apple's release notes, and slightly changed to make it look less so. I read the Release Notes myself and compared them to the table's content, they were basically copied verbatim (See Apple's iOS 18.0 release notes for instance about the "Gaming Mode" addition and the iOS 18.0 table pre-removal), and I saw this in the other tables as well, mainly in the iOS 17 table. They were going against policy and guidelines, as they were nearing the territory of WP:NOTCHANGELOG again. iTunes version history has also fallen victim to WP:NOTCHANGELOG, but nobody has bothered to really change it, because articles like these aren't what drives potential editors to the platform. The overall number of people editing Apple articles has dramatically decreased, to the point where most articles related to Apple are unlikely to ever become GAs or FAs. These types of tables blatantly encourage potential copyright violations, despite the previous AfD being held almost entirely on that point.

And accusing people of not wanting to edit iOS version history because of the potential for me to "remove or revert their edits for no apparent reason" is false and untrue; I would never just remove someone's edits for the sake of it, my only issues lie in not wanting the article to fall victim to either WP:NOTCHANGELOG or copyright violations again. I don't have anything to do with there being less active editors on that article; that article's editorship has fallen long before I began heavily changing the article. And yes, the article is in an unstable state right now, but it's kinda hard for it not to be when I am working on converting it to be prose and heavily (and properly) sourced.

All of our discussions have quite frankly led to nowhere, and I am honestly beginning to question if we will ever get along, or if we will always be at each others throats until one of us is permanently banned from editing. I do not want that to happen, I genuinely do want us to get along, but that's for the moment not possible when you revert a lot of my edits based on the premise of "accessibility", when tables all across Wikipedia pretty commonly use rowspan/colspan parameters to reduce duplication; why else would it be documented under Help:Tables if they shouldn't be used? And I'm pretty sure if they were bad for accessibility, it would be noted in MOS:DTAB that they should be avoided. But they are not bad for accessibility, and help prevent hundreds, if not thousands of unnecessary template calls. And I checked the revision history of each of those templates, and attempts to merge the cells were never made, they were always individual cells, even back when the templates were first created by User:LinuxPower. Maybe the idea was mentioned? I don't know. But what I do know is that as far as Wikipedia policy is concerned, using the rowspan and colspan parameters are encouraged.

I should be very, very clear: I do not hate you, nor do I have some sort of grudge or vendetta against you. I want to get along with you. But it is seemingly looking like we will never be able to because of the significant differences we have in how to interpret Wikipedia's guidelines and policies, or what to do when there isn't a policy in place. And, despite what you may think, I actually am fully open to discussions. - Evelyn Harthbrooke (leave a message · contributions) 21:53, 15 October 2024 (UTC)Reply

And no, people can't just revert edits whenever they want. For the most part, for changes to be reverted, they actually do have to go against policy or guidelines. My changes aren't bad. I never said they could be undone "whenever". I said that reverts aren't only for when policy are broken. See WP:DOREVERT for more information.

As for API levels, no they are not in fact the same. Apple's n.X release don't ever contain breaking changes. Whenever Android's API level goes up, they may. It's why Eclaire 2.0, 2.0.1 and 2.1 were listed as their own versions; because they are. As are all other versions where the API level goes up. For iOS, etc. that distinction doesn't exist. Even completely disregarding that, you have now completely arbitrarily combined major versions and left others separate, and removed any context about the API level from the main content. It is a mess.

Come on Evelyne, in previous discussions I and others have repeatedly told you you went against the MOS to the point where you began claiming that they aren't enforced and don't apply (heck, you're doing it right now with the support tables yet again, despite being told it is against the guidelines). While I do not agree with some of the reasons for the nomination of the template, making the assertion that you willingly and knowingly go against the MOS is absolutely not wrong.

The iOS 18 release notes are clearly inspired by Apple's official release notes yes, but they have been completely rewritten and in some occasions expanded beyond what those release notes say, that's is "written in the contributors own words" as this gets. That isn't a copyright violation. As for not removing/undoing content added by others; it's not very easy to check all of it (because frankly, who has the time), but randomly taking other people's changes out of the last 500 reveals that practically none of the edits other people than you made still exist on the page. Beyond some minor maintenance and typo changes; you've removed all of it. In part because you seem to flip-flop on what the article must be. Since early 2023 you've been absolute in that everything must be a table (as were you in that original discussion when the tables were removed in the first place) until a few weeks ago when suddenly everything had to be prose. Are prose better than the lists in tables. Absolutely. Does that mean we should throw everything away again until someone adds it back as prose? No. That is just disruptive. Things like that should just be replaced as it is rewritten. What, you think editors like Max Iombardo find it encouraging to contribute to an article, only for you to remove it hours later?

As for table accessibility, did you even read my comment or clicked on the link I provided? Or heck, did you even read the policy you are talking about? Because MOS:DTAB literally includes a link on how to make tables that show the exact thing you've done as an example of what not to do. I've also linked to the exact diffs that introduced the changes... Clearly you haven't bothered actually checking any of it. The guidelines clearly show not to combine cells for tables like those (otherwise, the example would have included a "good example" with a single cell with a checkmark). And yes, of course people are going to point out accessibility issues when you make edits that have no benefit but negatively affect the accessibility. As has been pointed out many, many times before; the inclusion size of these templates is absolutely not an issue. The created accessibility issues absolutely are. YannickFran (talk) 22:39, 15 October 2024 (UTC)Reply

Okay. I agree in that you have a point regarding Android's versioning, I have re-instated the separated tables. I have also re-instated the version tables on the iOS article, until these sections have had a chance to be converted to prose. They might just have to be converted to regular tables which is pretty easy. I did not realize that my removing of content could discourage editors like Max from contributing further, I just thought that they were copied from Apple's release notes based on how similar they read. My bad on that front.

But I still vehemently disagree that I intentionally go against the MOS at any point; my intent is to always follow it, the only thing I was trying to say was that the Manual of Style is a guideline document, it's not inherently something that can be directly enforced like a country's laws can, but perhaps my disagreements with it were unfounded. - Evelyn Harthbrooke (leave a message · contributions) 23:16, 15 October 2024 (UTC)Reply

Also, please see my below comment, it directly relates to your last paragraph. - Evelyn Harthbrooke (leave a message · contributions) 23:17, 15 October 2024 (UTC)Reply

You can't say my changes bring no benefits to the tables when they literally do. They significantly increase maintainability and reduce duplication of the template calls. These templates are only going to get more and more complex and complicated with each new iPhone launch. And they make no discernable differences in terms of accessibility, including with screen readers as I tested VoiceOver with the table and it's fine. You reverted my edits yet again without even replying here...this is why I take issue with your editing habits. Because yet again, you reinstated your vision of the table without finishing a conversation we were having. You criticized me not that long ago for not partaking in a conversation, and now you're doing the same, which is in my view, hypocrisy. - Evelyn Harthbrooke (leave a message · contributions) 18:36, 16 October 2024 (UTC)Reply

With the tables as they where, maintaining them was as simple as mindlessly copy-pasting cells at the end of each row. Having to go through various cells to check and make sure whether or not the colspan or rowspan has to be updated is objectively a much more involved task. The templates weren't complex, but you sure made them so by adding random col and row spans. I haven't reverted your changes, though. I've updated it with a compromise. Every structural change to these templates over the last 1,5 year has been made to address your concerns about their inclusion size (which, by the way, still really isn't a concern). But the compromises have come - every time - from other people, and once they are made, once you've been given a hand, you demand an arm. Besides, we weren't having a conversation about these tables anyways, because - again - we wouldn't be on this talk page if that was the case.

you reinstated your vision of the table without finishing a conversation we were having I literally didn't. I literally took the changes you've made, took what could work, and altered them contrary to "my vision". Unlike you, I don't blindly revert everything. Also... seriously? Do you really not get how hypocritical this is?

And for the record, in regards to your comment made in this edit summary, the accessibility issue here isn't screen readers. It is, as I've stated before, The lack of lines create a disconnect between the versions in the header and the table's content. These changes are an issue for people with dyslexia and other similar disabilities because merging every possible cell like this creates a disconnect between the header cells and the body cells, there is no clear through line to where a column starts and ends and it is just downright messy. It's why the approach from the iPhone and iPod tables doesn't work on the iPad table. Accessibility isn't just "does it work on a screen reader?". YannickFran (talk) 20:20, 16 October 2024 (UTC)Reply

Do you really not get how hypocritical this is? No, I do not understand how it's hypocritical. I reverted it, because while it was done in good faith, it doesn't bring any benefits, aside from your claim that it puts the devices in release order, but I imagine that that was not the goal of the template. It was organized to be by lineup, not release order, to likely avoid unnecessary wikitable duplication. - Evelyn Harthbrooke (leave a message · contributions) 20:25, 16 October 2024 (UTC)Reply

It should be additionally noted, that my change to the template to say "Supported" vs "Not supported", is literally one of two ways you can handle the template. a) by having an individual call for every single cell, or b) using text in place of icons. I prefer the latter, because a) it's more obvious and relates more to the template in question and b) it reduces the number of template calls, thereby reducing the amount of times someone has to insert them into the table. Its also much easier to work with that way as only the colspan and rowspan parameters have to be adjusted if the need arises, which is a simple increment of a number. I do not understand nor see how that is bad for maintainability, when it isn't. It's literally in the guidelines that you yourself linked to, in the second table under "Good uses of color". You have no grounds to revert my changes to the iPod touch template, especially because of that. - Evelyn Harthbrooke (leave a message · contributions) 18:53, 16 October 2024 (UTC)Reply

It should be noted as well that the API levels are still listed in Android version history's overview table, so they aren't completely gone. They just arguably do not need to be in the tables. And I genuinely believe that my changes to the templates do not fall victim to the color guidelines: the color guidelines are for only providing a color and not having anything to indicate its intent; that is what it is trying to show, that there should be something above its color to reflect its intent. But when you have over 100 cells, and an astronomical number of template calls, that becomes an issue because then the balance has to be "do we have one single checkmark for every single cell" or "do we save on resource costs by merging cells together". I vote for the latter, because these templates have no reason to have individual checkmarks and x's for every single cell. Admittedly, I missed the IP editor merging the cells, as it lacked an edit summary. But despite an attempt being made in the past, I firmly believe it was a misinterpretation of Wikipedia's accessibility guidelines. - Evelyn Harthbrooke (leave a message · contributions) 22:31, 15 October 2024 (UTC)Reply