User talk:Lentower
This is Lentower's talk page, where you can send him messages and comments. |
|
NOTICEs Please Read
[edit]Notices: |
---|
If you wish to discuss the content of an article or its talk page, please do so on that article's own talk page. That's one of the things that they are there for. And everyone concerned about the page gets to benefit! |
Please use my talk page for Wikipedia matters ONLY. Thank You! |
Please use email for non-Wikipedia matters. Thank You! |
I dislike disjointed conversations, where one has to switch between pages as each participant writes. |
Sxip Shirey
[edit]Hi, thanks for your work on Sxip Shirey. I created that article a year ago and it's been underloved since, so I'm glad someone else has taken an interest! --R27182818 (talk) 14:44, 12 June 2008 (UTC)
- Most welcome. I may keep chipping away at it. There are some New York Times refs that can be added, chase the ones down Sxip quotes on his web sight, and see what Google News turns up. Like to get it from Stub to Start Class. Help out if you can. Lentower (talk) 23:08, 21 June 2008 (UTC)
MBTABus template
[edit]Just noticed your edits to the Porter article. I appreciate all the copyedits you've been doing, but I'm iffy on the use of the MBTABus template because it ends up generating lots of redlinks.
Some special bus routes do have links: trolleybuses, (most) key routes, and some of the geographically divided ones like the North Shore routes. But most of the generic local routes don't have pages, nor do I see them as a likelihood anytime soon. (Additionally, many of the numbers redirect correctly but confusingly to a one-line entry on the trolley service they replaced). Is it worthwhile to keep using the template to generate long-term redlinks in exchange for the valid links that are created? If so, is there a way to provide anchors on the main bus route list so that we can create redirects so nothing redlinks?
(Feel free to reply here; I'll watchlist your talk page.)
Cheers! Pi.1415926535 (talk) 21:14, 8 June 2012 (UTC)
- I'll reply here, as you started the discussion here. But I would have raised the point at Talk:Porter (MBTA station) or Template talk:MBTABus. Discussions about articles or templates belong on their talk pages.
- Pi.1415926535 has found the related discussion at Template talk:MBTABus. See further discussion there.
- Some of the info about MBTA bus routes may be nested in articles without a REDIRECT to the bus route's section.
- You may beat me on figuring out how to add anchors to List of MBTA bus routes. But does it help the reader alot? The info in that list duplicates the description in the artciles.
- Like many areas of Wikipedia, it's been a while since anyone has gone through and try to give this information a consistent layout that benefits the readers. I've only looked at a few of the MBTA bus, subway, commuter rail, and other articles so far. The treatment of the bus routes has varied significantly.
- I'll get rid of the redlinks for now in Porter (MBTA station). Lentower (talk) 15:42, 9 June 2012 (UTC)
Location maps in MBTA infoboxes
[edit]I've noticed you've been changing the width of locator maps in MBTA infoboxes to 400 pixels wide. Are you sure about that? Everything else in the infoboxes is generally designed for 300px wide, and 400px adds a ton of whitespace. It also makes it very difficult to use images on the left-hand column. (My screen is a fairly modern but smaller-end 1366x768, and the 400px infobox takes up almost 40% of the article width).
I reverted Back Bay for now - I'm going to be doing some major rewrites and lengthening on it soon, and it's going to need the narrower infobox to accommodate the left-hand pictures - but I wanted to get your input before I reverted any others. Pi.1415926535 (talk) 02:54, 21 June 2012 (UTC)
(Correction: an IP reverted Back Bay before I did.) Pi.1415926535 (talk) 02:55, 21 June 2012 (UTC)
- I've been changing the map in Two Line Infoboxes to 370px, and the Amtrak Infoboxes to 400px. They Info boxes are displaying at a bit more than that width in the browsers I'm using, so the map have a lot of white space on the left of the map. I'll change them back, and look into it when I have time. Lentower (talk) 03:23, 21 June 2012 (UTC)
- Yeah, width parameters in infoboxes do weird things. Percentage widths may be a workaround, but there's some weird bugs with triggering scrollbars. I'll watchlist your talk page; let me know if/when you play around more with this. Cheers! Pi.1415926535 (talk) 03:46, 21 June 2012 (UTC)
HHVM and editing tools
[edit]I noticed that some of your edits have a tag "HHVM", but following the link led to a technical in B article about a virtual machine implementation. It look like you (and other editors) are using some sort of semi-automated editing tool to improve editing efficiency. Could you tell me the name of the tool(s) you use, and possibly some pointers to a good overview and introduction to them? Thanks! Reify-tech (talk) 20:18, 10 October 2014 (UTC)
- This only assist editing, by making interactions with Wikipedai faster. HHVM isin Beta. It's a server efficiency improvement: https://www.mediawiki.org/wiki/HHVM/About. Does seem faster. I look at the Beta trials once a month or so, and try out what seems useful. Btw, Hovercards and pop-ups don't co-exist well. — Lentower (talk) 23:48, 10 October 2014 (UTC)
A new reference tool
[edit]Hello Books & Bytes subscribers. There is a new Visual Editor reference feature in development called Citoid. It is designed to "auto-fill" references using a URL or DOI. We would really appreciate you testing whether TWL partners' references work in Citoid. Sharing your results will help the developers fix bugs and improve the system. If you have a few minutes, please visit the testing page for simple instructions on how to try this new tool. Regards, MediaWiki message delivery (talk) 18:47, 10 April 2015 (UTC)
Switch to 30em, very minor edits
[edit]This remains here, in case i ever find the time to write the essay on the wisdom of not overdoing format markup on Wikipedia.
Hi, you've been doing some "References: switch to 30em recommended on Template page". This isn't wrong, but it's so minor as to make one wonder why it should be worth chasing down unless someone has chosen a ridiculously large value as a joke. It is just about worth fixing while one is doing something else. And it's only a suggestion, not a requirement. Just my twopence worth. All the best, Chiswick Chap (talk) 15:03, 4 May 2017 (UTC)
- I do this as part of scanning for easy to fix stuff as I have an ear on my television (using WP's Android App, which isn't great for complicated extensive edits.)
- To give each user a consistent presentation of {{Reflist|...}} for their browser's characteristics determining width.
- I suspect (having had discussions with those who have reverted this change), that editors choose different values to make {{Reflist|not30em}} look consistent on the browser they use (a source of a lot of over formatting on Wikipedia). Few editors use more than one browser; not having wide experience with current browsers, let alone many of those since Tim released the first one in 1990 (which I used shortly after it reached MIT). :
- I appreciate any comments you have HERE. Thanks — Lentower (talk) 23:59, 6 May 2017 (UTC)
- I agree with Lentower that 30em is a good general default, which scales appropriately with the typefont size on a given display. Many editors habitually work with a single display setup and software, and unconsciously tend to over-optimize page layout for whatever configuration they happen to be using at that time. I use displays ranging from cellphone-sized to 30-inch "cinema-sized", and find obsolete layout specifications like the deprecated "perrow=4" in the Gallery tag (H:GT) to be very annoying. The same goes for overspecifying image size and overriding user preferences, by using a fixed "px" specification (see WP:IMAGESIZE). Editors need to be more aware that readers and other editors use a wide range of displays, and some are also visually-impaired in various ways and may rely on custom-configured setups. The worldwide span of variety in displays is likely to increase in the future. The time when some designers believed that "everybody" used 480 by 640 pixels is long past. Reify-tech (talk) 01:24, 7 May 2017 (UTC)
Column template for See also section
[edit]This remains here, in case i ever find the time to write the essay on the wisdom of not overdoing format markup on Wikipedia. Copied from Talk:Street_performance#column_template_to_use_for_See_also_section
I just reverted back, preserving you wikilink fix. Your change of "|gap=4em}}" produces even worse formatting on the Android App & some other browsers.
Questions:
- Why did you NOT preserve my edit of {{Portal|Theatre}} on your last revert?
- Why, granted your choice of column template produces broken formatting in several apps & browsers, do you keep reverting back to it?
- As editors, shouldn't we choose best practice, that work for all of Wikipedia's readers?
Discussion:
- The {{div col}} templates also automatically break columns to roughly equal lengths, on those browsers that support it without broken formatting. So no need to move a template like {{col-break}} around, when items are added or removed.
- Like many newer templates, {{div col}} does a lot of "best practice" formatting that works across all browsers/apps.
— Lentower (talk) 17:16, 24 July 2017 (UTC)
Hiatus
[edit]Chaheel_Riens: I just got news that my Godson was killed in a train accident. Supporting his father & brother, and the rest of my family comes before Wikipedia editing. I'll get back to the discussion we are having when I can. Please acknowledge reading this. Thanks for understanding. — Lentower (talk) 21:50, 1 April 2020 (UTC)
- Acknowledged - WP:DEADLINE. Chaheel Riens (talk) 19:54, 3 April 2020 (UTC)
Desktop improvements prototype
[edit]Hello, Lentower!
Exploration of the Unknown | ||
I hereby award you the Exploration of the Unknown award! You are being recognized for your courage and willingness to test a feature, gadget, or tool in development and for the constructive feedback you provided. |
Thanks for taking the time to participate in the user feedback round for our desktop improvements prototype. This feedback is super valuable to us and is currently being used to determine our next steps. We have published a report gathering the main takeaways from the feedback and highlighting the changes we’ll make based on this feedback. Please take a look and give us your thoughts on the talk page of the report. To learn more about the project overall and the other features we’re planning on building in the future, check out the main project page.
SGrabarczuk (WMF) (talk) 00:28, 9 April 2020 (UTC)
Disambiguation pages
[edit]You made a change to Colophon. There was absolutely nothing wrong with it before you changed it. Some disambiguation page guidelines are subject to interpretation. Edits that change a page's style because you have a slightly different interpretation of guidelines, but on the whole represent no improvement, just serve to annoy other editors. If you wish to challenge, or expand on the guidelines, or make them less easy to interpret in several ways, then please do so. In this particular case, not numbering and therefore ordering See also items is the result of previous consensus. Thank you, Shhhnotsoloud (talk) 10:22, 13 February 2021 (UTC).
- Shhhnotsoloud (talk · contribs): I breaking my points up, so you can reply to them individually, if you wish.
- Please link to the previous consensuses you mention. I've yet to see those discussions. (For what its worth, I've had a named account for 4 more years than you have, and was editing anonymously for several years before that.) — Lentower (talk) 18:23, 13 February 2021 (UTC)
- I disagree. It improves the style of the page. Particularly user readability. Having all WP articles links in Disambig page first, then links to related Disambig pages & related searches is better for the user. — Lentower (talk) 18:23, 13 February 2021 (UTC)
- I have been sorting Disambig See also sections for a long time. You are the first editor to revert. — Lentower (talk) 18:23, 13 February 2021 (UTC)
- Your other edit on this page was first rate https://en.wikipedia.org/w/index.php?title=Colophon&type=revision&diff=973505402&oldid=872495047 I note you added {{srt}} at that time (a fact I just checked). Which makes me wonder if our disagreement has to do with me changing your work? — Lentower (talk) 18:23, 13 February 2021 (UTC)
- Your emotional state ("just serve to annoy other editors") should not enter into reasoning with another editor. Editing decisions should be based on what best for the user guided by Wikipedia policies and guidelines. Not any editor's personal preferences. — Lentower (talk) 18:23, 13 February 2021 (UTC)
- Do you have another argument based on Wikipedia policies and guidelines? — Lentower (talk) 18:23, 13 February 2021 (UTC)
-
- Your ping didn't work. I agree entirely that "Editing decisions should be based on what best for the user guided by Wikipedia policies and guidelines. Not any editor's personal preferences." but the reverse happened here: your edit was based on personal preference based on your interpretation of guidelines. Please see Wikipedia talk:Manual of Style/Disambiguation pages/Archive 42#Canned Search, and this edit and a couple before them. Shhhnotsoloud (talk) 08:56, 16 February 2021 (UTC)
-
HOWTOSD
[edit]I guess you figured out I meant WP:HOWTOSD (all caps). Yes, 80 would be a sensible figure but...
For the background to this 'debate', see Wikipedia talk:Short description/Archive 9#Length – 40 or 90 characters??. --John Maynard Friedman (talk) 15:49, 26 December 2021 (UTC)
- John Maynard Friedman: Thanks. It got me to reread WP:SHORTDES. The last I read it, the count was still 80ish.
- Fixing the iPhone app to meet the guideline at the time, would have been better than cutting the length in half, but the decision is made.
- As my fingers can fumble some, I test links I type, before posting them. — Lentower (talk) 16:26, 26 December 2021 (UTC)
Annotated See Alsos
[edit]Ref your edit to Letterpress printing, it occurs to me that you may have missed these:
- {{anli}} (aka {{annotated link}}, appends the short description of the listed article
- {{subst:AnnotatedListOfLinks| etc etc}} to convert a long See Also to use ALs.
saves having to reinvent the wheel in every article that includes it in the See Also list. (but... Wikipedia talk:Short description/Archive 9#Length – 40 or 90 characters?? may mean that some further description needs appending.)--John Maynard Friedman (talk) 14:52, 15 April 2022 (UTC)
- John Maynard Friedman: Thanks. I was aware of {{annotated link}}, but its tedious to use. There are too many cases where the short description:
- needs creation;
- needs work;
- isn't quite right for the host article.
- SD editing takes real thought, more time than rote cleanup.
- I'll give {{subst:AnnotatedListOfLinks| etc etc}} a try. Thanks again — Lentower (talk) 19:11, 15 April 2022 (UTC)
- John Maynard Friedman:
- saves some time.
- know of a template or tool, that would convert punctuation after the "* Wikilink" to the <space><dash><space> {{annotated link}} outputs?
- you might skim thru User:Lentower/Templates - collected thru 15 years of editing.
- — Lentower (talk) 19:58, 15 April 2022 (UTC)
- John Maynard Friedman:
- No such thing a free lunch, of course. {{AnnotatedListOfLinks}} just applies the {{anli}} to every line in the list unless it already has a local description. Consequently, all your concerns still stand. In letterpress printing, for example, precisely zero of the articles listed had SDs before I started. One was a redirect (which can have its own SD if really needed, put it after the #Redirect line) but for no good reason – I replaced it and of course the target article had no SD either. But you probably don't share my obsession with making Wikipedia a resource for information discovery (in the library sense, not the legal sense), for serendipity. So I see missing SDs as an opportunity, not a hassle. Your mileage may vary. [On your third point, I would append some additional text or in extremis not use anli on that item.]
- Do you mean {{snd}}? (spaced endash)
- I have also collected various useful goodies, see my home page. --John Maynard Friedman (talk) 20:08, 15 April 2022 (UTC)
- I have limited time to edit WP, so I do missing SDs as I can. One of the many endless tasks WP needs done.
- Yes an en dash, not an em dash.
- Thanks — Lentower (talk) 21:12, 15 April 2022 (UTC)
- The nice feature of {{snd}} over simple {{ndash}} is that it prepends a non-breaking space so that you never get a new line beginning with a dash. --John Maynard Friedman (talk) 21:16, 15 April 2022 (UTC)
- Understood from the Template page. — Lentower (talk) 21:18, 15 April 2022 (UTC)
- My initial reaction was surprise that you hadn't seen it before but of course, unless you are a fan of Robert Bringhurst,[1] you probably follow the antique US convention of
text—text
and don't routinely use spaced endashes in running texttext – text
like civilised people :-D --John Maynard Friedman (talk) 22:06, 15 April 2022 (UTC)- I've been aware of " – " for 60 years & its use by {{annotated link}} , but not the template {{snd}} until you mentioned it.
- Please let this be the end of this exchange.
- I've extremely busy right now.
- Thanks! — Lentower (talk) 01:45, 17 April 2022 (UTC)
- My initial reaction was surprise that you hadn't seen it before but of course, unless you are a fan of Robert Bringhurst,[1] you probably follow the antique US convention of
- Understood from the Template page. — Lentower (talk) 21:18, 15 April 2022 (UTC)
- The nice feature of {{snd}} over simple {{ndash}} is that it prepends a non-breaking space so that you never get a new line beginning with a dash. --John Maynard Friedman (talk) 21:16, 15 April 2022 (UTC)
References
- ^ Bringhurst, Robert (2004). The elements of typographic style (third ed.). Hartley & Marks, Publishers. p. 80. ISBN 978-0-88179-206-5. Retrieved 10 November 2020.
[The em dash] belongs to the padded and corseted aesthetic of Victorian typography.
'see also' section changes
[edit]Hi Lentower. I’ve reverted a couple of your transcluded-short-description annotation of "see also" sections. The annotations much (most?) of the time don’t really seem that helpful (even compared to no annotation at all, but certainly compared to some expressly written annotation specific to the page). Often see also sections also already have stuff that is somewhat irrelevant or redundant and should probably be thinned out. (I generally see "See Also" sections as a kind of todo list, with an eventual goal of nearly/entirely eliminating it as the article develops). Anyway, I’m not trying to step on your toes, but I’m not sure it’s all that useful to try to convert all of the see also sections to automatically 'annotated' versions.
Separately, I don’t understand the point of adding 'mathematics portal' buttons to the see also sections of mathematics related articles. These seem pretty well irrelevant to the pages. Are you hoping that all of the thousands of mathematics related articles have this portal link? Or is there a particular reason you are putting it on the articles you have? If you want this to be a general thing, maybe it should be discussed by the math wikiproject. –jacobolus (t) 02:52, 2 April 2023 (UTC)
As a concrete example, Cotes's spiral (which you converted to an annotated see also section but I did not revert) has 2/4 annotations which are pretty much entirely useless: Bertrand's theorem – Physics theorem; Newton's theorem of revolving orbits – Theorem in classical mechanics.
These annotations provide zero useful information beyond what readers already on this page can already infer from the titles. The other two annotations are at least trying to give an idea of what they are about: Hyperbolic spiral – Spiral asymptotic to a line; Archimedean spiral – Spiral with constant distance from itself.
But are also not specific enough to really give readers of the Cotes's spiral page an idea about their relevance. The Archimedean spiral annotation is also misleading/wrong under most obvious interpretations. These other spirals are already listed on the "Spirals, curves and helices" navbox at the bottom of the page, and I’m not entirely sure they are helping anyone by being in the see also section. What would be helpful in my opinion would be some explicit comparison between Cotes's spiral vs. other kinds of spirals explaining when the various kinds would be appropriate, in the body of the article, with the compared spirals then removed from 'see also'. The two orbit-related theorems (Newton's and Bertrand's) should ideally be described in the article if they are relevant, and then removed from the 'see also' section. –jacobolus (t) 03:37, 2 April 2023 (UTC)