User talk:Chinissai

This user may have left Wikipedia. Chinissai has not edited Wikipedia since July 2017. As a result, any requests made here may not receive a response. If you are seeking assistance, you may need to approach someone else.

Daniel Briere

Sorry about that I must have clicked the wrong button on my view. It was showing me that you were doing the opposite of what you were doing. I must have hit undo instead of diff. -Djsasso (talk) 15:25, 16 May 2008 (UTC)[reply]

NY Route maps

So much thanks for the help. Keep it up, we could (so could I) use a lot more of them! Mitch32^{(Wikipedia's worst Reform Luddite.)} 04:28, 1 September 2013 (UTC)[reply]

Howdy. Can I ask of a favor, can you get started on some maps for the parkways and Interstates please? There are several I'd like to GAN but need maps. Mitch32^{(Wikipedia's worst Reform Luddite.)} 22:34, 13 September 2013 (UTC)[reply]

Which interstates are you thinking about? All the interstates left in New York are either short or historical. Chinissai (talk) 01:55, 14 September 2013 (UTC)[reply]

Every single one. I'm getting there on the rest. I could urgently use maps for the Northern State Parkway, Sunken Meadow State Parkway, Sprain Brook Parkway, and if you can get the data, Central Westchester Parkway and Playland Parkway.Mitch32^{(Wikipedia's worst Reform Luddite.)} 02:22, 14 September 2013 (UTC)[reply]

When you get the chance, more you can add the better. Mitch32^{(Wikipedia's worst Reform Luddite.)} 22:32, 15 September 2013 (UTC)[reply]

Howdy. I appreciate the help reverting DJV11181988 on those senseless changes, just too many for me to handle. Anyway, when you get the chances, could you knock off the rest of NY's KMLs for decommissioned stuff and maps that you can do at least? Mitch32^{(Any fool can make a rule, And any fool will mind it.)} 04:59, 9 June 2014 (UTC)[reply]

No problem. Are you talking about historical routes? I am not sure if I have GIS data on those, and tracing manually on Google Maps is not something I would like to do. If you know a proper, better way to do that, I would like to know. Also, I will be traveling for the next few weeks so no more maps will be produced during this time. Chinissai (talk) 12:43, 9 June 2014 (UTC)[reply]

Welcome, roadfan!

Hello, Chinissai, and welcome to Wikipedia! Thank you for your contributions. I hope you like this place and decide to stay. Here are some pages that you might find helpful:

Please sign your name on talk pages using four tildes (~~~~); this will automatically produce your username and the date. If you need help, check out Wikipedia:Questions, ask me on my talk page, or place {{helpme}} on your talk page and ask your question there.

If you are interested, there is already a community of users who are roadfans or who edit articles about roads, just like you! Stop by any of these WikiProjects—WP:HWY (worldwide), WP:AURD (Australia), WP:CRWP (Canada), WP:INR (India), WP:UKRD (United Kingdom), or WP:USRD (United States)—and contribute. If your interest is in roads in the United States, there is an excellent new user's guide. There is a wealth of information and resources for creating a great article. If you have questions about any of these WikiProjects, you can ask on each project's talk page, or you can ask me!

If you like communicating through IRC, feel free to ask questions at #wikipedia-en-roads ^connect as well. Here, there are several editors who are willing to answer your questions. For more information, see WP:HWY/IRC.

Again, welcome! T C N7JM 06:04, 1 September 2013 (UTC)[reply]

Interstate 26 in South Carolina map

Wow, you actually made a map for Interstate 26 in South Carolina. I didn't think anybody was going to do that. Thanks. ---------User:DanTD (talk) 01:18, 2 September 2013 (UTC)[reply]

No problem. Once I got a few maps going the task was not that difficult. Chinissai (talk) 01:42, 2 September 2013 (UTC)[reply]

Route maps

Hello! I'm enjoying seeing the new route maps you're putting up for state highways. (I'm looking in New Hampshire at the moment.) They will be a big help for readers of the articles. One question: would it be possible to display the maps in something other than straight lat/long? At the moment, it appears that the longitude values are given the same distances as the latitude values, which makes maps appear squashed in the north-south direction. A different projection (state plane or UTM, for example) would solve the problem. Anyway, I appreciate all the work you're putting into the maps! --Ken Gallager (talk) 13:12, 5 September 2013 (UTC)[reply]

Thanks for letting me know about the projections. I myself wondered why the maps looked a bit fat. I am still quite new to QGIS and I learned more from you. I updated most of my maps to use the UTM 18N projection. (I also do New York maps so that projection is "universal" for the moment.) The projection thing should really be in the tutorial. Chinissai (talk) 12:49, 7 September 2013 (UTC)[reply]

Maps

I said it before on Commons, but holy crap your maps are awesome. If you run out of ideas, there is a category for the most-needed maps here. In addition, there is a USRD map request page. There is some crossover between the two. Thanks for your work! –Fredddie ™ 14:40, 21 September 2013 (UTC)[reply]

Christopher Thompson User talk:Christopher Thompson How do I make my own map to show it on pages — Preceding unsigned comment added by Christopher Thompson (talk • contribs) 19:13, 19 October 2017 (UTC)[reply]

Alt text for infobox maps

One of the best pieces of advice I ever received for alternative text was related to the infobox maps. Basically, it should give a brief description of where the highway is, not just say that it is a map of the highway. For example, "M-185 is a highway that runs around Mackinac Island in the Straits of Mackinac between Michigan's Upper and Lower peninsulas" while the caption says, "Map of the Straits of Mackinac with M-185 highlighted in red". (Past advice for alt text was to describe the image as if you were telling someone over the phone about it; the better advice is that the alt text should describe what the image is attempting to add to the article, or use a generic "photograph" or "map" if the caption does so already.) Imzadi 1979 → 22:53, 11 July 2014 (UTC)[reply]

Roger that; however, I don't believe that the alt attribute always needs to fully describe the image if that description can be found elsewhere. This is especially true for road articles as the Route Description section already handles that. (See Alt attribute and WP:ALT.) The Route Description section should already help the visually impaired, leaving with the case where the image itself cannot be rendered. In that case, I think an identification of the image suffices. My only worry was that not having map_alt would invalidate the HTML, but since it seems that Mediawiki's default attribute value is alt="" to validate the HTML, I am happy to ignore the tag and let somebody else fill it in in the way you want it, as making maps is already some work. Chinissai (talk) 00:40, 12 July 2014 (UTC)[reply]

Except that would force the visually impaired to listen through paragraphs of prose later in the article when a single sentence in the |map_alt= would give the condensed summary up front and fulfill the purpose of describing why we bothered to include a map in the first place. Imzadi 1979 → 00:50, 12 July 2014 (UTC)[reply]

I reviewed a few alt attributes for existing articles and found that they paraphrase the lead paragraph (or even first few sentences) at best. I am still not convinced why redundancy is necessary. Chinissai (talk) 15:30, 12 July 2014 (UTC)[reply]

USRD watchlist

In lieu of not having Dispenser's project watchlist, I created a mega RC page at Special:RecentChangesLinked/User:Fredddie/Watchlist. –Fredddie ™ 22:42, 11 September 2014 (UTC)[reply]

Hey, thanks a lot for creating this and letting me know. That must have been quite some work for you. I also discovered your RC on the Talk namespace. I wish all of these namespaces just coexist in one page, but I don't know if you or MediaWiki will hate me for that, so I will live with what we have. I wanted to implement a replacement of the watchlist (open-sourced, since that seems to be the issue?), but I do not have enough resources to do that. (I know how to program, but I don't know any hooks for querying changes.) Chinissai (talk) 01:32, 13 September 2014 (UTC)[reply]

The talk page RC actually didn't work with all the Category talk pages, so I removed them. I agree with your sentiments about having them all in one spot, though. –Fredddie ™ 01:36, 13 September 2014 (UTC)[reply]

IP Whack-a-mole

What do you think of Special:Contributions/108.49.190.49? –Fredddie ™ 02:41, 9 October 2014 (UTC)[reply]

Well, I can tell you that both 108.49.190.49 (talk · contribs · WHOIS) and 50.205.78.134 (talk · contribs · WHOIS) are from Framingham, MA. One is Verizon FiOS and other is Comcast. They do have similar editing pattern, but the first one focuses on infobox junctions more recently, although it caused some trouble with RJL in the past. Chinissai (talk) 07:54, 9 October 2014 (UTC)[reply]

Alewife Brook Parkway map

Thank you for the improved map of ABP. I believe it needs a slight tweak, as a section of Concord Avenue is highlighted in red, in contradiction to the statement in the article that "The southern terminus of the parkway is the westernmost of the two Fresh Pond rotaries" (emphasis added). Best wishes, Hertz1888 (talk) 11:29, 30 July 2015 (UTC)[reply]

Thanks for letting me know. I used data from the census bureau, which sometimes can be off. It looks like I need to research a bit more about which one is actually correct. (If you are certain the description is correct, can you point me out to a verifiable source?) At any rate, I can't work on maps for the next several days. Chinissai (talk) 10:47, 31 July 2015 (UTC)[reply]

I can find no evidence that Concord Avenue changes name in its approximately 300 yards' concurrency with Route 16 et al. Per the Cambridge property database, 321, at the western rotary, is the highest-numbered address on ABP; between the rotaries, properties such as nos. 527 and 545 have Concord Avenue addresses. Though I doubt that the city assessors would have this wrong, I will be interested to see what you may find. Hertz1888 (talk) 22:05, 1 August 2015 (UTC)[reply]

[1] indicates that the Parkway ends just north of the westernmost rotary. If segments in the census data agree with this atlas (i.e., the extra segments include the rotary), I will update the map shortly. Chinissai (talk) 20:12, 5 August 2015 (UTC)[reply]

Interstate 87

Do you think the article on I 87 is ready to be nominated for GA? Everything seems referenced. I did very little work on it so I would not be the one to nominate it. PointsofNoReturn (talk) 02:13, 1 August 2015 (UTC)[reply]

I only worked on the exit list, so I am not sure about other sections. The article, like several others, is not stable yet because there have been erroneous edits I have to revert. This might cause it not to pass the GAN. Chinissai (talk) 11:07, 1 August 2015 (UTC)[reply]

Fair enough. I might try anyway since it looks good and might be worth a try. I guess we'll see what happens. Would you like to nominate since you did most of the work? PointsofNoReturn (talk) 19:27, 2 August 2015 (UTC)[reply]

USRD banner

The |needs-kml= parameter has been superseded in normal usage. The banner now checks to see if a KML exists, and based on that, it will automatically display whether or not one is present. We only need to use the parameter to override that check for articles that do not, and will not, have a KML, something like Michigan State Trunkline Highway System or Michigan left. For talk pages of "regular articles" that have the parameter present, it's sufficient to remove |needs-kml=yes and just save the page, or just purge the page. Imzadi 1979 → 02:44, 7 November 2015 (UTC)[reply]

A barnstar for you!

	The Original Barnstar
	Thanks for the KMLs. Rs chen 7754 21:09, 7 November 2015 (UTC)[reply]

Seconded. I couldn't help but notice the number at this page was dropping a lot faster than I had the ability to make it. Can't thank you enough for your help. T C N7JM 21:07, 8 November 2015 (UTC)[reply]

KML question

Do you plan on taking out the rest of Colorado? If so, I'll just start on Florida. T C N7JM 18:21, 20 November 2015 (UTC)[reply]

I am doing as much of CO as I can, but probably not at a speed as fast as in previous weeks. I am not planning on tackling FL so you can take that. Chinissai (talk) 18:26, 20 November 2015 (UTC)[reply]

ArbCom elections are now open!

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 13:52, 24 November 2015 (UTC)[reply]

Location refs in RJLs

Unless the locations are contentious for some reason, we've traditionally left that column uncited. In fact, I don't think the location column is cited in any of the 25 featured articles on Michigan highways and roadways. We have cited the milepost column on the basis that statistics like mileages should be cited, and since the MPs are cited to a source that gives the location and the intersecting roadway, it's been a long-time practice that the other columns do not need to be explicitly cited, unless there's some controversy over the contents of that column. I fail to see where there's any controversy on I-91, so the reference is unnecessary. Imzadi 1979 → 23:08, 3 December 2015 (UTC)[reply]

The same could not be said for every other state. If you look at Vermont's mileposts, you will see there is no location listed along with the mileposts. I am working on a reference for those locations now. I have seen edit wars over the location column, so why not have a reliable reference to prevent and perhaps readily resolve such disputes? If a reference is not there in a featured article, it does not mean it should not be in other "inferior" articles. Chinissai (talk) 23:18, 3 December 2015 (UTC)[reply]

I disagree though, and in years of working on these, unless there's some been weird controversy, it hasn't been deemed necessary to cite that column. If it's not necessary for "our finest work", then it's not needed on "interior" (your word) articles. It's also the start toward citation creep where every column (except the km column, and only because it's a mathematical derivative) gets a citation. Imzadi 1979 → 23:32, 3 December 2015 (UTC)[reply]

IRC

WP:HWY/IRC has the details, but a bunch of us chat in a channel on IRC to facilitate editing. Of course, we take any big decisions to the appropriate talk page, but we've found that it helps to hammer through the initial thoughts about a new idea on IRC before taking a second draft on-wiki... Also, it's just faster some times when debugging stuff. Imzadi 1979 → 05:29, 18 April 2016 (UTC)[reply]

Infobox road sandbox

Since you're working on it, I have some questions:

Were you planning on using the road data modules for populating infobox data?
If so, consider adding the ability to override the Jct shields for the infobox (when we switched to the modules, I switched every state to generic shields even if they use state-name shields [see Missouri] because of legibility at 20 pixels)

Add 'names' to the base data module, which is now the function of Template:Infobox road/name/USA. Also the ability to override (U.S. Highway vs U.S. Route)
Could you add the ability to embed the infobox in another? (see Template:Infobox road/testcases#Embedding)

I'm sure I'll have some more, but those are the things I'd like to see the most. –Fredddie ™ 21:36, 1 May 2016 (UTC)[reply]

@Fredddie: Thanks for touching base.

1. Yes, the goal is to use shared road data modules as much as possible. We should do away with modules in Infobox road that are duplicate of those in Road data. In the browse section, the live version is already using Road data modules for shields and abbrs.

I actually began with using shield definitions from road data, only to find that the "main shields" could differ from those appearing in jct. I guess a shieldmain field should be used, to mimic the template name, with perhaps a fallback to shield. We will need to figure out how to deal with banners. This will be easier if we don't need bannermain.
I already added most names to my local road data modules that use inheritance, as in Module:Road data/strings/USA. Overriding will work as expected. An example for Arkansas is available. The sandbox now looks in the road data module first and falls back to the name template. A notable example is US 41 in Wisconsin, where the name in road data differs from the template:

So, I am waiting for a green light on module inheritance, and then I can simply paste what I have. I would prefer not to add names to the live modules all over again when I already did that locally.

2. Added simple support for one nested infobox (see the testcases page). The skew seems to be Infobox's fault. We can definitely support a sequence of nested infoboxes and recursively nested infoboxes. Just curious, what's a use case for this?

Chinissai (talk) 22:57, 1 May 2016 (UTC)[reply]

Use case would be the Brooklyn–Battery Tunnel article in the testcases and also just being a good neighbor to other projects. –Fredddie ™ 23:07, 1 May 2016 (UTC)[reply]

I see you're working on length conversions now. Evad37 (or maybe it was Nbound) suggested a while back that when we imperialists convert one-half mile, it's preferable to convert to meters instead of kilometers. 1⁄2 mile (800 m) > 1⁄2 mile (0.80 km). Perhaps when the conversion is under 1 km, it should default to meters.

0.25 miles (400 m)

1⁄3 mile (540 m)

0.5 miles (800 m)

0.6 miles (970 m)

0.621 miles (1,000 m)

0.622 miles (1.001 km)

2⁄3 mile (1.1 km)

0.75 miles (1.21 km)

Thoughts? –Fredddie ™ 23:20, 6 May 2016 (UTC)[reply]

Hm, this conversion code is shared with {{routelist row/sandbox}}, so we will need a parameter to request for unit change when invoked from {{infobox road/sandbox}}. In principle, it is doable, but not too trivial. Chinissai (talk) 23:36, 6 May 2016 (UTC)[reply]

That was initially Nbound, but discussion continued at Wikipedia_talk:WikiProject_Australian_Roads/Archive_4#US_distance_conversions, looking at the case of conversions to imperial units – so under 1/4 of a mile would be displayed in feet instead. Which is a bit more work to code, but if we're doing it for imperial→metric we should probably also do it for metric→imperial - Evad37 [talk] 02:06, 7 May 2016 (UTC)[reply]

I decided to have the conversion function compute both units (mi and ft, or km and m), and let the caller decide which unit to use. Chinissai (talk) 10:51, 7 May 2016 (UTC)[reply]

Module:Jctint/AUS?

Would you be able to do something similar to Module:Jctint/USA for the Australian Jctint/core-based templates? {{AUS-WAint}}, {{ACTint}}, {{NSWint}}, {{NTint}}, {{QLDint}}, {{SAint}}, {{TASint}}, and {{VICint}} currently pass near-identical parameters through to {{AUSintcore}}, which reassigns them through to {{Jctint/core}}. (I was going to post this at the USRD thread, but decided it was a bit too offtopic for there) - Evad37 [talk] 02:21, 18 May 2016 (UTC)[reply]

Also a bit off-topic, but the Jctint/core templates are pretty underdeveloped outside of the US, Canada (missing some provinces), and Australia. I'm hoping that we can get more countries going in the future. --Rs chen 7754 05:29, 18 May 2016 (UTC)[reply]

I probably can, although I am starting to think that the core module should be able to process a list of subdivisions (e.g., a junction spanning multiple subdivisions) using a configuration in road data modules. Right now the USA module is doing some redundant work of creating wikilinks, when the core module should be able to handle it. Let me try this in Module:Jctint/core/sandbox first, but deploying this probably warrants some discussions. (I can't edit the live module either.) When I have a better idea of what the long-term solution looks like, I can then decide whether transition code for USA and AUS is appropriate. Chinissai (talk) 14:28, 18 May 2016 (UTC)[reply]

@Evad37: Can you help test Module:Jctint/AUS for me? You can replace state templates that call {{AUSintcore}} with the following form of invocation, e.g., for ACT:

{{#invoke:Jctint/AUS|jctint
|state=ACT
|LGA={{{district|}}}
|LGA_note={{{district_note|}}}
}}

For other states, remove both LGA parameters above and change |state= accordingly. Use WA for Western Australia.

I tried previewing {{NSWint}} and {{VICint}} with Newell Highway and it appeared okay to me. Note that the module uses Module:Jctint/core/sandbox, so you might not want to deploy this yet. (However, I doubt I will make any more significant changes to the sandbox in the near future, because it should now be general enough to handle junctions globally.) Chinissai (talk) 14:45, 20 May 2016 (UTC)[reply]

Thanks! Looking pretty good so far, with the tests I've done. Having enumarated sub2 parameters (|location#=) is cool, though there are a few issues with the current setup:

Overlinking: Having every instance of quadripoint and tripoint linked in Kwinana Freeway#Interchanges is too much. Perhaps have a parameter to turn off (or turn on?) the links.
Internationalisation: "line" is the terminology used for U.S. cities and counties, but "boundary" is used in Australia, and there might be different terminology for other countries.
5+ locations: while relatively rare, cases (such as second last row in Albany Highway#Major_intersections) could be handled by the code if it appended "multipoint" (linked to Quadripoint#Multipoints_of_greater_numerical_complexity on first use) when there are five or more
It would be good if the sub1 column could be handled similarly (e.g. have |LGA#= for Australia), and be really cool (if its not too complicated) to be able to use enumerated versions of the formatting-shortcut parameters, e.g. |LGAC1=Foo|LGAS2=Bar|LGAT3=Baz becomes [[City of Foo|Foo]]–[[Shire of Bar|Bar]]–[[Town of Baz|Baz]] tripoint

- Evad37 [talk] 03:11, 21 May 2016 (UTC)[reply]

Thanks for the comments.

I removed all wikilinks for tripoints and quadripoints. I think adding a flag to add wikilinks will introduce inconsistency if not used carefully. (For example, wikilinks might appear in multiple places inconsistently, or appear later than they should.) Texts outside templates are already susceptible to this, and I don't think the template should further encourage it. Unless instances of templates have a way to communicate with each other (I doubt this will happen), I think it is better to turn off all these links and perhaps wikilink elsewhere in the route description or the notes column.
Added customization for the border suffix. Not sure if you already noticed this, but Module:Road data/strings/AUS hosts the configurations, so this is just another line of specification.
Added wikilinked multipoint for 5-or-more locations. I believe these are rare enough that it doesn't hurt to always wikilink.
These are already supported, provided all parameters are of the same type. For example, you can specify LGAC1, LGAC2, ... to achieve the same effect as multiple locations. For mixed types, you will have to (for now) "unfold" the aliases in the road data module, perhaps something like |LGA1=Foo|sub1area1=pC|LGA2=Bar|sub1area2=pS|LGA3=Baz|sub3aread3=pT. In this case, you will have to add "LGA" as an alias for |sub1= in Module:Road data/strings/AUS, but |LGA= is already reserved for special text, so I couldn't reuse that. You can also customize |sub1area= to something else, e.g., sub1area_param = "LGAarea".

Chinissai (talk) 12:37, 21 May 2016 (UTC)[reply]

2016 Wikimedia Foundation Executive Director Search Community Survey

The Board of Trustees of the Wikimedia Foundation has appointed a committee to lead the search for the foundation’s next Executive Director. One of our first tasks is to write the job description of the executive director position, and we are asking for input from the Wikimedia community. Please take a few minutes and complete this survey to help us better understand community and staff expectations for the Wikimedia Foundation Executive Director.

Survey, (hosted by Qualtrics)

Thank you, The Wikimedia Foundation Executive Director Search Steering Committee via MediaWiki message delivery (talk) 21:49, 1 June 2016 (UTC)[reply]

Hold up

I'm pretty sure this edit, if it does what I think it does, just broke dozens of articles. It's completely redundant (and useless in my opinion) to require a |ctdab= when |county= is in the same template instance. –Fredddie ™ 16:02, 11 June 2016 (UTC)[reply]

I am trying to ensure consistency among template invocations. |county= inserts a county column and should not have other functions. If you want to disambiguate a location, you need to use |ctdab=. This is not redundant, as you specify two things that happen to be the same for two different outcomes. Otherwise, it is possible to have a template invocation that has |county=, but the location (township, so far) that does not require disambiguation ends up getting disambiguated anyway. This is surely undesirable moving forward. Chinissai (talk) 16:14, 11 June 2016 (UTC)[reply]

I disagree entirely, but it's not worth the effort to fight it. This was a controversial change in my book, so some sort of discussion or template talk page notice should have occurred. –Fredddie ™ 16:23, 11 June 2016 (UTC)[reply]

I can revert this edit after I am done with adding disambiguation. The change will make documentation simpler, and ~~it did not break too many articles~~. Chinissai (talk) 16:26, 11 June 2016 (UTC)[reply]

Disambiguation using county restored, but this usage is tracked. My concern is that it could be confusing when disambiguation uses |county= in certain invocations, but |ctdab= in others (in addition to the undesirable behavior above); they should be consistent among all. Chinissai (talk) 16:34, 11 June 2016 (UTC)[reply]

Actually, this reminds me that several states are yet to have their jctint converted, so breaking changes should not be introduced yet; thanks. What would be really helpful here is information passing across template instances, e.g., use the last county argument specified in the most recent template instance for disambiguation. Chinissai (talk) 17:18, 11 June 2016 (UTC)[reply]

Massachusetts Turnpike

I understand that the signage has Amherst on it, however this is not how all the other exits are listed (they haven't all been scoped out on Google Maps for accuracy). The column titled "Destinations" actually has a citation listed for it [2], which lists EB/WB as "32, Palmer, Ware". Unless there is a plan that will ultimately fix this discrepancy for all the exits listed it should be reverted to the way MassDOT has it listed on their official website. Garchy (talk) 20:26, 13 June 2016 (UTC)[reply]

I did verify all exits on Google Maps and added that reference about a year ago. Please check the article history. I could have added a StreetView reference for every exit, but that would definitely have been too much. Chinissai (talk) 20:37, 13 June 2016 (UTC)[reply]

How is signage normally added to the exit list on roads? You may have more experience there than me - usually I see a MassDOT reference, but it tends to be ambiguous from article to article. I've seen plenty of editors fighting about this through the years on different articles! Garchy (talk) 20:42, 13 June 2016 (UTC)[reply]

This is the edit I was talking about (goes back to almost two years already). All the exit lists I have worked on are verified against StreetView, but I rarely cite it in the destination column heading to avoid overciting (you can't have one single StreetView citation for all exits). If the DOT site has this list, however, I do cite it. In exceptional cases, I will cite individual exits when things get complicated or disagree with DOT listing, e.g., Exit 27 on I-95. I sometimes add a reference in a notes cell, e.g., Exit 10 on Mass Pike. I guess what should be done here is to add a StreetView reference to Exit 8 destination cell. Chinissai (talk) 20:54, 13 June 2016 (UTC)[reply]

Wisconsin towns

I'm curious why you're changing |town= to |location= like in this edit [3]. Towns in Wisconsin are the same thing as townships in other states and do not refer to a small city in the generic sense. I reviewed a few other edits you made last night/this morning that were on my watchlist and thought they were correct previously.–Fredddie ™ 14:29, 1 October 2016 (UTC)[reply]

I think Wisconsin towns and New York towns are similar. (New York does not have townships, and villages and cities are parts of towns.) One issue I found is that, like with New York, but to a larger extent, Wisconsin town articles are not named consistently. Some have (town) disambiguator (Dodgeville (town), Wisconsin), some have county disambiguator (Washington, Sauk County, Wisconsin), some have both (Deerfield (town), Dane County, Wisconsin), and some have none (Bridgeport, Wisconsin)! {{WIint}}'s |town= does not handle all of these cases (the latter two, in particular), and I am trying to make that work, ideally with Module:Jctint/USA. The problem is that |town= and |ctdab= are overloaded to prevent the two case above, so we need a way to accommodate them. One way is like what I did, and like in New York articles: towns without a disambiguator are coded using |location= and displayed as-is without Town of, towns with (town) disambiguator use |town=, which I regard as sugar for |location= with |area=town, and towns with county disambiguator use |location= and |ctdab= and are displayed without Town of. This way, we can use both |area= and |ctdab= to handle the third case. If one needs the prefix Town of displayed (not entirely sure why, if the town is unique among incorporated places within a county), the fourth case has to be handled accordingly without using any kind of disambiguator to trigger the prefix. One way to do that is to dedicate |town= for the prefix and use |area= and |ctdab= for the rest, but this just seems an overkill. Either way, I think we should make the usage for New York and Wisconsin consistent. Chinissai (talk) 15:13, 1 October 2016 (UTC)[reply]

Functionally, displaying "Town of <town>" should be exactly the same as "<town> Township" in other states. Yes, the naming conventions of Wisconsin location articles are all over the place, but that's not our problem to fix. If a junction is in a town in Wisconsin, it should say "Town of <town>". I think the logic behind town and ctdab works fine. –Fredddie ™ 16:38, 1 October 2016 (UTC)[reply]

So how do you suggest we deal with Bridgeport, Wisconsin, as in U.S. Route 18 in Wisconsin? {{{town}}} and {{{ctdab}}} do not handle this, and I am not willing to resort to |location_special=, which suggests that there is a fundamental issue with how parameters are intended to work with all cases. If it's not our problem to fix town article names, it is our problem to fix how we handle them. And if we can't be consistent, we shouldn't try to. Chinissai (talk) 16:46, 1 October 2016 (UTC)[reply]

Perhaps a more fundamental question is, why should we say "Town of <town>" when <town> has no duplicate within the county? Another way to put this is, why should Halfmoon in Interstate 87 be prefixed with "Town of" when there is no other Halfmoon in Saratoga County? Chinissai (talk) 16:57, 1 October 2016 (UTC)[reply]

(edit conflict) Bridgeport is unincorporated village, so if we want to use that, we should use |village=Bridgeport (or |location=Bridgeport|area=village if we don't have a village param) and redirect the Village of Bridgeport redlink to the community disambiguator. The better solution is to use |town=Bridgeport to get Town of Bridgeport and move on. –Fredddie ™ 17:07, 1 October 2016 (UTC)[reply]

How about Deerfield (town), Dane County, Wisconsin? (Again, no |location_special=, as this naming convention is not uncommon.)

Speaking of convention, I had to look deeper into how these things are named (see Talk:List of towns in Wisconsin, Wikipedia talk:WikiProject Wisconsin/Archive 4#Naming convention for unincorporated communities, and Wikipedia talk:WikiProject Wisconsin/Archive 5#Yet another discussion about naming towns), and it turns out "inconsistent" is not the right word to use here. There are rules deciding how articles get named, but the resulting names can be ambiguous: Looking at Summit, Waukesha County, Wisconsin, it is usually impossible to tell whether Summit is a town or a village. So, in that respect, one could argue that, to be clear to readers, we should prefix Summit with Village of, which raises the same question I asked earlier: Why do we need to do this if we know there is only one Summit in Waukesha County, whether it be a village or a town? Well, it turns out, as you pointed out with Bridgeport, that the article covers both village and town, even if it says village in the infobox! This is illustrated by Interstate 94 in Wisconsin, which points to Summit (town), Waukesha County, Wisconsin, which redirects to the article in question.

So, I agree that a disambiguator is needed if the actual article talks about multiple entities, but this should be reflected in the link also, not just the displayed text. Otherwise, our template would permit incorrect coding like |town=Marshall|ctdab=Dane to give Town of Marshall, and it would be difficult to police. (Same issue with "New York," whether it is state or city. There is an ongoing operation to pipe [[New York (state)|New York]] even if the state article remains at "New York.") I suggest we do the same thing here. If we need Town of prefixed, use |town=, but it will always add (town) disambiguator to the link. Create redirects as necessary. |ctdab= works as in the general case. This way we can handle the Town of Deerfield properly. Otherwise, there is only one such named entity within the county, so no disambiguator is needed, hence no need to prefix with Town of.

You raised a good point about the equivalence with townships in other states, that Township is always displayed alongside the name, and suggested that we do the same with Wisconsin towns. I would note that it was trivial for townships, because every township article name has Township suffixed, so |township= simply adds Township to both the link and displayed text. We could not do the same with towns by leaving the link alone without risking the possibility of incorrect coding above; some tradeoff needs to be made. Chinissai (talk) 19:20, 1 October 2016 (UTC)[reply]

I would be OK with adding (town) to every case of |town=. Redirects are cheap. –Fredddie ™ 21:45, 1 October 2016 (UTC)[reply]

This discussion belongs on the WikiProject Wisconsin talk page and any edits to the names of towns should receive the OK there. The proper terminology for referring to towns as jurisdictions in Wisconsin is "Town of ABC". Many towns have the same names as hamlets, villages, or cities, hence the reason for (town) in the article name. There are also many duplicate town names (same name in different counties, e.g. Springfield, Wisconsin), so the name of the county must be a part of the article title. Please do not make any wholesale changes to article names without discussing it on the WikiProject Wisconsin talk page. 32.218.38.203 (talk) 01:36, 2 October 2016 (UTC)[reply]

As to your example of Summit (town), Waukesha County, Wisconsin redirecting to Summit, Waukesha County, Wisconsin - if you had bothered to read the article you would have seen that the Town of Summit incorporated as a village in 2010. So the redirect is entirely proper and not some quirk as you think. 32.218.38.203 (talk) 01:51, 2 October 2016 (UTC)[reply]

Cool your jets. Redirects are cheap. –Fredddie ™ 02:00, 2 October 2016 (UTC)[reply]

Agreed, redirects are cheap, and for the structured usage of creating output links in templates like Template:Jctint (edit | talk | history | links | watch | logs), I'd say that the missing "Foo (town), Wisconsin" redirects should be made at some point anyway. Imzadi 1979 → 02:07, 2 October 2016 (UTC)[reply]

ArbCom Elections 2016: Voting now open!

Hello, Chinissai. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)[reply]

ArbCom 2017 election voter message

Hello, Chinissai. Voting in the 2017 Arbitration Committee elections is now open until 23.59 on Sunday, 10 December. All users who registered an account before Saturday, 28 October 2017, made at least 150 mainspace edits before Wednesday, 1 November 2017 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2017 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 3 December 2017 (UTC)[reply]