User talk:Mukkakukaku/Archive 3

Reply to: "Some advice"

Hi Mukkakukaku!

First of all, thank you so much for your advice! I'm going to apply what you have said to me and read more the guidelines to improve my contributions. I have made a "to do" list to make to notes of what I should/must do it according to your advices. Thank you too because you have made changes to improve the text and validations of some pages.

Before to transcribe more, I'm going to correct the text. If I have some doubt I will ask you.

Regards, Ivanhercaz | Talk 14:51, 23 July 2016 (UTC)

Should I use {{hi}} or better without any indentation? Ivanhercaz | Talk 15:22, 23 July 2016 (UTC)

Use the hanging indents. It's just the regular "paragraph indent" that we ignore. Mukkakukaku (talk) 20:10, 23 July 2016 (UTC)

Thanks again! Okay, I keep in mind that. One question about {{dhr}} so, would it be a good use?

I hope to make a good transcription with your advices! Regards, Ivanhercaz | Talk 20:23, 23 July 2016 (UTC)

Yes, that's good. You can also increase the size by using the second parameter, like this: {{dhr|2em}}. That would give you a vertical space twice as large as a line of text. Mukkakukaku (talk) 20:26, 23 July 2016 (UTC)

CAB reports...

I did some OCR cleanup on these. Not marked as proofread as I understood you were already doing that (and formatting). ShakespeareFan00 (talk) 13:19, 1 August 2016 (UTC)

Thanks for your help. I'll be uploading more CAB reports -- I'm aiming for one a day -- so any help is appreciated. (Especially since I have about 20 years' worth of reports to go through. - Mukkakukaku (talk) 13:22, 1 August 2016 (UTC)

The UK (AAIB) ones go back to around 1915, (so there's over a 100 years of those!). Might be worth making some enquires as to their status. :) ShakespeareFan00 (talk) 14:48, 1 August 2016 (UTC)

Yeah. In the US we had three different agencies (at least) doing these investigations -- CAA, CAB, and NTSB at minimum -- but I'm only focusing on the CAB ones right now. The CAB only existed and performed investigations for accidents between 1937 and 1965, but I plan on hitting up the NTSB next (which gives me time to figure out where the CAA accident reports may be stashed, if they exist at all.)

The US is easy in terms of copyright status since it's all federal government and therefore out of copyright. I've always been royally confused about Crown copyright (pardon the pun) but it's worth looking into to see if the AAIB reports are available in some copyright-free fashion. --Mukkakukaku (talk) 14:53, 1 August 2016 (UTC)

So for sure, AAIB reports are released under Crown copyright. And unless I'm misunderstanding, Crown copyright covers year of publication + 50 years. So in theory we should be able to host any AAIB report published prior to 1966. --Mukkakukaku (talk) 16:08, 1 August 2016 (UTC)

Quite possibly, but I'd check directly with the AAIB first :) . This also depends on having scans available. ShakespeareFan00 (talk) 16:14, 1 August 2016 (UTC)

The AAIB website only has the last 6 published reports, which all indicate a Crown copyright. So the trick will be finding the older ones. The NTSB does a similar runaround, though I think they've got the last few years' worth; best bet will probably be universities. (For example, old NTSB reports can be found by mucking around the Embry-Riddle University's aeronautical engineering archives, but you have to go through like six pages to get there because it's technically supposed to be for students only. or something.) --Mukkakukaku (talk) 16:22, 1 August 2016 (UTC)

Have you tried asking the NTSB for old reports directly? FOIA request if needed? ShakespeareFan00 (talk) 19:35, 1 August 2016 (UTC)

I've actually never had any difficulties locating NTSB reports. I did have problems with the CAB reports, until the Department of Transportation digitized their collection (which is bizarre since the CAB was part of the Department of Commerce. Go figure.) For NTSB, it's just a question of knowing where to look ... and having some university affiliations you can lean on for inter-library loans if need be.

Frankly, there's a lot of material easily available already so I'm not worried about running out of stuff to get my hands on. I'll worry about the rarer stuff once the low-hanging fruit is gone.

Now, the AAIB on the other hand -- I've done some searching and I haven't been able to find any of their older material online, not anything old enough to have expired the Crown copyright at least. I haven't been able to find the ICAO accident circulars which would be my backup data source for UK accidents, so that one's going to be a bit more of a challenge. But like I said, I'm not hurting for material... yet. :)

--Mukkakukaku (talk) 19:38, 1 August 2016 (UTC)

Patrolling

Do feel that when you revert edits as you did here that you can patrol the vandalism to show that you have been past and checked it. More info at Help:Patrolling. Thanks. — billinghurst sDrewth 03:51, 7 August 2016 (UTC)

Railroad Reporting...

I'd try and focus on the BIG ones that lead to changes in procedure.

Wikisource can't host RAIB reports ( third party content issue), and most are online anyway.

That said, if you have access to the right sort of library you might be able to find scans of the UK Board of Trade returns for railway accidents that go back to the late 19th Century! ( Not sure which Regulation of the Railways Act created HM Inspectors of Railways, but sometime around 1860 or so I think.) ShakespeareFan00 (talk) 22:36, 21 August 2016 (UTC)

• I'm actually not really interested in railroad accidents. Although I'll support a popular effort in that direction, my primary focus is still aviation accidents. Those reports I indexed yesterday I found were already on Commons -- I tripped over them by accident while trawling categories and figured I'd upload them before they got lost in the ether again. Mukkakukaku (talk) 07:44, 22 August 2016 (UTC)

Aviation Accident table

Do You intend to add a column for "class" of incident? (i.e Pilot , Mechanical , operations ) etc.. ShakespeareFan00 (talk) 09:20, 25 August 2016 (UTC)

@ShakespeareFan00: Not at this moment. Unfortunately there's no real standard set, and a lot of times it's a combination of factors -- eg.weather causing mechanical failure exacerbated by lack of ground communication causing controlled flight into terrain. I think Flight + Dates + Location is sufficient for now. It's always possible to go back and add more columns, but I'd rather not clutter the tables. Mukkakukaku (talk) 09:23, 25 August 2016 (UTC)

No worries, The concern was metadata for semantic web purposes.ShakespeareFan00 (talk) 12:00, 25 August 2016 (UTC)

H2 template?

Hi, I take it you aren't aware of {{heading}} that removes the necessity to have the H2 and any others in the series. Beeswaxcandle (talk) 09:40, 25 August 2016 (UTC)

@Beeswaxcandle: No, I was not. I ran into {{h1}} while I was validating, saw it was a recently created template a few montsh old, and needed support for a level-2 heading in the same document, so I thought -- just make an equivalent template. Both {{h1}} and {{h2}} should be deleted and their uses replaced with {{heading}}. --Mukkakukaku (talk) 16:38, 25 August 2016 (UTC)

long s

Is there a policy forcing its use? I think I'll continue replacing the long s ("ſ ") with the modern "s". The {{ls}} template seems superfluous to me (produces no visible difference to the reader, and is way too much work). ~ DanielTom (talk) 20:38, 29 August 2016 (UTC)

@DanielTom: The Style guide says the following --

5. Special characters such as accents and ligatures should be used wherever they appear in the original document, if reasonably easy to accomplish. This can be achieved by using the special character menu shown below the editing form; or typography templates (such as {{long s}} (s)), which may help avoid confusion between special and alphabetical characters.

Not sure what the "avoid confusion between special and alphabetic characters" part is about, but I've always understood the rest of it to read "use s where it's shown in the text."

The only time we explicitly don't use the ligatured templates are the {{Ligature Latin ct lowercase}} family of ligatures which were argued about a while back (I wasn't a part of it so I can't comment about the salient points.) Mukkakukaku (talk) 20:44, 29 August 2016 (UTC)

Thank you. Well, having to use that template over 20 times in just 2 stanzas is not "reasonably easy" to me. It's a waste of time. ~ DanielTom (talk) 20:54, 29 August 2016 (UTC)

@DanielTom: Yeah, it's obnoxious. You could always proofread without it and let the validator add it, but some validators get really irritated when they have to make more than two or three changes. Alternatively you could copy the text into a text editor and do a find-and-replace -- the long s appears to be used for all s's that don't terminate the word.

If you'd like to just proofread a regular s, I can go through behind you and add the template as I validate, but I won't be too quick at it due to time constraints. Mukkakukaku (talk) 20:57, 29 August 2016 (UTC)

Right, "long s" isn't used for all "s", so "find-and-replace" isn't really a (quick) solution. In any case, I've given the matter some thought, and I have to confess I'm not at all not convinced that I (or validators) should/need to use that template. First of all, in my experience, all validators I've seen (except you) have let the "s" be. Examples from some projects I've worked on, all diffs by different validators: The Lusiads: (2013), (2014) (same), Vida's Art of Poetry (2015), and Almada Hill – which has been 100% validated, and no long s were used. My opinion that its use is not "reasonably easy" (which is actually why the long s stopped being used in the first place – history is on my side) extends to validators as well. So, I don't think validators should change the "s"s into "long s"s at all (or into that template which renders it "s" in the main namespace anyway) – unless they want to. ~ DanielTom (talk) 21:50, 29 August 2016 (UTC)

The idea behind the style="ls;" template was that readers could choose (through a tool) which character they wanted to see when reading a text that used it. The long-s was mostly in use in the Tudor and Stuart periods, but by the end of the 17th Century it was falling into disfavour and by the end of the 18th was only used by publishers who wanted to pretend antiquity, which situation still persists today. There have been long debates here about how to transcribe the long-s (particularly as it doesn't display for everyone depending on the font and browser) and we are pretty much settled on it being a matter of choice for the original editor. We just ask that it be consistent throughout a work and that the decision is noted on the Index Talk: page for the work. As a rough guideline my personal preference is to use s in works written and printed in the period up to and including the First Commonwealth. From the Restoration onwards I just use s. Beeswaxcandle (talk) 07:45, 30 August 2016 (UTC)

Thanks for the insight, Beeswaxcandle. I wasn't aware of the per-work policy. (We should probably update documentation like the style guide to cover this.) However since the long-s really doesn't add any semantic value, I'm of half a mind that it should go the way of the other ligature templates. I'm going to bring it up on Scriptorium to see if we can get a consensus. --Mukkakukaku (talk) 14:18, 30 August 2016 (UTC)

Sir Martyn

If you look at the transcluded text, what you've just done is eliminate all the space between the cover and the "advertisement" section, and (worse) with this the space between stanzas one and two. Are you doing this intentionally? ~ DanielTom (talk) 16:13, 4 September 2016 (UTC)

There shouldn't be a trailing {{dhr}}, but perhaps one before the {{nop}}. I need to go check what other templates are being used because it's a of a non-standard usage that this work has got going. So yes, it is somewhat intentional but temporary. -- Mukkakukaku (talk) 16:17, 4 September 2016 (UTC)

Also the front matter should probably be separate from the actual cantos, which should be their own sections. This is a fine place to be using {{Auxiliary Table of Contents}}. Mukkakukaku (talk) 16:18, 4 September 2016 (UTC)

Okay thanks, just making sure. ~ DanielTom (talk) 16:30, 4 September 2016 (UTC)

Dropping this here for reference: Wikisource:Scriptorium/Help/Archives/2014#Poems and page breaks. --Mukkakukaku (talk) 16:41, 4 September 2016 (UTC)

@DanielTom: -- OK, it's a bit of a weird situation that I ran into a few years ago. When a stanza ends at a page break, you need to put a {{nop}} inside the closing <poem> tag of the first page, and another {{nop}} immediately following the open <poem> tag on the subsequent page. The link I dropped above for reference shows the discussion where we figured out this weirdness; it has to do with the way the <poem> tag is implemented, and how the Wikimedia servers eat trailing whitespace on transclusion (or similar.)

So I put the {{nop}}'s in as needed between stanzas I and II in Canto 1 so they should be showing again with appropriate spacing. --Mukkakukaku (talk) 16:50, 4 September 2016 (UTC)

Dashes

I notice you've been using ndashes (–) instead of mdashes (—) in a few places where I've validated your proofreads. Is there a reason for that? It is my understanding that ndash is really only used for things like number ranges, but in most cases mdash is the correct punctuation to use, especially in the case of parenthetical statements such as are common in the Beatrix Potter tales we're working on. —Beleg Tâl (talk) 18:54, 19 September 2016 (UTC)

I use whatever the first dash is on the editing toolbar. (This one: –). When I did transcription work (in real life, not on WS), the rule of thumb was "if it's the width of one letter, use an en dash; two letters, use an em dash; more, use a horizontal line/bar. But when I used that rule when I was first starting out on WS, I was told I should be using en dashes. So I just kind of... gave up and now if I see a dash, I use the first one on the toolbar unless it's clearly intended to be longer, in which case I use {{bar}}.

So. I can start using em dashes. I don't know about the "ranges" rule -- I was taught to use hyphens for that in school. I can switch to start using the em dash as my default if that's more accurate. --Mukkakukaku (talk) 19:06, 19 September 2016 (UTC)

Hm, interesting. I was just perusing w:Dash#En dash versus em dash and apparently both en dashes and em dashes are considered correct for this purpose, though I've never seen (or at least never noticed) en dashes used this way. However, the dashes in the Beatrix Potter tales are definitely em dashes, as have been the dashes in all the works I've proofread. I don't know why someone would insist on you only using en dashes, unless you were using em dashes in a number range. I'd recommend using em dash as a default but I won't insist on it. (I will replace en dashes with em dashes in my validation though!) —Beleg Tâl (talk) 19:22, 19 September 2016 (UTC)

Formatting of pages of the Special 301 Report

Hello! Thank your for your interest and participation in proofreading of the Special 301 Report.

Regarding your changes of formatting of the pages which you did along with validation of the 1992 issue. At first, probably I'm not oppose to your change of using customized list instead of separate mini-tables on each item of lists. I may say why I used those tables: it was because of I minded to keep appearance of the pages to be close to that one of original printed pages, but (AFAIK) this is not achiveable by means of using html list; although I suspected (but not was sure) that such approach could be excessive and using simple html list was well enough. Since I do not know how this point is commonly regarded in the En-WS where I am newbie, I do restrain from any claims how far is it correct as you did on this point...

But I am a little stuck by another point (maybe it seems too pedantic, but nevertheless): why did you changed in the proofread text the angled qoute, which are printed in the text of original pages, to the simple one? Really, I understand that keeping formatting must be in reasonable extent, but this your actions seem to be just a worsening of the quality of proofread work. I would agree that for someone it must be allowed that, when first proofread is being done and those users don't want to bother themselves with typing non-standard signs not available from keyboard, the simple signs to be used at first time; but when someone already typed those specific symbols — to change them to simple ones is not good...

Could you comment something on this? Regards, Nigmont (talk) 19:20, 25 September 2016 (UTC)

Hi @Nigmont:

So first, the list versus the tables. I actually tripped over one of the reports while browsing on my phone and it did not scale well, hence why I swapped them over to a list. Tables are for tabular data and they don't scale properly -- nor do they "render" appropriately to screen readers either. HTML lists have the benefit of having automatic scaling built-in. The list items can be further tweaked to appear more like the original by setting a "padding-left:2em;" on the list items themselves, and probably a "margin-left:5px;" on the overall list. But once you go tweaking whitespace like that you run into that non-scaling issue again; since we're modifying the text itself and not applying external style sheets based on the viewer's screen size, I find it better to err on the side of less "whitespace styling" to allow things to scale more appropriately.

With regards to the angled quote -- It is WikiSource policy not to use "curly quotes" (aka 'smart quotes') unless there's an overriding reason for a particular work. This is documented in our style guide where it says:

• Use typewriter quotation marks (straight, not curly).

I hope that helps clarify matters. (Also for future reference, when you want to underline text, the {{u}} template exists for that purpose.)

Best. --Mukkakukaku (talk) 20:01, 25 September 2016 (UTC)

Mukkakukaku, thanks a lot for your clarifications! I'll take them for my consideration while proofreading any other pages in the future (pages of the Special 301 Report, or pages of other works as well). --Nigmont (talk) 20:19, 25 September 2016 (UTC)

Formatting of Iran Air Flight 655 investigation.

I'm attempting to edit the pages of Iran Air Flight 655 to include the handwritten redaction remarks. I managed to produce exact formatting on page 17, but the <ol><li> templates are making it so paragraphs run the entire length of the page, without space to float right. Here is an example of a currently problematic page 6, as you can see, it's impossible for paragraph 5(a) to be shifted over to the left, in order to allow the censor remarks to float independently to right. can you think of any solution? Legofan94 (talk) 16:55, 12 October 2016 (UTC)

@Legofan94: -- We don't retain handwritten annotations. There's a policy somewhere but I can't find it right now. At minimum there's this: Help:Beginner's guide to proofreading#Do not include

That being said, I think these handwritten annotations indicate why something was redacted, right? It would be interested to extend the {{redacted}} template to take an extra parameter, eg "remarks", and then show them on hover. (The whole sidenotes thing is not well supported in general.)

And that being said, you're supposed to use something like {{sidenotes begin}} to "make" a column of space for sidenotes. --Mukkakukaku (talk) 18:14, 12 October 2016 (UTC)

@Mukkakukaku: Thank you for the reply and advice on formatting. I was using The Pentagon Papers as a guide for how to format declassified documents, and they fetured handwritten annotations prominently.

You are correct, those marks do refer to the codes for redacting documents [seen here] I think that there's a gray area with regards to this formatting, in that the document has been altered by employees of the Department of Defense prior to them being released by the freedom of information act, and should be treated as if they were authors or editors. It sounds like the guideline was written to avoid transcribing a college student's essay notes scribbled in the margins.

I think your idea to add extra parameters to the Redacted template would solve both these problems, let me know if you find anyone able to code it in, I'll undo my changes and resume validating.Legofan94 (talk) 20:42, 12 October 2016 (UTC)

@Legofan94: Looks like there's already an undocumented parameter replacement on the {{redact}} template. So {{redact|20|replacement=(b)(b)(6)}} will render like this:  . Think that's sufficient? It's a little goofy but I could tweak it further to make the 'replacement' heading configurable. --Mukkakukaku (talk) 08:55, 13 October 2016 (UTC)

@Mukkakukaku: The system DOES work when only one line of text is required, but the tooltips are unable to render breaks in text. I wouldn't know how to format stacked text in a way that makes the annotations clear to read. an unintuitive way could be to split the redacted text down the middle into two, but that seems to be a bad idea as well. The redaction template itself even says to use these replacements sparingly, since they don't show up for viewers on mobile devices. Legofan94 (talk) 17:28, 13 October 2016 (UTC)

@Legofan94: Actually I added that documentation. :) Previously it was a "hidden" parameter that wasn't documented at all.

Can you show me an example of multiple lines of annotation for a single redaction? I thought it was a 1:1 relationship or otherwise stylistic (which is to say, there's only so much room in a margin so the DOD employee split his notes into two lines.) --Mukkakukaku (talk) 17:31, 13 October 2016 (UTC)

@Mukkakukaku: Page 6 is where I first encounter the problem. In section 5:a , The censor redacts a line and cites two codes, (b)(6) and (b)(7)(c). these represent exceptions to the freedom of information act, as can be seen here [1] (search "This section does not apply to matters that are").

(b)(6) indicates that it was a name redacted to protect the privacy of the person in question, in this case the "Identification Designation Supervisor" on the USS Vincennes who misidentified Iran Air 655 as an F-14. (b)(7)(c) indicates information was used in the official investigation, but if released, would constitute a clear violation of personal privacy. The DoD employee did not split the margin into two lines, it was one item redacted for multiple reasons. countless pages throughout this source have the names of sailors and officers in the US Navy redacted, almost all of them use these two citations, some as many as three.

This is a really crazy censorship job IMHO, it won the Secretary of Defense and Rear Admiral William Fogarty the 1988 Doublespeak Award. Legofan94 (talk) 18:48, 15 October 2016 (UTC)

@Legofan94: Haha, ok. So it seems like the best solution would be to have a tooltip that says: "Redacted text; FOIA request exceptions: (b)(6), (b)(7)(c)"? It would be rather simple to update the template to show that. Mukkakukaku (talk) 19:02, 15 October 2016 (UTC)

@Mukkakukaku:Sure, works for me, so long as it can accommodate a large enough number of exceptions. I haven't read the entire source all the way through, but at the minimum 3 will be needed. Legofan94 (talk) 19:08, 15 October 2016 (UTC)

@Legofan94: OK I'll update the template, test it, and let you know after I finish. Mukkakukaku (talk) 19:28, 15 October 2016 (UTC)

@Legofan94: OK it's done. I've updated the documentation as well. Use the new foia-exceptions parameter like this: foia-exceptions=(b)(6), (b)(7)(c). --Mukkakukaku (talk) 19:44, 15 October 2016 (UTC)

Index:Civil Air Regulations - Part 40 (1953).pdf

OCR corrected. Not to sure about the V-speed subscripting though. ShakespeareFan00 (talk) 15:02, 13 November 2016 (UTC)

Cool, thanks. I'll take a look. -- Mukkakukaku (talk) 15:39, 13 November 2016 (UTC)

Index:The_Coming_Race,_etc_-_1888.djvu

Another version, I forgot I'd proofread previously :) ShakespeareFan00 (talk) 12:08, 31 December 2016 (UTC)

LOL, wow. --Mukkakukaku (talk) 19:51, 31 December 2016 (UTC)