Template talk:Jctint/core

Ideas for inclusion

Here is a scratchpad for ideas to add to this template. –Fredddie™ 05:22, 26 January 2012 (UTC)

Unit conversion (mi↔km)

• Infobox road-style or {{convert}}?
• Reference capability – |mileref=, |mile2ref=, etc.

Edit request on 28 May 2012

The color coding function isn't working in {{jctbridge}} which uses this template. Please change:

-->{{#if:{{{place|}}}|<td rowspan={{#if:{{{pspan|}}}|{{{pspan}}}|{{#if:{{{jspan|}}}|{{{jspan}}}|1}}}} colspan={{#switch:{{{1|}}}{{{2|}}}|exit=3|old=4|exitname=4|oldname=5|#default=2}} align=center>{{{place| }}}</td>|<!--

to:

-->{{#if:{{{place|}}}|<td rowspan={{#if:{{{pspan|}}}|{{{pspan}}}|{{#if:{{{jspan|}}}|{{{jspan}}}|1}}}} colspan={{#switch:{{{1|}}}{{{2|}}}|exit=3|old=4|exitname=4|oldname=5|#default=2}} {{#if:{{{type|}}}|{{#switch:{{{type}}}
|closed|concur|mplex|incomplete|unbuilt={{Jctint/{{{type}}}}}|#default=}}|}} align=center>{{{place| }}}</td>|<!--

to re-enable it. The change has been tested in the sandbox, thanks. (Please copy the code from the edit window because there are non-breaking spaces present in it. Imzadi 1979 → 10:13, 28 May 2012 (UTC)

Is there a testcase somewhere? Or can you tell me if the simplification I made to the version in the sandbox works correctly? Anomie⚔ 16:09, 28 May 2012 (UTC)

Template:Jctint/testcases contains the testcases for the entire suite's sandboxes... and the colored one is the tunnel in the California section. (Exisiting isn't red for the Figeroa tunnels, but the sandbox is). Imzadi 1979 → 16:27, 28 May 2012 (UTC)

 Done -- WOSlinker (talk) 21:05, 29 May 2012 (UTC)

Feature request: Cell to span region and sub1 column

Would it be possible to adjust the template code to allow a cell to span the region and sub1 columns, so that something like this would be possible?

State	LGA	Location	km	mi	Destinations	Notes
New South Wales	some LGA	some location	0	0.0	some road	NSW is divided into LGAs...
Australian Capital Territory		another location	1	0.6	another road	...but the ACT is not

- Evad37 (talk) 01:39, 8 April 2013 (UTC)

Let me look, but I think it's already in there. –Fredddie™ 02:25, 8 April 2013 (UTC)

Try using |unitary=. That should span across the three columns. –Fredddie™ 02:29, 8 April 2013 (UTC)

Yes, but I'm looking for something to span only the first two columns, and still allow locations to be entered on the third column - Evad37 (talk) 03:02, 8 April 2013 (UTC)

{{editprotected}} I think the changes I've made to the sandbox version will work without breaking anything. Basically, it adds a new parameter |region_spans_sub1. If it is set to "yes", or any other non-empty value, the region table cell will have a colspan of 2; otherwise the colspan will be set to 1. Example:

State	LGA	Location	km	mi	Destinations	Notes
New South Wales	some LGA	some location	0	0.0	some road	NSW is divided into LGAs...
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

It doesn't seem to cause any problems in the testcases page. - Evad37 (talk) 05:12, 14 April 2013 (UTC)

Edit request removed... There are districts that can be used for ACT road junctions lists - Evad37 (talk) 13:08, 15 April 2013 (UTC)

Shouldn't the existence of an exit= be enough?

Why is 1=exit necessary? --NE2 09:27, 30 December 2013 (UTC)

Take U.S. Route 131 for example. Sections of that highway are not a freeway, so there aren't exit numbers. If we didn't have |1=exit, the template wouldn't know to insert a blank cell for the exit column. Imzadi 1979 → 09:29, 30 December 2013 (UTC)

I thought we hashed this out two years ago when the core was written. –Fredddie™ 12:44, 30 December 2013 (UTC)

Nothing would prevent you from using |exit if you want. Or maybe |exit=none could be used as an alternative method. --NE2 17:46, 4 January 2014 (UTC)

How about a way to give a reference for just one distance?

Something like a length_ref parameter for one row in the table, if you use a different source for that distance. --NE2 17:47, 4 January 2014 (UTC)

Make sure |length_ref={{{length_ref|}}} is added to {{FLint}} or whichever one you're using. Adding a ref to the mile column will break the conversion. –Fredddie™ 21:18, 4 January 2014 (UTC)

Oh cool, it was there. --NE2 05:18, 5 January 2014 (UTC)

Template outputs non-accessible code

This template outputs code that does not meet WCAG 2.0 requirements for an accessible table. One of the following needs to happen to make the table accessible.

1) Convert to a simple table by moving the output of the mile markers to the first column. However, this would not be sufficient in tables where the mile markers reset to zero through the course of the table, so this might not be a good solution.

2) Meet the markup requirements of a complex table by adding id and headers attributes as described in http://www.w3.org/TR/WCAG20-TECHS/H43.html (in the case of Jctint, we are using the columns preceding the mile markers as row headings as opposed to column headings, but the principle is the same). Thisisnotatest (talk) 22:37, 22 June 2014 (UTC)

For example, for California State Route 82:

• The county, location, postmile, and destinations cells in the heading row might get id="c1", id="c2", id="c3", and id="c4" respectively
• The Santa Clara cell might get id="r2c1"
• The San Jose cell might get id="r2c2" and header="r2 c2"
• The R8.61 cell might get id="r11c3" and header="r2c1 r2c2 c3"
• The Santa Clara Street cell might get header="r2c1 r2c2 r11c3 c4" (no id because it is the first non-row-header data in that row) — Preceding unsigned comment added by Thisisnotatest (talk • contribs) 23:02, 22 June 2014 (UTC)

This honestly looks like a bunch of gibberish to me. From what I can tell, you want me (the maintainer) to add row and column numbers to the cells. However, the templates don't keep track of row and column numbers. Junction lists generally have two columns for distances, and they may have additional columns for old and current exit numbers, include a column for named interchanges, or possibly not use the county and location columns at all. This looks easier said than done. -happy5214 06:34, 23 June 2014 (UTC)

Out of the scope of this page—this template merely implements the WP:RJL standard. Proposed changes to the standard should be done on its talk page. —Scott5114↗ [EXACT CHANGE ONLY] 07:28, 23 June 2014 (UTC)

Pspan issues

Currently, you can use |pspan= to rowspan the place/bridge/restarea/etc colspanned cell However, there is no way to turn off this cell when pspan is used. We can use |notes=none to turn off the notes column when it is rowspanned. N50 road (Netherlands) shows this in action; the bridge spans more than one body of water. –Fredddie™ 17:48, 3 January 2015 (UTC)

Fixed in the sandbox. |place=none can now be used in the same way as |notes=none. See Template:Jctint/testcases#pspan for the test case. Chinissai (talk) 23:58, 10 May 2016 (UTC)

Formatting of large distances

The template/module formats a large distance in the primary unit without a thousands-separting comma, but in the converted units there is a comma. Putting a comma in the input breaks the conversion, so that isn't an option. Example:

County	Location	mi	km	Destinations	Notes
Sub1	Sub2	3,133.42	5,042.75	Example
Sub1	Sub2	3,133.42		Example
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

Further examples at Great Northern Highway § Major intersections - Evad37 [talk] 05:54, 18 January 2015 (UTC)

@Happy5214: Any thoughts? - Evad37 [talk] 00:52, 26 January 2015 (UTC)

I'll look into it, but I figure it's an issue with not being able to parse the comma-including number. -happy5214 02:31, 26 January 2015 (UTC)

I think I found something:

County	Location	mi	km	Destinations	Notes
Sub1	Sub2	3,133.42	5,042.75	Example
Sub1	Sub2	3,133.42		Example
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

-happy5214 03:23, 26 January 2015 (UTC)

Almost there, but that sandbox version is truncating trailing 0's (indicating precision) from the primary units:

County	Location	mi	km	Destinations	Notes
Sub1	Sub2	0.00	0.00	Live
Sub1	Sub2	1,234.00	1,985.93	Live
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

- Evad37 [talk] 05:01, 26 January 2015 (UTC)

The sandbox now has the expected behavior (see above). Chinissai (talk) 14:55, 8 May 2016 (UTC)

|primary_topic= too general

{{{primary_topic}}} specifies whether {{{sub1}}} and {{{sub2}}} should be disambiguated with {{{region}}}. For example, in California, if |primary_topic=no, |sub1=Marin would give [[Marin County, California|Marin]], and |sub2=Stinson Beach would give [[Stinson Beach, California|Stinson Beach]].

Today I came across British Columbia Highway 99, where sub1 (regional district) is not to be disambiguated, but sub2 (location) is to be disambiguated. For example, |sub1=Squamish-Lillooet should give [[Squamish-Lillooet Regional District|Squamish-Lillooet]], but |sub2=Squamish should give [[Squamish, British Columbia|Squamish]]. No possible argument for {{{primary_topic}}} would make this work.

I would like to propose that |primary_topic= be refined to |indep_city_nodab=, |sub1_nodab=, and |sub2_nodab=, so that BC highways, and potentially many more road articles, can be handled with grace. See function locations in Module:Road data for the proposed code, and Template:Jcttop/core/testcases for BC example above in action. Chinissai (talk) 23:34, 10 May 2016 (UTC)

If only the sub2 needs the disambiguation, then can't you (in the wrapper template) use |sub1_special= instead of |sub1=? That's what {{AUSintcore}} uses for LGAs (sub1), which aren't disambig'ed while locations (sub2) are disambig'ed - Evad37 [talk] 01:37, 11 May 2016 (UTC)

One could do that, but that would defeat the purpose of having |sub1= available in the first place for that wrapper template, wouldn't it? I consider |sub1_special= to be used in special cases, so for regular cases, we should be able to use |sub1= as much as possible, and what we have now does not accommodate that. Chinissai (talk) 02:59, 11 May 2016 (UTC)

I suppose its just a matter of where the disambiguating code lives, the wrapper template or the module (i.e. no difference for the end user). Although lua might be a bit quicker? On another matter, if I'm reading the proposed code correctly, every wrapper template will need to be edited? That is, those currently without |primary_topic= will need to add |indep_city_nodab=yes|sub1_nodab=yes|sub2_nodab=yes, and those currently with |primary_topic=no should have that parameter removed and may need one or two of the new parameters added on a case-by-case basis (possibly replacing some existing code in |sub1_special=) - Evad37 [talk] 01:55, 12 May 2016 (UTC)

Template-protected edit request on 11 May 2016

Module:Jctint/core/sandbox contains fixes for Template talk:Jctint/core#Formatting of large distances and Template talk:Jctint/core#Pspan issues, along with code reformatting and refactoring. Relevant test cases can be found in the aforementioned sections and at Template:Jctint/testcases#pspan. The sandbox module can be simply synchronized with the live module without further modifications. Chinissai (talk) 00:13, 11 May 2016 (UTC)

@Chinissai: Thanks so much for a very clear edit request here. Appreciate the test cases too. The code looks good, but I'm just checking again before we publish... allow a few minutes. — Andy W. (talk · ctb) 01:02, 11 May 2016 (UTC)

@Chinissai: Looks all right to me.

Question: At Template talk:Jctint/core#Formatting of large distances, is the error behavior of producing in the second case when 3,133.42 expected or does it need documentation? — Andy W. (talk · ctb) 01:10, 11 May 2016 (UTC)

Currently the error only shows itself by giving a blank cell instead of the converted distance. An explicit error message isn't a bad idea. - Evad37 [talk] 01:44, 11 May 2016 (UTC)

@Andy M. Wang: That's the expected behavior, as the input number contains a comma. The sandbox module automatically inserts commas; no need to do that in the input. Chinissai (talk) 02:53, 11 May 2016 (UTC)

Done Sounds good. — Andy W. (talk · ctb) 04:01, 11 May 2016 (UTC)

Sorry, apparently there was a bug on |unitdef=, when it is not passed an argument. The default value is supposed to be km, but this was not mentioned in the documentation, so I missed it. British Columbia Highway 99 has an example of the error. The Module:Jctint/core/sandbox has the patch. Chinissai (talk) 04:56, 11 May 2016 (UTC)

@Chinissai: I don't know Lua well enough to review the patch in the sandbox, but in the meantime, I've reverted back to the stable version. Pinging Andy M. Wang to review the patch if he cares to. ~ Rob^Talk 05:05, 11 May 2016 (UTC)

Thanks. @Chinissai: Ported to live again with Special:Diff/719691641/719693610. Thanks for your patience :) Let me know if there are still issues. — Andy W. (talk · ctb) 06:23, 11 May 2016 (UTC)

@Andy M. Wang: Thanks for your comprehensive code review. The module should be more robust and less error-prone now. Chinissai (talk) 06:31, 11 May 2016 (UTC)

Negative distances

@Chinissai: Can we do something to allow negative distances? There's a bunch of Canadian roads in Category:Jctint template using non-numeric parameter values using negative distances for closed/former sections at the start of the junction list. - Evad37 [talk] 22:59, 11 May 2016 (UTC)

@Evad37: I believe those errors use an en-dash instead of a plain dash. Looks like a plain dash will be converted to an en-dash automatically, as seen here:

County	Location	mi	km	Destinations	Notes
Tompkins	​	−15	−24		Plain dash |mile=-15
		−15			En-dash |mile=−15
		−15			minus |mile=−15
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

So, converting en-dashes to plain dashes should solve the problem. Chinissai (talk) 23:16, 11 May 2016 (UTC)

Okay, thanks Chinissai - Evad37 [talk] 23:18, 11 May 2016 (UTC)

It's possible that it was a minus sign (−), which is different than -, –, or —. –Fredddie™ 00:03, 12 May 2016 (UTC)

Yeah, it (or at least one) was a minus. Copying from an old revision of Ontario Highway 15: {{#ifeq:−|−|minus|not minus}} → minus; {{#ifeq:−|–|endash|not endash}} → not endash. I added a minus to the table above, but I don't know if we actually need to support this going forward – a hyphen is easier to type as template input, and the output from the template is still a minus. - Evad37 [talk] 01:32, 12 May 2016 (UTC)

Multiple old exit numbers

Moved from User talk:Chinissai

Re: this edit, I would oppose the collapsible option completely and advise against adding it. I do like the little extra footnotes in the example on the testcases page, but I think collapsing the old numbers is a very bad idea from an accessibility standpoint. Imzadi 1979 → 13:46, 14 May 2016 (UTC)

Just to follow up, there's nothing wrong with listing multiple old numbers separated by commas in that single cell, adding the footnotes as appropriate. However, the show and hide links overlap the numbers on my display, and that many extra links would cause issues with screen readers. They'd even cause issues with regular readers who'd have to spend an eternity expanding numerous cells in the table to see all of the information. I'd strongly encourage you not to proceed with this new concept. Imzadi 1979 → 13:59, 14 May 2016 (UTC)

Several issues are at play:

1. All old exit numbers should be kept to help with the history section.
2. Old exit cells should not be too large or they would detract normal readers.
3. Cell contents should be accessible or we hurt the disabled.

Putting old, perhaps ancient exit numbers outside the exit list is obviously impractical, because they form a list of numbers. Dropping ancient exit numbers altogether is inimical to the history of the highway. It appears that all old exit numbers should remain in the exit list with a footnote for each number.

Listing all old exit numbers in the exit list will remain practical if there are not too many of them. In a long run, there could be many old exit numbers, and showing all of them in a cell simply takes too much space. Plus, the displayed old exit numbers probably should be listed on the highway signage. It appears that ancient exit numbers should be hidden unless readers are interested to know.

According to the spec of collapsible tables as I understand it, visually impaired readers will not have trouble with them, as screen readers should still read the collapsed content. Mobility impaired readers might have trouble clicking the show/hide button, but they still see the most recent old exit number, which is probably the most important compared with the rest.

Tradeoffs will need to be made. This is an initial approach. Chinissai (talk) 14:33, 14 May 2016 (UTC)

Regarding your points, I agree with all three, however, I think collapsing the contents of the cell is not the answer. I'm not aware of any cases that would have more than two old exit numbers, something that's easily handled now just by listing both separated by a simple comma. This isn't that different than displaying the distance as a range, and the upside is that the old exit numbers are actually simpler than the mileage numbers with their decimal places.

As we've said in other cases regarding complex notes for complex interchange layouts, sometimes the tabular format of an RJL does not work well to hold and convey the information, and we have to make editorial choices on excluding or summarizing content. I'd also list the oldest old number first and work from there in chronological order, which is backwards of what you're doing. Imzadi 1979 → 15:58, 14 May 2016 (UTC)

The collapsible table now doesn't show up until there are three old exit numbers. The order of exit numbers can be easily reversed; they are specified in chronological order as inputs to avoid excessive parameter renaming. When there are three or more old exit numbers (who knows when), the most recent should always be shown. Ordering is again easy to fix in this case. Chinissai (talk) 16:22, 14 May 2016 (UTC)

Another issue, if the numbers are cited or footnoted, the footnotes are appearing before the comma separator, when our MOS says punctuation appears before any footnotes in such cases. In short, it's just easier to format multiple old numbers manually. I think this is a solution in search of a not-yet-existing problem. Imzadi 1979 → 16:59, 14 May 2016 (UTC)

Slash solves the problem. There's nothing wrong with thinking ahead about something that is bound to happen in a long run. Chinissai (talk) 18:06, 14 May 2016 (UTC)

Unit precision

How is unit precision being determined? The junction list should have the same precision all the way through. In Anthony Henday Drive, for example, the location of all interchanges is provided in whole kilometres. But the location outputted is shown to the tenth of a mile for the first 10 kilometres, then whole miles for the rest of the route. Inputting a whole kilometre should either output a tenth of a mile, or a whole mile, every time. Likewise, inputting a whole mile should output a whole kilometre every time. 117Avenue (talk) 05:00, 14 November 2016 (UTC)

I no longer fully know how this module is designed, but I believe that the precision was meant to model {{convert}}. Compare 2 kilometres (1.2 mi), 12 kilometres (7.5 mi), 52 kilometres (32 mi), and 212 kilometres (132 mi). -happy5214 06:45, 14 November 2016 (UTC)

Edit: well, the comment in the module that does the conversion (Module:Road data/util) says it's supposed to model {{convert}}. @Chinissai: Any ideas? -happy5214 06:45, 14 November 2016 (UTC)

Precisely. Template:Convert/doc#Rounding:_100_ft_is_30.C2.A0m_or_30.5.C2.A0m_or_30.48.C2.A0m.3F. Chinissai (talk) 13:39, 14 November 2016 (UTC)

@117Avenue: personally, I'd rather we had those distances provided to at least the tenth of a kilometer, which should resolve the situation by prompting the templates to round to the tenth of a mile, even for larger numbers. Imzadi 1979 → 14:47, 14 November 2016 (UTC)

I didn't come here for a work-around to put on the article, I came here to say there is something wrong with the template code. Template:Convert is a one off conversion, converting 2km into a tenth of a mile, and 212km into a whole mile has its use. But Template:Jctint makes a list of locations, and in the table kilometres 2 and 5 should be the same distance apart as kilometres 212 and 215. If the intention of this template is to convert tenth of a kilometre to tenth of a mile every time, then it should convert a whole kilometre to a whole mile every time. Surely the module can be rewritten to do that. 117Avenue (talk) 19:30, 16 November 2016 (UTC)

@117Avenue: Imzadi's suggestion wasn't meant as a template workaround, at least as I understood it. I saw it as more of a general content improvement. Anyway, it appears that Chinissai's attempt to clone the {{convert}} code isn't working like it should be. Whether it needs to be rewritten for better consistency, as you suggest, should be discussed. I believe the prior version of the code implementing the distance conversion (I ought to know, since I wrote it.) didn't try to model {{convert}} and simply reused the provided distance's (kilometers in this case) precision. As for this "list", I'm not entirely sure what you meant by that. Each row is a self-contained template call that has no knowledge of the other distances in the table. -happy5214 00:57, 17 November 2016 (UTC)

I can confirm that the last pre-rewrite version used the simpler conversion code that reused the precision of the provided distance. -happy5214 01:00, 17 November 2016 (UTC)

I'm sorry, @Happy5214:, but can you give a specific example of how my conversion code is not "working like it should be"? I did not intend to clone {{convert}} template, but did implement the conversion according to the specifications on precisions (see above). And I don't believe the code is that complicated either; it handles more kinds of conversions than previously. Chinissai (talk) 01:34, 17 November 2016 (UTC)

@Chinissai: Compare the 12 km example given above with the jctint output on the article we've been discussing. I may have spoken in generalities. By "cloning" I meant specifically trying to duplicate {{convert}}'s precision handling, which jctint does not do exactly as shown in the aforementioned 12 km example. I think the issue at the heart of this discussion is with lines 92-95 of Module:Road data/util, which adds a digit of precision when the input distance only has one significant digit, leading to the inconsistency mentioned by 117Avenue. Finally, just because I think my version is simpler doesn't mean that it's better, or that your version is even that complicated. (Of course, what you and I think is "simple" is still likely gibberish to most.) -happy5214 02:55, 17 November 2016 (UTC)

Sorry if this seems too easy, but couldn't we just use the convert module? There's no reason to reinvent the wheel for sake of the roads projects. –Fredddie™ 03:30, 17 November 2016 (UTC)

I would love to, but the convert module does not export functions that just give the converted result without unit, and I can't seem to find a function that returns a table of converted values in different units, which would help with infobox units that may vary depending on the result (see Template:Infobox road/testcases). Even worse, the module assumes that only {{convert}} will use it, relying on getting input from frames. I would prefer not to parse numbers from convert's output text when it is possible to get each number separately (e.g., why pick apart "16 km (9.9 mi)" when we can get 16 and 9.9 to begin with). At any rate, I updated the util module to better handle the test case pointed out. Chinissai (talk) 14:47, 17 November 2016 (UTC)

@WOSlinker: can you offer any advice? –Fredddie™ 22:28, 17 November 2016 (UTC)

Correct; even using Google Maps to determine distances should result in numbers to the tenth of a unit, while using the preferred sources from the appropriate governments gives us numbers to the hundredth or thousandth. To update that article to give at least the tenth of a kilometer would be beneficial to our readers, and it would resolve the immediate situation. As happy says though, each line of the table is independently generated, and the template can't know the precision level of other lines. Imzadi 1979 → 01:12, 17 November 2016 (UTC)

I am aware each line of the table (or list) is independently generated, which is why I am saying the precision of the output should be based on the precision of the input. 117Avenue (talk) 02:17, 18 November 2016 (UTC)

@Chinissai: Is there any reason for the current bump in precision in such cases, other than mirroring {{convert}}? If not, it may make some sense to follow 117Avenue's advice and eliminate it. -happy5214 02:55, 18 November 2016 (UTC)

{{convert}} must have a reason for bumping precision in such cases. I can't be absolutely sure what that reason is, but here is a possible one. Without the additional precision, the converted result of a small input number would result in too much error from rounding. For example, both 2 km and 1 km would be converted to 1 mi, and the rounding error is between 20-50%. In contrast, even if both 96 km and 97 km are converted to 60 mi, the rounding error is less than 2%.

This brings up the argument that the difference of the converted values should be identical regardless of the input values. I don't think this is a valid argument. Since conversion introduces rounding errors, one should not take a difference of conversions, which results in even more rounding errors; rather, one should take a conversion of the difference of input values. In other words, we should not rely on the correctness of difference of conversions, so there is no need to make sure that this difference is consistent across all sections of the exit list table.

This conversion function is shared with {{Infobox road}} as part of an attempt to minimize the number of conversion functions used in road articles. As I said earlier, using {{convert}} would be ideal. Wikipedia has a standard for doing conversions, so I don't understand why we need to try to come up with another standard just for road articles and confuse readers.

Regarding precision, it seems that what is lacking is a way to specify the precision of the input, as is possible with convert and was possible with infobox, using |length_round=. For example, when one writes 300 km, it could mean anything between 250-350 km (converted to 190 mi with precision bumped to reduce rounding error). We need a way to say that it means something between 295-305 km (also converted to 190 mi) or 299.5-300.5 km (converted to 186 mi). If it means something between 299.95-300.05, then 300.0 is written (converted to 186.4 mi). Still, I don't understand why it is such a problem to simply go to Google Maps and use its measuring tool that gives a more accurate figure to one decimal digit, for which we already have a way to specify. Of course, it is a workaround of some sort until this precision indicator is made available, but it also improves the article. Chinissai (talk) 05:38, 18 November 2016 (UTC)

Since it's relatively easy to add RJL distances to the tenth of a mile/kilometer, I'd be more inclined to have MOS:RJL mandate that than to modify a shared module (and I do think the current setup is useful for the infobox) to satisfy a editor's sense (however intuitive it is; I don't dispute that count) of how an edge case (or what should be an edge case) should behave. I personally won't "fix" it unless someone can come up with a compelling reason for why we should even try to support distances with such a lack of precision. -happy5214 06:04, 18 November 2016 (UTC)

Agreed. I would note that sometimes intuition doesn't work, as described above. One reason that 0.1-precision might not be possible is on historical roads, but unless the road is completely demolished, one could still use Google Maps for determining precise figures. The util module accepts intended input precision, but it hasn't made way to {{jctint}} or {{routelist row}} yet. Chinissai (talk) 13:42, 18 November 2016 (UTC)

Chinissai, I disagree with you, that the rounding error is smaller for 96/97km than it is for 1/2km. Junction lists are used to compare locations to each other, not with the origin of the road. If there's a landmark at both 96 and 97km, it's as much as a problem as it is at 1 and 2km. Adding more precision to the articles, I feel, is still a work around, I want to talk about this template. It needs to have a default precision. Even if we add tenth of a kilometre to every article, we will still have cases where there is a landmark at 0.9km, and the template will convert it to 0.56 miles. The inputted kilometre precision, should be the same as the outputted mile precision, every time. Unless we believe that is not precise enough, in which case the outputted mile precision should be one more, every time. 117Avenue (talk) 06:21, 20 November 2016 (UTC)

This is exactly the point I was making: one should not rely on the difference of already-converted figures due to the accumulation of rounding errors. Landmarks at 96-km and 97-km marks, and 1-km and 2-km marks are 1 km apart, i.e., 0.62 mi. See what I did there? I did the conversion after I took the difference, so there is consistency between both pairs, and rounding error percentage is identical. On the other hand, landmarks at 97-km and 2-km marks, and 96-km and 1-km marks are 95 km part, i.e., 59 mi. In the latter cases, the landmarks are far enough apart that nobody cares about more precise figures, and adding them would be to introduce false precision anyway. If readers desire to determine how far apart two points are, they should work on the input numbers, not on the converted numbers, and be responsible for determining the actual difference in the target unit themselves, or at least be aware of the rounding errors if they insist on working with converted units directly. This template can never anticipate what pairs of points will be compared, so it should not be responsible for ensuring that the differences of converted values are consistent. The default precision for conversions is as specified in the convert module, which is standard across Wikipedia. We don't need to come up with another standard just for this template. Chinissai (talk) 13:12, 20 November 2016 (UTC)

Another way to think about this: the template is showing how far apart points are from the beginning of the road at 0-km post, so the output unit column is showing the correct precision for these comparisons. If readers want how far apart points are from other locations, they're gonna have to do that calculation themselves (again, taking the conversion after taking the difference). Chinissai (talk) 13:25, 20 November 2016 (UTC)

Edit suggestion to module

If I understand this module correctly, the region_special argument doesn't work if the region argument is not present. I don't think this is the desired behaviour, and therefore we should check whether either of the two arguments are present on line 56 (if region then) or add an else clause to this if statement.

I need this for an article I'm working on: A2 motorway (Netherlands). TheWombatGuru (talk) 13:16, 28 December 2016 (UTC)

@TheWombatGuru: I chose the first option of the two you listed. I also edited the A2 article back to the expected code. -happy5214 21:12, 28 December 2016 (UTC)

Thank you for the quick reply. TheWombatGuru (talk) 00:19, 29 December 2016 (UTC)

Request of a copy of the source for usage in Tagalog Wikipedia

Hi. May I request an exact copy of the source of Module:Jctint/core for it to be used in tl:Module:Jctint/core? That tlwiki module is still not existing as of now, and I'm going to create it, but cannot create it if I don't have the copy of the module's source. If not, can anyone create that module with the source exactly as this module? Hope it will have a very quick response as soon as possible. Thanks!JWilz12345 (talk) 10:09, 3 June 2017 (UTC)

There is an option somewhere to export any page/template/module to any wiki. The name of said tool and its location escape me, however. –Fredddie™ 02:02, 4 June 2017 (UTC)

I have already created the tlwiki version of the module. I have based it largely on Chinese version zh:模块:Jctint/core (which is still unprotected as of now and where I copied the source), with some modifications based on the viewed source of this module. Sorry for the inconvenience. However, I hope that someone can check tl:Module:Jctint/core for errors and the like.JWilz12345 (talk) 02:31, 4 June 2017 (UTC)

Don't do that. In fact, you committed a copyright violation. Using the export tool preserves page history from whichever wiki it comes from, which complies with the CC-BY-SA license of Wikipedia. –Fredddie™ 02:38, 4 June 2017 (UTC)

You will need to find a tlwiki administrator and have them use w:tl:Special:Import. Let us know if you need help. --Rschen7754 02:48, 4 June 2017 (UTC)

Help

Can someone help me about jctbridge? --HueMan1 (talk) 10:44, 18 April 2018 (UTC)

@HueMan1: {{Jctbridge}} has documentation transcluded on its page. If you need help beyond that, you'll need to be more specific. -happy5214 23:23, 18 April 2018 (UTC)

@Happy5214: About its source code --HueMan1 (talk) 01:14, 19 April 2018 (UTC)

specifically the {{{river|}}} tag

@HueMan1: The name of the river that bridge crosses goes in the |river= parameter. By default this table cell spans two columns (e.g. "County" and "Location"). If the table actually has three geographic columns (e.g. "State", "County", and "Location") set |river_wide=yes to make the cell span the three columns. If the table only has one geographic column (i.e. entirely within a single county or similar subdivision), use either |location= or |location_special= instead of |river=. - Evad37 [talk] 02:13, 19 April 2018 (UTC)

@Evad37: Since the Philippines has no States and Counties the creator of {{PHLint}} substituted it to |region= and |Province=. My problem is that if I remove the province tag (for a road in one province) the river tag is still large/wide, like this sandbox (User:HueMan1/sandbox/PHLbridge) for Governor's Drive. {{PHLbridge}} is the under-construction Philippine version of {{jctbridge}}. --HueMan1 (talk) 02:28, 19 April 2018 (UTC)

@HueMan1: Jctbridge is general enough that country-specific versions aren't really required. As I said above, if there's only one geographic column, you just need to use a different parameter:

{{Jctbridge
|location_special=''Unnamed River''
|km=48.252
|bridge=Naic Diversion Bridge
}}

will give you...

The entire route is located in Cavite. 

City/Municipality	km	mi	Destinations	Notes
... rows omiited ...
Naic	57.159– 45.947	35.517– 28.550	N402 (Antero Soriano Highway)	Change to unnumbered highway.
Unnamed River	48.252	29.982	Naic Diversion Bridge
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

- Evad37 [talk] 02:36, 19 April 2018 (UTC)

@Evad37:Thanks Evad --HueMan1 (talk) 03:01, 19 April 2018 (UTC)

@Evad37: Now my question is how do I align it on centre? --HueMan1 (talk) 03:07, 19 April 2018 (UTC)

@Evad37:? Do have any idea how to align it on centre?

Center-alignment isn't usually used unless a cell spans multiple columns, so it isn't built in to the templates; if you still want to, you should be able to use {{center}}, i.e. |location_special={{center|River Name}} - Evad37 [talk] 22:44, 19 April 2018 (UTC)

@Evad37: Thank thee...! --HueMan1 (talk) 09:02, 20 April 2018 (UTC)

References

Newbie question about th tags in miles column

I'm a newbie to this template and haven't really dug into it much, but I have a technical question about its markup. Here's a simplified example for illustration:

County	Location	mi	km	Exit	Destinations	Notes
Broome	Kirkwood	14.2	22.9	–	I-81 south – Scranton	Continuation into Pennsylvania
1.000 mi = 1.609 km; 1.000 km = 0.621 mi       Concurrency terminus       Incomplete access        Tolled

When I look at the rendered code for this example using Special:ExpandTemplates, I see that the cell for the miles (the contents of which are "14.2") is rendered as a <th>...</th> table header cell instead of a <td>...</td> normal table cell. I'm not sure, but this may be causing some or all of the Linter errors at Interstate 81 in New York and some other pages that transclude this template. Does someone have an explanation and/or fix for this apparent anomaly? Thanks. – Jonesey95 (talk) 09:06, 26 November 2018 (UTC)

The explanation is in MOS:RJL#Standard columns. According to MOS:DTT, we're supposed to have row headers. It just so happens that the first column is usually heavily rowspanned. I'll check out the lint errors shortly. -happy5214 10:45, 26 November 2018 (UTC)

Now that I think about it, why would this issue only happen on some road articles? I would think that if it were this template, almost all U.S. road articles would be affected (on the order of thousands). -happy5214 11:05, 26 November 2018 (UTC)

Thanks for the response, but I read that linked section and I do not see how it explains the mileage being rendered with <th>...</th> tags instead of <td>...</td> tags. As for why it happens on only some road articles, that is something I haven't puzzled out yet. Also, when I paste the section into Special:ExpandTemplates, I don't get any Linter errors. There is a bit of a mystery here. – Jonesey95 (talk) 12:02, 26 November 2018 (UTC)

How do you know that this template is causing the error? Does the linter say that this template is to blame? Can you link to the page of the linter error list containing the I-81 page? -happy5214 12:41, 26 November 2018 (UTC)

I have LintHint installed in my vector.js file. It looks like this:

mw.loader.load( "https://wiki.riteme.site/w/index.php?title=User:PerfektesChaos/js/lintHint/r.js&action=raw&bcache=1&maxage=86400&ctype=text/javascript" );

Once you have it loaded, you can see a yellow LintHint button at the upper right of any page. If you click it, it will show all of the Linter errors on that page. On the Interstate 81 in New York page, I see 719 "stripped tag" errors. (Although sometimes LintHint shows as green (no errors) if I purge the page; I have asked for help at Wikipedia talk:Linter. The th tags still don't seem syntactically correct, though.)– Jonesey95 (talk) 13:17, 26 November 2018 (UTC)

I can't even put an empty pair of td tags into ExpandTemplates without LintHint complaining. That needs to be fixed before I even know how to go about fixing this template, if there's even anything wrong with it. -happy5214 15:00, 26 November 2018 (UTC)

??? A pair of td tags by themselves is not valid code. – Jonesey95 (talk) 17:35, 26 November 2018 (UTC)

<td>Test</td> also fails. Is that not valid either? -happy5214 18:22, 26 November 2018 (UTC)

I don't think so, since that's just a table cell on its own. You would need something like: <table><tr><td>Test</td></tr></table> – Jonesey95 (talk) 19:36, 26 November 2018 (UTC)

Per MOS:DTT, it's a best practice to have a row header on each row of a table. The header for a row should be an unique attribute, and in the case of these tables, that's the milepost (or kilometre post in metric). As happy5214 noted, the first column(s) are quite heavily rowspanned, and the intersecting roadways wouldn't necessarily be unique (or succinct) either. The primary distance really is the best feature to use as a row header. Imzadi 1979 → 20:58, 26 November 2018 (UTC)

Hmm, that's a new one on me. That looks like a good answer to my original question, and accessibility is a Good Thing. Let's call this case closed for now, since I think the th tags were a rabbit hole, not the answer to the Linter error question. I'll dig around some more to try to figure out why some of these articles have tons of table-related Linter errors (but only sometimes?). – Jonesey95 (talk) 21:26, 26 November 2018 (UTC)

On a side note, |cspan=1 and |lspan=1 are not necessary. –Fredddie™ 00:53, 2 December 2018 (UTC)

Requested move 10 September 2024

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Moved. (If anyone particularly cares that I am closing this after making a comment, though it was only procedural, I am open to receiving complaints at my complaints department.) (closed by non-admin page mover/template-editor) SilverLocust 💬 00:52, 19 September 2024 (UTC)

---

• Module:Jctint/core → Module:Jctint

– This is currently a sub-page of a non-existing module. As this is the main module page, it should be at the base name. Gonnym (talk) 22:34, 10 September 2024 (UTC)

I was going to process this, but the usual page swap script I use didn't work, and I don't want a manual swap to break anything, but if anybody else wants to give it a shot, this revision for Module:Jctint has what I believe to be the correct syntax to redirect it, if you restore that revision before swapping it should hopefully avoid any downtime, as this is used on around 15k pages. ASUKITE 18:49, 12 September 2024 (UTC)

It's template protected anyway. I'd wait 7 days given that Gonnym chose to open an RM rather than request it at WP:RM/TR. SilverLocust 💬 21:42, 13 September 2024 (UTC)

Support' per nom. HouseBlaster (talk • he/they) 22:53, 13 September 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.