Please do not post any new comments on this page.
This is a discussion archive first created in May 2010, although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Announcements

New lower case diacritic templates

I got sick of having to drive a mouse through a menu whenever I need a diacritic, so I created the following templates:

{{a'}} —> á
{{c'}} —> ć
{{e'}} —> é
{{g'}} —> ģ
{{i'}} —> í
{{o'}} —> ó
{{n'}} —> ń
{{r'}} —> ŕ
{{s'}} —> ś
{{u'}} —> ú
{{y'}} —> ý
{{z'}} —> ź
{{0'}} —> ǿ
{{a`}} —> à
{{e`}} —> è
{{i`}} —> ì
{{o`}} —> ò
{{u`}} —> ù
{{a~}} —> ã
{{n~}} —> ñ
{{o~}} —> õ
{{a:}} —> ä
{{e:}} —> ë
{{i:}} —> ï
{{o:}} —> ö
{{u:}} —> ü
{{y:}} —> ÿ
{{a^}} —> â
{{c^}} —> ĉ
{{e^}} —> ê
{{g^}} —> ĝ
{{h^}} —> ĥ
{{i^}} —> î
{{j^}} —> ĵ
{{o^}} —> ô
{{s^}} —> ŝ
{{u^}} —> û
{{w^}} —> ŵ
{{y^}} —> ŷ
{{a-}} —> ā
{{e-}} —> ē
{{i-}} —> ī
{{o-}} —> ō
{{u-}} —> ū
{{y-}} —> ȳ

This covers most of the lower case diacritics. It would be sweet if {{a:}} and {{A:}} could be made to yield difference results, but all of our titles are regularised to upper case first letter, so this is impossible. Therefore I haven't bothered with upper case diacritics.

I see these as convenience templates. They are there to make coding simple. Going through and replacing all occurrences of ŷ with the corresponding template would be a very silly thing to do. A bot that substitutes these out would be entirely unobjectionable.

Hesperian 13:19, 16 February 2010 (UTC)

What's your opinion of {{+a:}}? BTW, wouldn't it be simpler to use hotstrings with automation software? I don't know what OS you use, but Windows has been converting converting "´u" to "ú" at least since 98SE, if memory serves. I'm not sure, but I think there are combining diacritics in Unicode, so creating hotkeys for a few diacritics might also work. Paradoctor (talk) 13:54, 16 February 2010 (UTC)

"+a:" is as good a title as any. Suits me fine if you want to go ahead and create them too. Hesperian 13:59, 16 February 2010 (UTC)

... except that there is a difference between lower and upper case second letter, so I guess I'd prefer {{+A:}}. Hesperian 14:07, 16 February 2010 (UTC)

I am lazy, so I started {{,}}

{{,|:a}} = ·

{{,|:A}} = ·

{{,|:|a}} = ·

{{,|:|A}} = ·

{{,|a|:}} = ·

{{,|A|:}} = ·

... and so on. Paradoctor (talk) 14:41, 16 February 2010 (UTC)

How does the use of templates impact on text-search functions, whether within WS or Google? Jan1naD ^{(talk • contrib)} 14:03, 16 February 2010 (UTC)

No impact. Hesperian 14:06, 16 February 2010 (UTC)

Sheesh, I am even lazier, I find it far easier to remember alt-0163 £; alt-0233 é; alt-0232 è; alt-0198 Æ; and alt-230 æ which seems to cover 95% of what I need from edittools.(unsigned comment by Billinghurst)

I'm lazier than that, I'm a mac-user. Cygnis insignis (talk) 11:47, 17 February 2010 (UTC)

Note for Mac users, many common diacritics are keystrokes. To create an accent use option-e then type the character, a grave is option-`, option-u gives an umlaut ... and so on. The keystroke option-apple T (option-command T) in any application gives a floating 'Character Palette' which contains virtually everything. Cygnis insignis (talk)

I'm the laziest of all. I use the alt-"number keypad numbers" going back to the days of "extended ascii" to type in common Germanic and Romance language characters, reducing Billinghurst's 4 digits to 3! ResScholar (talk) 05:16, 19 February 2010 (UTC)

╔══════════════════════════════════════════════════════════════════════╗
║128 Ç   143 Å   158 ₧   172 ¼   186 ║   200 ╚   214 ╓   228 Σ   242 ≥ ║
║129 ü   144 É   159 ƒ   173 ¡   187 ╗   201 ╔   215 ╫   229 σ   243 ≤ ║
║130 é   145 æ   160 á   174 «   188 ╝   202 ╩   216 ╪   230 µ   244 ⌠ ║
║131 â   146 Æ   161 í   175 »   189 ╜   203 ╦   217 ┘   231 τ   245 ⌡ ║
║132 ä   147 ô   162 ó   176 ░   190 ╛   204 ╠   218 ┌   232 Φ   246 ÷ ║
║133 à   148 ö   163 ú   177 ▒   191 ┐   205 ═   219 █   233 Θ   247 ≈ ║
║134 å   149 ò   164 ñ   178 ▓   192 └   206 ╬   220 ▄   234 Ω   248 ° ║
║135 ç   150 û   165 Ñ   179 │   193 ┴   207 ╧   221 ▌   235 δ   249 ∙ ║
║136 ê   151 ù   166 ª   180 ┤   194 ┬   208 ╨   222 ▐   236 ∞   250 • ║
║137 ë   152 ÿ   167 º   181 ╡   195 ├   209 ╤   223 ▀   237 φ   251 √ ║
║138 è   153 Ö   168 ¿   182 ╢   196 ─   210 ╥   224 α   238 ε   252 ⁿ ║
║139 ï   154 Ü   169 ⌐   183 ╖   197 ┼   211 ╙   225 ß   239 ∩   253 ² ║
║140 î   155 ¢   170 ¬   184 ╕   198 ╞   212 ╘   226 Γ   240 ≡   254 ■ ║
║141 ì   156 £   171 ½   185 ╣   199 ╟   213 ╒   227 π   241 ±         ║
║142 Ä   157 ¥                                                         ║
╚══════════════════════════════════════════════════════════════════════╝

This photo gave me an idea. It is possible to plug in a second keyboard. I'm looking into programming it so it can be used for shortcuts. Paradoctor (talk) 10:54, 19 February 2010 (UTC)

Note that on unix-like computers, you usually have a Compose key (for me its the key left of the right Ctrl key). For example Compose-"-a creates ä. You can even make all kinds of crazy stuff, such as Compose-(-7-) to create ⑦. Maybe AutoHotKey or a similar software can provide such facility for Windows users as well.--GrafZahl (talk) 11:09, 5 March 2010 (UTC)

Absolutely, you can use hotstrings for that. Paradoctor (talk) 12:00, 5 March 2010 (UTC)

Hey ResidentScholar, a kindred spirit. Is that IBM extended ASCII image copied from Wordperfect??? Do you realize that it dates us back to the Flintsones? :-) — Ineuw (talk) 14:39, 20 March 2010 (UTC)

I was going to copy the image from a help screen of my 1992 edition of Microsoft QBasic to Microsoft Word to the Scriptorium, but Word translated each symbol to its own character set. So I kept the numbers and retyped every character using the alt-num pad keystrokes. Then I imported it here and thought it would look better with a border, so I typed that in too (you'd be surprised at how much work it takes to be lazy sometimes). A lot of old programs still work better than their new ones. I hear footnoting is still easier to do on Wordperfect than Word 2007. And I still use Quicken 8 for DOS (1995) because start-up, navigation and data entry operations have quicker response times than the Windows Quicken. And for nostalgia, I originated an Apple ][ font that I use on IRC so I can pretend I'm using a modem (I know, even with your Popular Science background, I didn't prepare you for this degree of recrudescence). ResScholar (talk) 07:06, 26 March 2010 (UTC)

I haven't visited the Scriptorium in the past few days and missed your reply. Yes, many old softwares are superior in reliability and speed. For this kind of work, I would love to use WP 5.1, (I still have the manual), unfortunately it doesn't support Unicode etc., although some people were trying to develop it, and UBS print support. :-). I also have WP 3.1 Office Suite, (the precursor to Windows 3.1), and DOS 6.1. But let's not regress too much because all this nostalgia will make other Scriptorians ill. — Ineuw (talk) 01:51, 1 April 2010 (UTC)

I raised a similar point at Wikipedia [1] — should have done it here... The option I used at the time was Microsoft Keyboard Layout Creator [2]; I'd wondered if Wikipedia could maintain a page of binary downloads of the keyboard files thus created. But you can also set "US International" under Keyboards in Windows (I don't like it as much as my ad hoc version, but it works). You can also use AutoHotKey. I still don't think it would be a bad idea for editors to get together and work out a best keyboard layout for Wikisource and Wikipedia. Mike Serfas (talk) 18:13, 24 April 2010 (UTC)

Newton's Principia addition a Wikisource milestone

User:D.H has just completed the proofread version of a Wikisource edition of The Mathematical Principles of Natural Philosophy (1846) by Isaac Newton. D.H should be applauded for even undertaking this historic and influential work with the complexities of its long series of reasonings, graphical diagram placement and mathematical typefacing, and yet he has completed it, from all my observations, single-handedly or nearly single-handedly. This 1726 third edition of the work remains a valid explanation of macroscopic physics, of both celestial and terrestial motions within its realm of small velocities and offers intellectual exercise and deeper understanding of the physical world to those who work to master its theories. This kind of major work gives prestige to Wikisource and remedies the plight of those who, for one reason or another have difficulty purchasing or borrowing the work. Again, congratulations, D.H for your achievement in producing an new on-line edition this great work and for honoring us with the efforts behind your contribution. ResScholar (talk) 09:28, 26 March 2010 (UTC)

I agree; fantastic work. —Spangineer^wp (háblame) 12:00, 26 March 2010 (UTC)

I've seen D.H's footprints at Wikipedia. I don't know what kind of body chemistry powers his efforts, but it surely can't be mere C¹². Congratulations! Paradoctor (talk) 14:35, 26 March 2010 (UTC)

Just reviewed the finished product, and wow, what a monumental undertaking! Extraordinarily impressive. Featured text candidate, anyone? Tarmstro99 (talk) 01:08, 1 April 2010 (UTC)

Very impressive. I certainly vote for it.— Ineuw (talk) 12:32, 1 April 2010 (UTC) (P.S: D.H? What's your hourly rate? I am hiring for PSM. :-)

Can I suggest that we give some priority to validating the work so it can be a 'Featured text. I will add it to Wikisource:Featured text candidates so that it is in for consideration. — billinghurst sDrewth 21:07, 1 April 2010 (UTC)

Yes please, but see the bottom of this page and Index talk:Newton's Principia (1846).djvu for some things that need to be tackled before we can get there. —Spangineer^wp (háblame) 21:51, 1 April 2010 (UTC)

I must join the chorus praising this contribution, a very important work made available by a great effort. I removed the nomination at FTC, pending validation and resolution of formatting issues; when resolved it will be an excellent choice for promotion as a Featured Text. Cygnis insignis (talk) 09:33, 2 April 2010 (UTC)

Proposals

Other discussions

Questions

{{listen}} and video .ogg

Richard Nixon's Phone Call to the Moon is the first time that I have come across a video .ogg, and it may be slightly problematic with our existing style and the use of {{listen}}. A graphic within {{header}} may not be the look that we want, at least not set to the left. We could look to add a parameter to the template that sets the image to the right. Other thoughts? — billinghurst sDrewth 13:58, 28 February 2010 (UTC)

Other articles with videos just stick them in a thumbnail in the body, like an image file. I made a new companion template for {{listen}} called {{watch}}. This mostly automates the normal thumbnail format but also adds some of the features from listen. I have altered the Nixon page accordingly. However, I cannot change the similar use of a video in Transcript of the 'friendly fire' incident video (28 March 2003), as it is protected. Hope this helps (and doesn't complicate things) - AdamBMorgan (talk) 18:45, 31 March 2010 (UTC)

I have dropped the protection level to semi, so you should now be able to edit it. — billinghurst sDrewth 19:06, 31 March 2010 (UTC)

Oh, plus a thanks for the work with this. Appreciated. — billinghurst sDrewth

...and that's done too. Thanks, AdamBMorgan (talk) 13:04, 1 April 2010 (UTC)

Custom substitution of archaic letter-forms (and more)

In response to the way we currently deal with long-s (i.e. show ſ in the Page: namespace and "s" in the Main: namespace) I have made a template, {{custom substitution}}, that will allow a user to choose which is shown outside the Page: namespace, using CSS "display" commands stored in the user's Monobook.css. If a user does not have this addition to the monobook, the behaviour defaults to what we have now. The original letter form (i.e. ſ) is always shown in the Page: namespace, regardless of settings, to maintain the correspondence with the text.

I already made the template {{eszett}} which uses {{custom substitution}} to do the same thing for "ß" and "ss" as a test, it does what it is supposed to.

I haven't changed {{ls}} yet, as it a very widely used template, and I'm not convinced this CSS show-hide method is the best way to do things, but it's the only way I can think of doing it. I suppose it could also be done with Javascript somehow in a find-and-replace manner.

This template also allows you to have multiple categories for the substitution, so you can switch them on and off independently.

Thoughts and suggestions? There are instructions on how to use the template on the documentation page. Inductiveload (talk) 10:35, 10 March 2010 (UTC)

Inductiveload, I think it is a good idea as long as it doesn't break anything. As we discussed on IRC, my biggest concern is that we don't change the syntax of {{ls}} because that has the potential to break a lot of stuff. Anyone else have thoughts or ideas? --Mattwj2002 (talk) 11:31, 10 March 2010 (UTC)

Yes, {{ls}} will be used exactly the same. Behaviour of the template will change acocrding to personal options, the default is the same. Inductiveload (talk) 14:44, 10 March 2010 (UTC)

It's not a bad idea, but I disagree strongly with the concept of the eszett template. ß is not archaic typography; it's a modern German character. Its use in English outside names of German origin is simply wrong. The ſs ligature is not ß, and should appear like the fi or ct or any other ligature under the influence of an appropriately smart font.--Prosfilaes (talk) 13:17, 10 March 2010 (UTC)

OK, I wasn't aware the ſs ligature was distinct from ß. I was using it on the eighth line of this page. Maybe it should be removed? For now it illustrates the custom substitute template quite well. The {{ls}} is the primary focus of my effort.Inductiveload (talk) 14:44, 10 March 2010 (UTC)

I think I'm missing something here, but what's wrong with Unicode? Paradoctor (talk) 13:38, 10 March 2010 (UTC)

Where? The goal here is to make user-controllable letter substitutions, particularly in the long-s/s field. I'm personally a fan of just killing the long-s, but since people do want to keep it, it's nice for the user to be able to choose whether or not it appears in the mainspace. All this uses Unicode, but doesn't force us to display the long-s. I suppose a wiki-mod could let us use the straight Unicode instead of templates while keeping the ability to choose long-s over s, but that's more complex for us and less flexible--though I don't really see where the flexibility is necessary.--Prosfilaes (talk) 14:21, 10 March 2010 (UTC)

Oh, it's one of those "reproduction" vs. "readability" things, right? FWIW, I'm a big friend of synchretistic publishing, so go for it, IL. Paradoctor (talk) 19:11, 10 March 2010 (UTC)

The use of long s

I made many page using long s; keeping the long s is tedious, prone error, longer to validate and for little use afaics. If people want them, why not, but I think Page:* should be proofread/corrected with normal s then after the whole book is validated people can switch them to long s (perhaps with a bot?). Readability of code, when proofreading it, is important. And {{ls}}pace is {{ls}}ome movable dimen{{ls}}ion or mea{{ls}}ure... kill the possibility to use orthographic corrector. By the way, actually {{ls}} expand to s in main, any reader complained against? Phe (talk) 12:50, 11 March 2010 (UTC)

So should we just not bother any more about transcribing with {{ls}}? I've been using it a lot as well, but I'm beginning to wonder why… — Sam Wilson ( Talk • Contribs ) … 12:57, 11 March 2010 (UTC)

To be honest, I am not sure how I feel about this. On one hand we want to stay as true to the work as much as possible, which would mean we should want to use the long s. On the other hand, if it is causing technical problems, maybe we don't want to use it. That is my two cents. --Mattwj2002 (talk) 13:08, 11 March 2010 (UTC) (Sorry I forgot to sign in earlier with my comment)

No, I don't think it's causing technical problems (unless they are with whatever system is to be devised for toggling the display). At the moment it's working fine: normal s in the main namespace, long s in Page:. I guess the thing is that no one, no general reader, really sees the long s version. And nor, perhaps, do they want to! That's why I wonder whether it's worth it. — Sam Wilson ( Talk • Contribs ) … 13:29, 11 March 2010 (UTC)

I don't bother. Its fiddly, its meaning is no different to an 's', and if displayed in main it reduces accessibility. However, it may be easier to validate in the Page namespace before entering edit mode. It should also be possible to write a script to assist in converting these, if desired, the exceptions are nearly always predictable. Cygnis insignis (talk) 13:34, 11 March 2010 (UTC)

I did it for Index:The Mathematical Principles of Natural Philosophy - 1729 - Volume 2.djvu, the text layer contain {{ls}} but it's not so easy to do that after validation, template, some parameter to template but not all, html entity, math tag should not be changed, I think it's feasible with a bot but not so easy it look like. Phe (talk) 13:47, 11 March 2010 (UTC)

Add: It may be desirable for some works, but I would first consider if the benefit justifies the effort. People may like doing it that way, perhaps others want a facsimile, and that would be unobjectionable with this proposal. Cygnis insignis (talk) 13:43, 11 March 2010 (UTC)

Even for people wanting something that look like the original works, we are not providing the right things, the italicised form of long s is very different from the non italicised form, like an integral symbol, and most font designer don't draw it correctly. See the word similar, second line Page:The Mathematical Principles of Natural Philosophy - 1729 - Volume 2.djvu/14, any people see it correctly ? Phe (talk) 13:55, 11 March 2010 (UTC)

It doesſn't work with the wrong font.

Juſt pick the right font.

To sum it up:

Juſt pick the right font.

;) Paradoctor (talk) 14:57, 11 March 2010 (UTC)

Interesting, but I'm unsure if changing the default font is wise. Phe (talk) 16:53, 11 March 2010 (UTC)

I'm not sure what you mean by "default". The font used is a client-side decision, and depends on OS, browser, local customizations and the user's custom CSS. Whatever the HTML page requests is merely a suggestion, nothing that binds the client in any way. If the text is even used through our web interface, which is not a given.

Besides, I'm not against providing "modern" variants, but, as billinghurst put it: "The text is king.". One may be concerned that deciding to hide the original version of the text could obscure connotations relying on the choice "s" vs. "ſ". To give an example, Bavaria is written in modern German as "Bayern", which is the result of a 1825 royal decree. It was generally written as "Baiern" before, also as "Bayrn". Pronounciation is the same, but the "greek" y had to be used because the king's son became king of Greece in 1825. As you see, even such apparently "cosmetic" changes may cloud allusions to matters genuinely majestic. ;) Paradoctor (talk) 20:42, 11 March 2010 (UTC)

All the allusions aside, when does the long-s matter? In almost a decade of scanning long-s material, I've ran across one situation where changing the long-s into a s might matter, Magazine, or Animadversions on the English Spelling, and it looks like the scholar who post-processed it for us disagreed. In any case, a text where the author makes up his own alphabet is surely the exception.--Prosfilaes (talk) 01:34, 12 March 2010 (UTC)

"when does the long-s matter?": You never know, that's the whole point. Archiving is about conserving, after all. The nice thing about wikis is, there's never a need to fight a holy war over the finer points. If you don't feel like doing it, do what you like, someone else will finish the finicky stuff later. :) Paradoctor (talk) 02:07, 12 March 2010 (UTC)

The example you give about Bayern vs. Baiern is a spelling change, and these must be kept as it imho, but it's really different from a typographic thing like long s, long s *are* s, nothing else. There is already a lot of typographic change we do, like the ct or Q typography in old book. Reader wanting archive should go directly through the djvu or pdf scan, it's the only authoritative data we have. Phe (talk) 07:20, 12 March 2010 (UTC)

One might wonder why we go to all this trouble at all when we already have authoritative scans. ;) Paradoctor (talk) 10:35, 12 March 2010 (UTC)

Because it can be read by screen readers, because it can be read without deciphering a crummy scan with old-style fonts, because it can be automatically processed (searching, corpus-building, etc.) All of which mediate against the preservation of the long-s; will searching for cast or even caſt find ca{{ls}}t?--Prosfilaes (talk) 05:47, 13 March 2010 (UTC)

Yes, it will find one or the other, at least. The templates are all completely rendered by the time the Google spider starts scraping them. However we render ca{{ls}}t is how Google will find it. Then it is up to Google to recognise that the two are equivalent. Hesperian 10:52, 13 March 2010 (UTC)

But what about our local search?--Prosfilaes (talk) 13:45, 13 March 2010 (UTC)

I started discussion of that in the subsection "Source vs. product" below. Paradoctor (talk) 17:34, 13 March 2010 (UTC)

(edit conflict) Which takes us back to my original question: What's wrong with unicode? That some users need to adjust their settings is already true for modern languages. If I wanted to read burmese script, I'd have to get a font for it. We can direct users to relevant help files. Paradoctor (talk) 11:21, 13 March 2010 (UTC)

Because people who want to read Burmese know they need Burmese fonts; people who want to read Shakespeare don't think they should need special fonts. And again there doesn't seem to be anyone who actually wants to read Shakespeare with the long-s, and not at the very least giving them option not to would be foolish.--Prosfilaes (talk) 13:45, 13 March 2010 (UTC)

I must be missing something here. As I stated above, I am all for providing variants. I merely say that the default base text should stick as close to the source as possible. Anything else produces more entropy than necessary. Transformation of long s to modern s is as simple as adding a simple bit of ECMAScript to the site, and saves us the hassle of dealing with templates.

"people who want to read Shakespeare don't think they should need special fonts": Source that to reliable sources, and I'll believe it. ;) You could also say that people never think they should need anything, but that would probably be held against me. ^_^

Burmese: Um, you can always create a 1:1 transliteration. Romaji is not 1:1, but lack of fonts has never been a fundamental obstacle to anything, merely a matter of haggling over the price. Paradoctor (talk) 17:34, 13 March 2010 (UTC)

You're example about Burmese, like the one on spelling change, is irrelevant. Burmese is written with a different alphabet, here we are talking about an identical character using a different glyph. It's like if you try to argue than this transcription is wrong because we don't use the same glyph for each character. I know it's a common error to consider long s as a different character but it is not. Beside that, it's up to you to show long s can imply semantic change as you suggest, not the reverse, all the evidence we have actually is that use of long s or normal s imply no change in the text. Phe (talk) 14:30, 14 March 2010 (UTC)

Transcribing printed and handwritten literature are different beasts. If you transcribe handwriting, a loss of information about the original text is already implicit.

I'm not saying that I know of particular connotations in this case. I say we don't know, and it's better to err on the side of caution. If you want a nice example of the connotations a typeface can have, read about Nazis and fonts. The simple fact that there are two different glyphs implies that someone thought there is some difference. This difference may be "cosmetic", but that does not necessarily mean it's irrelevant to using or interpreting the text. Formatting can impact on perception of a text's authoritativeness. Honor your ancestors, or they will come back to haunt you. ;) Paradoctor (talk) 15:48, 14 March 2010 (UTC)

┌───────────────────────────────────────────────────────────┘

There's no fundamental difference between transcribing printed and handwritten literature. There's one poem I transcribed, I believe for Project Gutenberg, where the last two lines are the same, but the justification is slightly different on the two lines in the printed version. At the very least, any transcription of that loses information by making it clear whether it was intentional or not, which is not clear from the original. More major is Tristram Shandy, wherein PG's version, and by extension our copy thereof, has been seriously criticized because the original played all sorts of tricks with several blank pages in a row and an all-black page, things that no non-page orientated medium can handle exactly. Your example of the Antiqua-Fraktur change goes right to the point; we don't preserve the distinction, and HTML offers no way to switch to Fraktur short of specifying a specific font and hoping they have it installed. Furthermore, I've done this enough to know what an 18th century font looks like, and what an early 19th century font looks like, and they look and feel differently than Courier or Times New Roman or Arial, with or without long-s.

The fact that there is two different glyphs only means that the style of writing demanded two different glyphs, like the style at the time demanded a special ligature for st (ﬆ).

More over, nothing's free. Transcribing the long-s takes time, which reduces the number of texts we can do. It reduces the chance that I will work on a long-s text if Mozilla's built-in spellchecker is broken by {{ls}} in the middle of words, and it reduces my ability to proofread a text becau{{ls}}e the{{ls}}e words now have in{{ls}}ide them brackets ob{{ls}}curing them and effectively changing the orthography to {{ls}}omething unique.--Prosfilaes (talk) 03:17, 15 March 2010 (UTC)

I have to wonder if using the long-s is an unnecessary distinction -- at least in many cases. In the case of the work I've been transcribing, while in the original edition long-ses were used (as well as the quaint ligature for 'ct"), in the 1805 edition, the text was reset & printed using the modern s. As a result, I've been transcribing using the modern s, & I wouldn't change it -- unless a peeer review insisted it was needed to make Featured status, & then only if done with a bot. -- Llywrch (talk) 16:49, 15 March 2010 (UTC)

"an unnecessary distinction -- at least in many cases": So is a seat belt. Not that I'm saying this is a matter of life and death. ;)

"the 1805 edition, the text was reset & printed using the modern s": Connotations change with time. In the Peterhof Palace, there is a room whose walls are covered with aluminium foil. Paradoctor (talk) 20:00, 15 March 2010 (UTC)

My point was that after only 15 years passed the long s was dropped, which is the equivalent of changing norms between 1995 & now; unless the French Revolution inspired the people responsible for the 1805 edition to drop the long s's, I can't think why typographical practices would change so noticeably this fast. In this case, maybe there was either a reason in the 1790 edition for using an obsolescent practice, or one in the 1805 edition for using a progressive one. Or it was entirely the printer's arbitrary decision in both cases. Or maybe we're reading far too much into this choice. (Does anyone know more about why this letterform went out of use -- facts, not speculation? The Wikipedia article offers only an obvious reason for the change, which lacks a citation to expert opinion.) -- Llywrch (talk) 16:03, 16 March 2010 (UTC)

"only 15 years passed" ... "the French Revolution inspired the people responsible for the 1805 edition": And what's so hard to believe about that? From feudalism to democracy, feminism began in earnest, the metric system replaced a byzantine system of incompatible units. In the decade after, Bonaparte spread the French disease over much of Europe. Compare 1955 to 1970. You'll easily find more examples. Consider this: 15 years is almost a generation.

"maybe we're reading far too much": Maybe, maybe not. The point is, we don't know, so we better err on the side of caution.

"why this letterform went out of use": That would explain why the distinction was considered unimportant. What I'd like to know is: Why were the two distinct glyphs used simultaneously? Either way, this doesn't address the lack of knowledge about connotations, and therefore the cautionary principle still applies. Paradoctor (talk) 18:54, 16 March 2010 (UTC)

It's clear the scholarly opinion on this, as evidenced by every non-facsimile edition of works of this era, is that it doesn't matter. You're changing fonts, you're removing pages, you're removing line breaks, etc.; why does the cautionary principle not stop that?--Prosfilaes (talk) 19:18, 16 March 2010 (UTC)

"𝔰𝔠𝔥𝔬𝔩𝔞𝔯𝔩𝔶 𝔬𝔭𝔦𝔫𝔦𝔬𝔫": 𝔊𝔬𝔱𝔠𝔥𝔞! :) 𝔚𝔥𝔞𝔱 𝔞𝔟𝔬𝔲𝔱 𝔞𝔯𝔱𝔦𝔰𝔱𝔰? 𝔗𝔥𝔢 𝔊𝔢𝔯𝔪𝔞𝔫 𝔞𝔯𝔱𝔦𝔠𝔩𝔢 𝔬𝔫 𝔉𝔯𝔞𝔨𝔱𝔲𝔯 𝔰𝔱𝔞𝔱𝔢𝔰 𝔱𝔥𝔞𝔱 ℌ𝔢𝔯𝔪𝔞𝔫𝔫 ℌ𝔢𝔰𝔰𝔢 𝔦𝔫𝔰𝔦𝔰𝔱𝔢𝔡 𝔬𝔫 𝔥𝔞𝔳𝔦𝔫𝔤 𝔥𝔦𝔰 𝔴𝔬𝔯𝔨𝔰 𝔭𝔯𝔦𝔫𝔱𝔢𝔡 𝔦𝔫 𝔉𝔯𝔞𝔨𝔱𝔲𝔯 𝔞𝔣𝔱𝔢𝔯 𝔚𝔚ℑℑ, 𝔢𝔳𝔢𝔫 𝔱𝔥𝔬𝔲𝔤𝔥 𝔄𝔫𝔱𝔦𝔮𝔲𝔞 𝔴𝔞𝔰 𝔱𝔥𝔢 𝔬𝔣𝔣𝔦𝔠𝔦𝔞𝔩 𝔰𝔠𝔯𝔦𝔭𝔱 𝔰𝔦𝔫𝔠𝔢 1941. 𝔗𝔥𝔦𝔰 𝔪𝔢𝔞𝔫𝔰 𝔱𝔥𝔞𝔱 𝔞𝔫𝔶 𝔢𝔡𝔦𝔱𝔦𝔬𝔫𝔰 𝔬𝔣 ℌ𝔢𝔰𝔰𝔢'𝔰 𝔴𝔬𝔯𝔨 𝔦𝔫, 𝔰𝔞𝔶, Times New Roman, 𝔠𝔞𝔫𝔫𝔬𝔱 𝔟𝔢 𝔠𝔬𝔫𝔰𝔦𝔡𝔢𝔯𝔢𝔡 𝔞𝔲𝔱𝔥𝔬𝔯𝔦𝔱𝔞𝔱𝔦𝔳𝔢. Paradoctor (talk) 21:39, 16 March 2010 (UTC)

I have no clue why you dumped a bunch of ill-formed mathematical notation up there. The Mathematical Fraktur block of Unicode is for symbols, not words.--Prosfilaes (talk) 22:04, 16 March 2010 (UTC)

You and I know about the intended use of Unicode points. Most people would have entirely missed this connotation created by the use of alternative code points for the same glyph. Furthermore, your reaction is an excellent example of the difference "mere" glyph variations can make. Had I used "correct" letters rendered in default fonts, you would have addressed my actual question, rather than my devilishly clever abuse of Unicode. ;) Paradoctor (talk) 22:47, 16 March 2010 (UTC)

I am not sure what the whole issue here is really about. I mean pretty much every text that we could come across with a long s will have another version available printed a century or so later with modern typography. Our goal here is not to have "the one and only authoritative reading of Book". Our goal here is to archive whatever has been printed. If we are archiving an edition from the 1600's use a long s and spell "she" with two e's. If we are archiving an edition from the 1800's do otherwise. This practice let's us do fun things like Elegy II Comparative text. I don't understand what the difference is between archaic typography and archaic spelling. The substantive arguments seem the same to me, the only difference is that no one is promoting the conversion of archaic spellings. Do we just want to ask (or insist??) that a "modern" edition of every text is available for the ease of our readers before people bring in archaic editions? Is there something I am totally missing here?--BirgitteSB 01:44, 17 March 2010 (UTC)

There's a lot of material I've done for PG with long-s, usually where I'm pretty sure there's no alternate version. A lot of low-budget scholarly reprints are done with facsimile reproductions, usually because there is no other modern edition of the text and a facsimile is better than nothing (and often better than a quick-and-dirty transcription). (I suspect a lot of this practice has or will die off, with the availability of Internet scans.)

I think saying "Our goal here is to archive whatever has been printed" is overly facile; we don't preserve pagination, lineation, or fonts. Looking at Elegie II, you evened out the spacing, adding space after commas that didn't have any following. That is, we don't preserve the archaic typography, and if this is part of it, it should go along with it. I don't see where it lets us do Elegy II Comparative text; we could do that whether or not we preserve the long-s, and it would arguably be more useful if we didn't, as substantive differences are easier to see when the superficial ones have been ironed out.

I don't think the arguments are the same at all. It's expensive to keep the long-s in proofreading, as the OCR never records it, and in fixing the text it's easier to type an s than a {{ls}} or ſ. It's a mechanical process that's practically reversible with a script and loses no information. (As Phe says, it's "tedious, prone error, [and] longer to validate".) On the other hand, keeping the original spellings is free, and changing spellings is the way that's tedious, error-prone, and makes it harder to validate.

I am actually for the conversion of archaic spellings; that once we have a good transcription of the text, we should feel free to produce an edition with modern orthography. But that's orthogonal to this discussion.--Prosfilaes (talk) 04:10, 17 March 2010 (UTC)

First of all I don't object to modernized editions, but merely do not understand why they must preclude archaic editions. Second of all I don't even object to people forgoing the long s when they find it too tedious or error prone to use. But if someone wants to take the time and effort, why override them on the texts they worked on? Must we have come to a definitive conclusion for the whole collection? Can't we say use or not as you like? Which is how we have generally approach stylistic concerns. As long is we are consistent in a given work, do we really have force the issue? I thought the point of the template was to set-up a preference to convert it for those who wanted short s, while keeping it possible to show long s preference as well. I don't understand why this compromise was not satisfactory.

Regarding the Elegy: I didn't mean to change any spacing. It was too long ago for me to remember working on, and it was all hard to do before side-by-side proofreading. Normally I wouldn't change any spacing in a poem, although I probably would in prose.--BirgitteSB 04:34, 17 March 2010 (UTC)

I didn't see this as a discussion of a mandate for the project, just best general practices.--Prosfilaes (talk) 04:44, 17 March 2010 (UTC)

My mistake, I saw mention of bot conversion, but on re-reading closer they were talking of adding the long s back after validation. I don't think that would work as it not a 1:1 conversion and there are some weird exceptions to even the standard rule. I think it should just be hashed out on the talkpage of each work amoung the collaborators whether they want to use it. Or as is more likely decided by the preference of the sole contributor.--BirgitteSB 05:06, 17 March 2010 (UTC)

I don't think bot conversion would be that problematic; I've got a copy of Mrs. Mary Eale's Receipts with the long-s, and there's 17 cases on 100 pages with the normal s followed by a letter, and half of those are transcription errors, so the bot would have been as accurate as my transcription, just erring in the other direction.--Prosfilaes (talk) 06:05, 17 March 2010 (UTC)

Source vs. product

Ok, I just realized what the real issue is: Where does Wikisource draw the line between page source, which is what we editors see, and product, which is what the readers get? With our web interface, it's no question, the template is rendered, so screen readers have no problem either way. With XML access, users will get the wikisource, and have to deal with templates in some way. Are there currently (significant) other ways of packaging our content? As long as the answer to the latter is "no", there should be no problem.

Searching may be a problem though. AFAIK, the search box provided Mediawiki operates on the source, rather than the product. Seeing as this is part of the "user experience", it probably should, by default, search content after templates have been expanded. Your thoughts? Paradoctor (talk) 11:21, 13 March 2010 (UTC)

Just saw Hesperian's remark, completely forgot that Big Brother is watching. Paradoctor (talk) 11:25, 13 March 2010 (UTC)

Summary?

Now that this discussion has cooled off a little (we even had a Godwin's Law moment), with some good points and discussion that needs having but without any real upshot, let's recap:

For demarcating long-s's

They are a distinct glyph, and should be retained, just as ß would be retained in a German text, to maintain source-text fidelity. They are especially nice when and old version has them, and a new once doesn't and you can compare.
They add information to the text. Even if most users turns them off, the fact that a long-s existed there might be useful for those who want them.

The original point of this post was to say that I hacked up a way to turn them on or off, and wanted to know what others think about that.

Even if the long-s's are not added by editors, they could conceivably be added by a script, taking into account the replacement rules.

These rules are about as fixed as the spelling in that era, i.e. not, so a semi-auto method may be needed with the editor OKing the replacements, depending on the text. More research needed into making the bot clever enough, but certainly possible.

Against

The glyph may be distinct from "s", but the meaning isn't (like ligatures), thus we shouldn't worry about them.
They are a royal pain to add by hand, and make transcribing texts unattractive to the average editor.

But if some users don't mind adding them, then there is no harm in leaving them out and waiting for a Wiki-gnome to add them.

Having "{{ls}}" littering the code makes it hard to verify against the text.

Wouldn't matter if the long-s's were added after verification

Outcomes - what is the point of all this?

Keep {{ls}} just as it is - show in page, don't show anywhere else.
Keep {{ls}} and have a way to turn it on in other namespace if you want. More thinking/research/coding may be needed.

See {{custom substitution}} for one way based on the monobook.css. I'm not sure if this is a good way to do it, but it seems to work for me.

Ditch s altogether.

What about all the long-s's marked already - seems a waste to dump them when they are already there.

Inductiveload (talk) 08:35, 22 March 2010 (UTC)

With {{custom substitution}}, there is really no reason not use the flexibility. Those who don't want to do the fiddly stuff can leave it to others, so there should be no problem. As I said above, go for it.

BTW, is there an ECMAscript that permits dynamic switching? If not, I'll make one. Paradoctor (talk) 12:05, 22 March 2010 (UTC)

The reference to ß in a German text is entirely off-point; the ß is no less a letter in German then w (vv) is a letter in English. There is no such thing as after verification in Wikisource; even the few texts that get semiprotected can still have typos fixed.--Prosfilaes (talk) 17:16, 22 March 2010 (UTC)

Yes, ß is definitely not in the same league, but it's a separate glyph the same meaning as "ss", and even is related to the long-s/s ligature, so there is some merit in the comparison, I feel. Inductiveload (talk) 23:48, 22 March 2010 (UTC)
- That's not entirely true. The ß is (historically, and you can see it very clearly in Fraktur) graphically an ſz ligature, not an ſs ligature. Logically it's a separate letter, but according to traditional German rules, if you write Gießen in all caps you have to write GIESZEN, not GIESSEN. Hans Adler (talk) 10:04, 25 April 2010 (UTC)

The second outcome is the likely one, a pragmatic approach which I favour it and I think represents the consensus here. I've had another idea on how to do it, where is the appropriate place to discuss that? Cygnis insignis (talk) 19:37, 22 March 2010 (UTC)

I would say that Template_talk:Ls is as good as any for that discussion. Inductiveload (talk) 23:48, 22 March 2010 (UTC)

I hope that upgrades can be done to the software to sidestep any conflict. There's no reason why the Unicode character itself shouldn't be a target for custom display - that's why we have Unicode, so that plain text is plain text. The reader should have a simple checkbox to display any ſ as s, with no {{ }} required, and every s should be changed to ſ. Mike Serfas (talk) 18:26, 24 April 2010 (UTC)

I, as well, wish this could be a built-in software thing. But if/since that won't happen, I think the second outcome is by far the best. I think removing the long-s all together is a mistake as it removes some of the historical milieu of the work. But I definitely understand how it might be confusing to some people and who would want the typography modernized.—Zhaladshar ^(Talk) 13:25, 25 April 2010 (UTC)

{{Dropcap}} vs {{Dropinitial}}

Both these templates do exactly the same thing, but {{dropinitial}} has more flexibility in the margins and sizing. In the interests of consistency and to reduce confusion, I recommend that {{dropcap}} be deprecated, and maybe replaced outright with {{dropinitial}}.

A straight redirect is not possible, as the size parameter is in different formats (in {{dropcap}}, it is in percent, but without the % symbol. In {{dropinitial}} it is any CSS compatible size, eg 2em, 50px, 150%, etc). However, it may be possible to easily botify the change, as the size parameter of the {{dropcap}} can be fed to {{dropinitial}} with a % sign after it. Comments? Inductiveload (talk) 08:07, 22 March 2010 (UTC)

{{Dropcap}} could be changed to something like {{Dropinitial|{{{1}}}|{{{2|250}}}%}}, which would redirect the parameters to the new template whilst adding the % sign to the size. If desired, a bot could then substitute {{Dropcap}} (caveat that it would probably need to resolve the logic with the second parameter - present for cases where the default parameter is used). Mike Peel (talk) 08:43, 22 March 2010 (UTC)

I adopted dropcap for no other reason than dropinitial didn't produce a good result in some circumstance, some time ago now, but I've followed the development of DropInitial with interest. The latter does something I wasted a lot time wrestling with, controlling the margins while keeping things 'flexible'. I linked the two as 'see also' because I'm ignorant of the subtleties in their coding. I think I got the idea it was conflicting with something when wrapped in other code, this may have been my misuse, or something in the code that has since been fixed. My concern is this: does dropinitial do exactly the same thing in the same way or does it produce a similar result by different means? Will a bot substitution of my earlier use or workarounds, perhaps misguided, produce the same effect. Perhaps a report on changes would allow users to check the results on pages that used, perhaps my concerns are baseless. Cygnis insignis (talk) 10:56, 22 March 2010 (UTC)

From a quick look, the internals look remarkably similar. We should be able to bot it dropinitial has font-size: {{#if:{{{2|}}}|{{{2}}}|3em}} which basically has a set height or a default 3em, and dropcap font-size: {{{2|250}}}%; with a default of 250%, both at 2. So wouldn't seem a major issue, we would could simply apply 250% where no second parameter exists, or where a second parameter exists we would just add a % sign to the parameter to get the same effect. After done, convert it to a redirect and that will mostly manage legacy issues of older versions by having a drop cap, but maybe not to the same size.— billinghurst sDrewth 11:57, 22 March 2010 (UTC)

See the comparison at Template talk:Dropcap. Billinghurst's direct translation will reproduce the same effect. Inductiveload (talk) 01:42, 23 March 2010 (UTC)

e where just looking for some like this into it.source. Very interesting! The problem was, how to render the image as the right character while copying/pasting the text. I could not avoid a space between the image and the text. But - if you try pasting into a text editor this text - you'll see that the first word "We" is perfect. But - it's strange - you have to select the text and image backwords (using FF): why? --Alex brollo (talk) 15:11, 26 March 2010 (UTC)

Looks to be a bug/feature in Firefox that causes it to select from the first letter in the paragraph rather than the first image if you start the selection from the left/start of the paragraph. Try starting the selection from the paragraph before, and it copies "W" OK. Probably something to file a bug report with Mozilla about at some point. Mike Peel (talk) 22:43, 26 March 2010 (UTC)

I don't think it's a bug, but it's a strange truth of FF that backward selection works universally, while normal selection fails in many cases.— Ineuw (talk) 02:11, 1 April 2010 (UTC)

I have replaced {{dropcap}} with a version passing parameters to {{dropinitial}} and marked it as deprecated. It appears to be rendering correctly:

LLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

I have stripped out the default. If no parameter was provided to dropcap, none will be passed to dropinitial, and it will default to the dropinitial defaults. If one was provided, it will be passed on to dropinitial. This is because the default size of dropcap was smaller than the "usual" drop cap found in most works. Inductiveload—talk/contribs 03:40, 8 April 2010 (UTC)

Vector is coming

Just a quick note that some time soon the Usability Initiative people will be rolling out the new interface. When that happens, all users with the default MonoBook skin (i.e. nearly all of us) will have their skin automatically switched over to Vector.

For those who haven't tried Vector, it presently suffers from the major drawback that the Page: namespace navigation arrows are put into a dropdown menu, making navigation between pages extremely tedious. I have no idea if Thomas is working on that.

Another issue is the new skin will use vector.js rather than monobook.js, so any personal scripts will need to be moved. We have been warned that there may be some temporary problems with scripts and gadgets.

If any of this bothers you, it is no big deal to go into "my preferences" and manually switch your skin back to MonoBook.

Hesperian 02:56, 26 March 2010 (UTC)

ThomasV has said in IRC (about a month ago) that the time that he has had available has been more focused on the usability initiative and related issues, rather than on improving/modifying Proofread Page matters. More than that I do not know. — billinghurst sDrewth 03:32, 26 March 2010 (UTC)

“	http://usability.wikimedia.org/wiki/Toolbar_customization . Currently this is a bit too technical, I'll work on making it more accessible this week. The ProofreadPage extension (I assume that's what you meant) has gotten some love yesterday to make it compatible with Vector and the enhanced toolbar: the arrows no longer show up in a dropdown menu and its JS doesn't break the edit page any more. These changes are currently in SVN and will hopefully go live soon.	”
—From Wikitech mailing list

There is a more substantial problem with editing in the Page: namespace using the Vector beta than just having the navigation arrows in a drop-down menu. Unless I am overlooking something, there currently is no way to display or edit the “header” or “footer” sections of the page, where we typically apply templates like {{RunningHeader}}. The text in those portions of the page is automatically wrapped in <noinclude> tags so it doesn’t get transcluded, but it is there, and can be edited by clicking on the “[+]” icon when editing the page in monobook. I do not know whether the recent ProofreadPage updates address this problem or not, but if they don’t, they should. Tarmstro99 (talk) 13:22, 7 April 2010 (UTC)

Weird line break in paragraphs with images

Need some expert advice on this one: ResidentScholar and I are trying to figure out how to properly show images in The Mathematical Principles of Natural Philosophy (1846)/Axioms, or Laws of Motion. The problem can be best seen if you scroll to page 90: there's a line break where the page break is. It seems to be due to the image. I put in a fix for the second image you see if you scroll to page 84 (under Cor. II): see Page:Newton's Principia (1846).djvu/90 and Page:Newton's Principia (1846).djvu/91 for the relevant pages. Basically, page 84 calls a section from page 85 and displays it when in the main namespace. Problem is that now in the main namespace it looks like the image and that entire paragraph are on page 84 (they aren't).

Looking at The Fight at Dame Europa's School, it seems that other folks have had this issue, but I don't remember seeing discussion about it. Is there a cleaner solution than what I've done? —Spangineer^wp (háblame) 12:47, 1 April 2010 (UTC)

In most of those cases I created an extra paragraph, for example: p. 461. In other cases, I put the image at the top of the paragraph of the preceding page (p. 423 to p. 424). However, your solution looks better... --D.H (talk) 13:20, 2 April 2010 (UTC)

Somebody please take a peek at the transcluded page now. I removed the "right" (as in div class="floatright") parameter from the images' link line, "added" span style="float: right;" for each image instead and I don't see the funky paragraph line breaks anymore. George Orwell III (talk) 08:22, 5 April 2010 (UTC)

Great, it works! --D.H (talk) 08:53, 5 April 2010 (UTC)

Nice get George Orwell III. I had never known that right inside a file was a div style, and from a quick (re)look, it isn't documented. D.H. you should be able to use {{float right}} which is our template for that formatting. — billinghurst sDrewth 09:04, 5 April 2010 (UTC)

I'm glad that it helped

George Orwell III (talk) 09:08, 5 April 2010 (UTC)

Extracting a project's proofread list

Is it possible to see a list of articles of the Popular Science Monthly project that were proofread by users other than myself but not yet validated? — Ineuw (talk) 00:14, 4 April 2010 (UTC) P.S: I don't mean the .djvu index pages with the colour codes since that would not indicate the editor.

Have you exhausted the options found in the toolbox feature, Related Changes, for the page in question already? If not, ticking Show changes to pages linked to the given page instead, hiding your own edits and playing with the few other limited settings might let you narrow down the pages or edits that others have made within the project. George Orwell III (talk) 05:02, 4 April 2010 (UTC)

George, Thanks for the direction, unfortunately, I had no luck, in extracting a list. — Ineuw (talk) 16:15, 6 April 2010 (UTC)

There isn't anything readily customisable, so you may need to try drilling down from an Index, eg. http://en.wikisource.org/wiki/Special:RecentChangesLinked/Index:Popular_Science_Monthly_Volume_3.djvu though you will still need to do visual checks looking for someone else assigning the proofread. — billinghurst sDrewth 01:39, 7 April 2010 (UTC)

I have a script that performs a similar service for myself, except that I am stalking a couple of users rather than a project. See User:Hesperian/Stack. If you wish I will tweak my script and produce the list you desire. Hesperian 02:00, 7 April 2010 (UTC)

Aha! so this is how you caught me. :-) Yes, I would really appreciate it. What I want is sometimes take a break for a change of pace and validate pages in PSM for which I wasn't the proofreader. Thanks. — Ineuw (talk) 02:21, 7 April 2010 (UTC)

I've put a list at User:Ineuw/Proofed PSM pages. Poke me when you want it updated. Hesperian 02:34, 7 April 2010 (UTC)

This is great. Thanks. — Ineuw (talk) 14:04, 7 April 2010 (UTC)

Process for creating new book?

Some time ago, I transcribed (although didn't proofread) a religious text published in the USA in 1840 by a small Christian denomination. Would such a work be acceptable here? Moreover, I get the impression that WS policy requires images of all pages of works published here. Is this correct? I don't have steady access to a scanner, but I can photograph pages of the book and upload them to Commons; is this acceptable? Nyttend (talk) 16:13, 4 April 2010 (UTC)

En.WS policy doesn't require images of all pages, though it is nice so that someone can verify the proofreading. Any text published prior to 1923 is fine.--Prosfilaes (talk) 18:19, 4 April 2010 (UTC)

If the photographs will allow proofreading, that seems an excellent solution. If you are going to do that, it would be worthwhile talking to Mattwj2002 (talk • contribs) as he loves the challenge of working with images for the conversion to DjVu files. — billinghurst sDrewth 06:12, 5 April 2010 (UTC)

Nyttend, once we get the images I can easily do the converting to a DJVU for you. It doesn't take much. What is the name of the text? Is it a cookbook by chance? :) I know a lot of country churches publish cookbooks for fundraisers. :) Please let me know what I can do to help. --Mattwj2002 (talk) 10:17, 5 April 2010 (UTC)

You want details, you get details :-) The book is far from being a cookbook — it's the church's theological testimony, kind of their elaboration on and expansion of the w:Westminster Confession of Faith. The denomination was the "Reformed Dissenting Presbytery" or "Reformed Dissenting Presbyterian Church", although that name only appears about once in the book, while the first name is quite common (if you want to read more, see this page and the following one), which existed in the upper Ohio River valley. The title is A Narrative of the Introduction & Progress of Christianity in Scotland Before the Reformation: and of the Reformation, and the Progress of Religion, Since, in Scotland and American, Especially Among Presbyterians. There are 128 pages in total. I have a physical copy of the book easily available, so I'll try to photograph and start to upload today. Nyttend (talk) 12:02, 5 April 2010 (UTC)

I have created A Narrative of the Introduction & Progress of Christianity in Scotland Before the Reformation as a stub for you, click to it and click "Edit" to begin adding in the text of the book itself :) Note that pages 87-127 appear to constitute a second work printed in the same booklet, so we may want to export those pages to An Act, declaration, and Testimony, of the Reformed Dissenting Presbyterian Church in North America. Sherurcij ^{Collaboration of the Week: Author:Thomas Carlyle.} 11:14, 6 April 2010 (UTC)

Okay, thanks. Upon looking for the book, I can't find it quickly, so I'll have to do a more in-depth search. Now I'm curious, however — how were you able to find the information that I didn't give you? I didn't know that there was anything available online about this book! The copy I have is by a different printer: it was printed in 1839 by James Smith of w:West Union, Ohio. Nyttend (talk) 04:08, 7 April 2010 (UTC)

Just after I wrote the note above, it occurred to me to look somewhere I'd forgotten before, and the book was there. I'll try to start getting pictures tomorrow. What resolution of pictures is best? As to the work itself — we might do better to call it "Testimony of the Reformed Dissenting Presbytery". It's a two-part work, with the first ("A Narrative...") being the historical part and the second ("An Act...") being the doctrinal part. My copy is a single bound volume, and the general practice by small Presbyterian denominations was to have two-part testimonies like this (the w:Reformed Presbyterian Church of North America did the same thing, for example) that were viewed as The Testimony, not The Testimonies. Nyttend (talk) 04:26, 7 April 2010 (UTC)

Nyttend, if you want to create a zip of JPG files and send those to me I can work with those. If you want to create a high quality PDF under 100 MB I can work with that as well. A PDF under 100 MB could uploaded to the Commons. A zip file full of images we would need to find another way to transfer. My biggest concern is that the quality is as high as possible. :) Please let me know what you decide. Feel free to leave me a message on my talk page. --Mattwj2002 (talk) 10:54, 7 April 2010 (UTC)

Nyttend, try uploading the zip of jpegs to rapidshare and e-mail me the link. I'll send you my e-mail address. The zip will have to be under 200 MB though. --Mattwj2002 (talk) 23:19, 7 April 2010 (UTC)

Interwiki to old WS?

Anyone know if we can create a language interwiki to oldwikisource:? Need to create one at Author:Kabir. If not, what is the process for getting the code created? — billinghurst sDrewth 14:51, 5 April 2010 (UTC)

Why not move content from there to here? JeepdaySock (talk) 16:33, 5 April 2010 (UTC)

The complete collection of pictures & songs by Randolph Caldecott

The complete collection of pictures & songs by Randolph Caldecott is now available on Commons. Hope you find good use for it... commons--Diaa abdelmoneim (talk) 10:31, 6 April 2010 (UTC)

Index now at Index:The Complete Collection of Pictures & Songs by Randolph Caldecott.jpg. I tried to DJVU'ify, but the quality was terrible, so I used the JPGs instead. Enjoy! Inductiveload—talk/contribs 02:56, 8 April 2010 (UTC)

Rotating Djvu file

Does anyone know how to rotate a Djvu file? I can't figure out how to do it using Djvu Solo 3.1. The goal is to rotate this file 90 degrees clockwise, save it that way and upload it again, so that it will appear correctly as default in thumbnail images, etc. I anyone knows how that would be great. Dovi (talk) 02:39, 7 April 2010 (UTC)

Hi! There is no way to do it in place, as far as I know. I can do it quickly with an automated image editing tool, and I can split the pages down the centre to make a page in the DJVU equal a real page. However, that DJVU is quite low quality, and is only 3MB. Commons accepts up to 100MB, so there is plenty of room for extra quality. If I could have the original scans as JPG or TIFF or a higher quality DJVU, I can split them for you, rotate and upload a much better version. You could upload to Commons, or, probably better and much easier, zip them up and put on a temporary hosting site like Megaupload and give me the link. Cheers! Inductiveload—talk/contribs 01:51, 8 April 2010 (UTC)

Thanks for your reply! The original scans were done directly from the book itself to Djvu using Solo 3.1, such that the file you see is the original one. It is extremely clear even when greatly enlarged, so quality is not a problem.

So can an automated image editing tool work directly on Djvu images? As far as splitting the pages down the middle that would be great if there is a way to do it without too much labor. Dovi (talk) 03:50, 8 April 2010 (UTC)

This may be a very late response not having noticed this post. If you are using Windows, IrfanView rotates images very easily, by any increment from 1/100° to the preset 90° left or right. - Ineuw (talk) 13:58, 29 April 2010 (UTC)

w:XnView appears to be faster, and has more bells and whistles. Paradoctor (talk) 16:04, 29 April 2010 (UTC)

Recurrent whole paragraphs with minimal differences

Moved here from a user's talkpage since Scriptorium is a more appropriate forum...

...I was wondering if you could point me in the right direction with the following issue: particularly in the Private Acts sections of the US Statutes at Large Vol. 33 such as here, endless increases (or sometimes grants) in pension are found, using essentially boiler plate language, with only a few variables, such as:

name of grantee

increase or grant

date of grant

amount of pension

quality of grantee (usually a veteran or widow)

A very few deviate from the standard by also having provisos such as increase to be rescinded on death or majority of minor child or suchlike. Can you think of any way that I could semi-automate this process, I assume off-line? Names at least can be culled from the index into a merge-list almost by hand - slow, I know, but much quicker than laboriously correcting and proofing 400-odd pages of semi-identical text!

Thanks, and sorry to bother you! CharlesSpencer (talk) 17:45, 19 March 2010 (UTC)

Something like that could be turned into a template fairly easily, you would need to identify the standard text and the variations and the place of the variations. Even if you start with the basic variations, and more can be added as you identify more. Start a page in your user space, and you can point some of us at it, though probably more useful to do that from WS:S rather than from John's talk page. — billinghurst sDrewth 23:59, 6 April 2010 (UTC)

Thanks Billinghurst - duly moved here from John's talkpage. Does this do the trick in terms of template? It should cover grant, increase and increase with proviso, as per chapters 8 and 9 here, and chapter 20 here. I'm afraid I have no template or regex(?) experience at all, so any help from here would be welcomed! CharlesSpencer (talk) 11:08, 7 April 2010 (UTC)

Did the basic framework of a template, and a place where you can play with the variations, and we should be able to better define for interrelationships. Have a play there and see how you go. — billinghurst sDrewth 12:45, 7 April 2010 (UTC)

Vector and it.source

Is there a page to discuss & share source-specific troubles & tricks to customize js scripts to Vector for general, and project-specific, requisites of source projects, or at least to list the links to the most interesting pages where such issue is discussed? It would be great if en.source could be a reference project during this difficult transition. Thanks! --Alex brollo (talk) 12:28, 8 April 2010 (UTC)

Not yet that I am aware. Personally, I am just going to drop back to monobook until all the dust has settled, the major scripts have been adapted, and I will look at it then. — billinghurst sDrewth 22:55, 9 April 2010 (UTC)

I too. I can't wait for Regex menu framework update for Vector... aren't you that gave me that excellent suggestion? Please let me know as soon as the new version is running, if you can! --Alex brollo (talk) 14:46, 12 April 2010 (UTC)

Update. Regex menu framework works simply posting the scripts into your User:username/vector.js. Toolbar costomization is far from difficult; I successfully added some personal buttons to it. I'll move my it:User:Alex brollo/vector.js page here into User:Alex brollo/vector.js, just to see if it runs here too. Let me know about your WIPs please! --Alex brollo (talk) 12:12, 16 April 2010 (UTC)

What's happened to page editing?

Has something changed? Up until yesterday, when I opened a djvu page, such as this one for editing, I was able to use the mouse wheel to zoom in and out of the image. Now I find this has stopped working, indeed I seem to get unpredictable behaviour. If something has been changed can it be reverted please?

More information: I use Windows XP Pro SP3 and Firefox 3.6.3, and I've edited succesfully since either of them was updated. Jan1naD ^{(talk • contrib)} 11:23, 9 April 2010 (UTC)

>There's been a code update today. The mouse wheel now scrolls the image; this was a feature requested by many users. To zoom, click in the image first. You may then zoom with the mouse wheel, or drag the mouse to select a rectangular region to zoom into. ThomasV (talk) 12:23, 9 April 2010 (UTC)

You say "many users" - please supply reference. And how do I go about requesting a reversion? The previous behaviour was highly intuitive, including the ability to drag the image around to the desired position. The current behaviour, as well as being more clumsy, is difficult to use because of the delay between clicking the mouse and the image noticing this. So, is there a forum where "many users" can ask for reversion? Jan1naD ^{(talk • contrib)} 12:37, 9 April 2010 (UTC)

I'm trying to give it a go, I really am, but then, for no apparent reason, it blows up to a ridiculously large magnification, and I can find no way of getting it back to normal without abandoning the edit. Please help. It's getting near to the point that I'm seriously considering giving up on Wikisource, which would be a shame, not least for me. Jan1naD ^{(talk • contrib)} 12:58, 9 April 2010 (UTC)

I'm not seeing that problem. Which browser are you using? Cygnis insignis (talk) 13:39, 9 April 2010 (UTC)

See above. Jan1naD ^{(talk • contrib)} 13:41, 9 April 2010 (UTC)

Sorry, I noticed. I was just removing the question and conflicted. Cygnis insignis (talk) 13:44, 9 April 2010 (UTC)

I just checked this out. it seems fine so far. This is 'intuitive' in that it makes the behaviour consistent and predictable once used, and scrolling is very widely used. There has been discussion about this, previously the behaviour was dependent on the editing mode the user selected, wide or side-by-side, and different again to the read-only mode. There is a lag in the old system too, grabbing and pushing the page up to check the bottom seems to take more time than the current scroll method. I often miss things in edit mode, only noticing when it returns to the full view in read mode, the time taken for the image to load and render is a big factor for contributing - I think this is 'working' in that regard. Cygnis insignis (talk) 13:39, 9 April 2010 (UTC)

Add: another feature I discovered is that clicking once allows zooming to a rectangular selection of the page. Cygnis insignis (talk) 13:58, 9 April 2010 (UTC)

To help me, can anyone answer these questions?

How can I be aware of code updates?
What is the forum for requesting code changes?
How can I get a usable page editing facility?

Thanks. Jan1naD ^{(talk • contrib)} 13:52, 9 April 2010 (UTC)

for your points 1 and 2, see oldwikisource:Wikisource:ProofreadPage and its discussion page.

to get back to the original magnification during editing, click on the magnification glass icon.

ThomasV (talk) 16:13, 9 April 2010 (UTC)

I just installed firefox 3.6, and I agree that the mouse wheel zoom is unacceptably slow. I am investigating the best way to fix it. In the mean time, you may disable it by setting "proofreadpage_disable_mousewheel=true" in your javascript configuration. ThomasV (talk) 20:51, 11 April 2010 (UTC)

In reply to Jan1nad above and Ineuw below: I don't remember if I'm one of the users who complained about what is now referred to as the "old" way of editing in the page namespace, but when it was first implemented I gave up using the side-by-side layout and switched to horizontal by default. It made no sense that scrolling did not make the image scroll, and grabbing/zooming was a hassle when all I wanted to see was the bottom half of the page I was proofing. Of course, monitor size combined with the font size of the book might make zooming necessary, but for the monitors I use and the works I edit, I don't experience that very often. To me, this switch is a return to the better way to edit in the page namespace, with the added feature of easy zooming (namely, click and scroll). Give it a chance, and try the horizontal layout as well; maybe it'll grow on you. —Spangineer^wp (háblame) 21:12, 11 April 2010 (UTC)

Can we implement a javascript solution, so that individual editors can edit according to their preferences for how the tools will work? BD2412 T 00:30, 12 April 2010 (UTC)

I've had a good go at this and don't find it intuitive. I'll bet many users would be the same. In the mean time this should be turned off and a setting in my preferences/gadgets to enable. Moondyne (talk) 01:55, 13 April 2010 (UTC)

I think if scroll wheel zooming wasn't dysfunctionally slow, I would have adjusted to the changes and be happy with them by now. I do like the fact that my scroll wheel now scrolls. Hesperian 02:00, 13 April 2010 (UTC)

Patrolling recent changes is having issues (lodged in Bugzilla)

In undertaking patrolling of edits, I am getting a failure message, though on checking logs, it shows that the edit is working. I have lodged a bugzilla request for a fix, see https://bugzilla.wikimedia.org/show_bug.cgi?id=23132 — billinghurst sDrewth 04:24, 10 April 2010 (UTC)

Using mouse wheel to magnify OCR image

Is it possible to revert to the old way of resizing the OCR image in the side by side edit pane? The new system of varying the image size by the use of the center wheel + click is more complex, slow, and inaccurate. Are these changes necessary? Or, is there an assumption that text is being proofread too quickly? Or, are we soon going to run out of proofreading material and the plan is slow the process??— Ineuw (talk) 17:18, 10 April 2010 (UTC)

P.S: I just noticed the previous post, What's happened to page editing?. I consider this issue to be serious. Too many unnecessary changes. It's my turn to write Why ... Can't we leave well functioning features alone? There is a difference between programmers and users. — Ineuw (talk) 17:25, 10 April 2010 (UTC)

Following various reports of zoom slowness with firefox 3.6, I temporarily disabled wheel zoom on this wiki.

Users can override this in their javascript see here

Other zoom methods (toolbar buttons or region selection) are still available.

Note that the problem has been fixed in svn and the fixed code waits to be deployed.

ThomasV (talk) 08:52, 13 April 2010 (UTC)

Hi ThomasV. Some additional info: Tested IE6 where the wheel zoom is equally slow. (Win XP SP3). Also tried changing the about:config wheel settings, in both FF 3.6.3 and Minefield (FF3.7pre5), but there is no change.
As recommended, the header/footer display is on in Gadgets, without which the custom toolbar doesn't appear. On the first page opening for edit, it loads very slowly. On second try, both the image and the toolbar load instantly. Is this a cache issue? Is the OCR image transcluded from Wikimedia Commons? Also noticed that there is a relationship between the appearance the custom toolbar and the OCR image load.
I know that you are working on resolving these issues and if it saves you time, I gladly volunteer to test whatever you want in Win XP.— Ineuw (talk) 00:26, 14 April 2010 (UTC)

I believe that I have fixed all the issues that have been reported. The fixed code still waits to be deployed, though.

you can always test the code it you care to install the latest version

ThomasV (talk) 09:01, 17 April 2010 (UTC)

Right way to index JPEGs

What's the right way to set up a short Index for a couple of JPEGs? I'm thinking of doing Presidential Proclamation No. 94 of September 24, 1862, by President Abraham Lincoln suspending the writ of Habeas Corpus since various other works mention it already.

ARC Identifier 299959 / MLR Number A1 24

George Orwell III (talk) 07:48, 17 April 2010 (UTC)

Manually set up an index file, so Index:Working name.jpg and then manually set them rather than utilise <pagelist />, eg. Index:The Complete Collection of Pictures & Songs by Randolph Caldecott.jpg — billinghurst sDrewth 10:14, 17 April 2010 (UTC)

Author name resolution in PSM

The author of this article is listed as Alfred E. Wallace, which is to me is an obvious mistake, and would like to change it to Author:Alfred Russel Wallace in the main name space title header. Can anyone provide some pointers as to how to handle such errors, as there are numerous and expect to increase as time goes by? — Ineuw (talk) 01:41, 22 April 2010 (UTC)

I suggest just correcting it in the header, and making a note about it in the "notes=" parameter about the mistake. I at least don't consider {{header}} to be part of the work, so there's no need to preserve incorrect information.—Zhaladshar ^(Talk) 03:09, 22 April 2010 (UTC)

The E. is a OCR error. It is R. in the text.--T. Mazzei (talk) 03:33, 22 April 2010 (UTC)

Thanks for both responses. Must need new glasses. :-)— Ineuw (talk) 13:38, 22 April 2010 (UTC)

Question about illustrations

Hi, I am going to publish on WikiSource a scientific paper that had captured some attention in it's time. It includes about 10 illustrations - graph and pictures. It is rather unlikely that these illustrations would ever be reused outside of the article. Should I upload the images to Commons or WikiSource ? Svobodat (talk) 07:20, 24 April 2010 (UTC)

Commons. Our practice is to load at Commons, unless Commons cannot host them. Part of our reasoning would be that it is (wildly) possible that any of the language WS communities may wish to translate the paper and to access the images they need to need to be at Commons. — billinghurst sDrewth 12:38, 24 April 2010 (UTC)

Purge clock

In the Vector skin the font of the "Clock and Purge" gadget is too large. Can anyone fix it, please? Thanks in advance. --Amir E. Aharoni (talk) 18:35, 24 April 2010 (UTC)

Help us out, anywhere that you use where you see it working fine? not used vector and in no hurry to change. — billinghurst sDrewth 18:47, 24 April 2010 (UTC)

It seems to work correctly in Commons. --Amir E. Aharoni (talk) 19:00, 24 April 2010 (UTC)

Done — billinghurst sDrewth 01:07, 25 April 2010 (UTC)

Another Vector related visual matter

100% = Thanks for the Clock purge size fix. Another change noticed with Vector use is that a reduced (90%) font size is not as noticeable as it is with Monobook. When time permits, perhaps someone can take a look at it?

90% = Thanks for the Clock purge size fix. Another change noticed with Vector use is that a reduced (90%) font size is not as noticeable as it is with Monobook. When time permits, perhaps someone can take a look at it? - Ineuw (talk) 15:52, 25 April 2010 (UTC)

The style of vector is exactly that. Two choices, swap back to monobook, or to edit your own. I don't think that playing with the global file is beneficial. — billinghurst sDrewth 18:09, 25 April 2010 (UTC)

PSM authors list

Prepare thyselves! This is the beginning of a possibly long post to which I will progressively add questions, the first of which is technical.

How can links to Wikipedia display accurately the non/existence of an article? Currently, links in this table are displayed as existing but many do not. - Ineuw (talk) 17:24, 25 April 2010 (UTC)

At this stage there is no ready means, though I saw that the programmers are planning on some sort of x-wiki x-links, and we have to await that being rolled out. — billinghurst sDrewth 18:11, 25 April 2010 (UTC)

Plus my personal preference is that it should not matter. Locally we should link to our author page, and from author page we would like outwards to WP. From the author pages we simply check and test. — billinghurst sDrewth 18:14, 25 April 2010 (UTC)

Thanks for the clarifications for this, and my previous post about the font size change. - Ineuw (talk) 15:02, 26 April 2010 (UTC)

Is there any way to get folks to utilise the Summary box when creating new pages by simply adding a single word, such as "created", instead of having the long default descriptions appear when it is left blank? Could make for easier patrolling IMHO. George Orwell III (talk) 22:31, 27 April 2010 (UTC)

Mea culpa. Will do. - Ineuw (talk) 06:22, 29 April 2010 (UTC)

Adding a translation to new texts

How do you add a translation to template:new texts? I've just added a translation of Pangur Bán (see the Wikipedia article w:Pangur Bán). —innotata (Talk • Contribs) 20:39, 27 April 2010 (UTC)

No, this one provides full source information, so it has no copyright issues. —innotata (Talk • Contribs) 22:35, 27 April 2010 (UTC)

The original of this was by an anonymous monk, while the translation is from 1903, by authors who died over a hundred years ago. —innotata (Talk • Contribs) 22:37, 27 April 2010 (UTC)

Understood and indeed not the same in that regard - but I have feeling that the latter is just a matter of improper header info and that's why it's not associated with the main work. Sorry for the mix-up. George Orwell III (talk) 22:40, 27 April 2010 (UTC)

The German Text to A Mighty Fortress is Our God is just a German text already at de:Ein feste Burg ist unser Gott, so it can be deleted. Is something wrong with the header for Pangur Bán? I don't get what you're saying. —innotata (Talk • Contribs) 23:50, 27 April 2010 (UTC)

I made a slight modification to the new texts template to make it be able to handle this more easily. You can now use code like:

{{New texts/item|Pangur Bán|Anonymous, tr. [[Author:Whitley Stokes|Whitley Stokes]] and [[Author:John Strachan|John Strachan]]|1903|nowiki=yes}}.

You get:

Pangur Bán (1903)

by Anonymous, tr. Whitley Stokes and John Strachan

—Spangineer^wp (háblame) 23:01, 27 April 2010 (UTC)

I added it just as you suggested. —innotata (Talk • Contribs) 23:42, 27 April 2010 (UTC)

Passages in the Life of a Philosopher

Don't know what to make of this page. Thought it should be a speedy delete but apparently some projects are linking to it. Thoughts? George Orwell III (talk) 22:05, 27 April 2010 (UTC)

A real title, a redlink to a work by Babbage, that someone filled in as a test. I deleted it. Cygnis insignis (talk) 22:17, 27 April 2010 (UTC)

thanks George Orwell III (talk) 22:45, 27 April 2010 (UTC)

Wikimania 2010

Wikimania 2010, this year's global event devoted to Wikimedia projects around the globe, is accepting submissions for presentations, workshops, panels, and tutorials related to the Wikimedia projects or free content topics in general. The conference will be held from July 9-11, 2010 in Gdansk, Poland. For more information, check the official Call for Participation. Cbrown1023 (talk) 22:22, 28 April 2010 (UTC)

Choosing a text to upload

I can't find anywhere how to choose a dejavu to upload. Some are obviously higher quality than others, but what should one do when there are scans available in both color and black and white? In this case http://www.archive.org/details/cu31924014025138 vs http://www.archive.org/details/korea00hami thanks and regards, NativeForeigner (talk) 00:24, 29 April 2010 (UTC)

My suggestion is go with the whiter copy. The color you are seeing is likely a product of the decay of the paper itself. While it doesn't matter one way or another which one you upload, the whiter copy is closer to how the paper originally looked, and in my opinion is always a little better to look at.—Zhaladshar ^(Talk) 00:56, 29 April 2010 (UTC)

Yes, in his case both copies are "in color," as you can see from the cover. If one copy were in color and another were in black and white with higher resolution, first I would see whether the lower resolution had any impact on readability. If not, it remains an interesting question. I don't think there is any preference as far as color vs. resolution goes. It is a matter of taste, and I'm not sure it can/should be dictated by Wikisource policy. --Eliyak T·C 02:10, 29 April 2010 (UTC)

In general I prefer MSN versions, because they don't have watermarks (except on some of the first pages), while Google works have them everywhere. In your case both are MSN versions though so just pick the one with the color you prefer (personally, I think I like yellow better). —Spangineer^wp (háblame) 04:56, 29 April 2010 (UTC)

We really should be putting together Wikisource:DjVu files/How to choose a text-image file (or something similarly named) as there are a number of considerations, and it is part art, and part science. For me, the things that flit through my head when choosing are (and these need to be expanded):

Completeness - all pages, and all readable
OCR and scan quality (high quality B&W from a quality material make great OCR; however, if not high quality scans, not great source material then the grey scale are generally better for OCR
Whether it has images that need reproducing, and are they colour or B&W in the scan; should we look at a mix and match if colour images are involved.
Relevance of the edition, where I try to pick the definitive volume, usually first, though not always; at the same time some of the later illustrated versions make better exhibits
Watermarks, though that is a lower consideration for me
Has it been transcribed elsewhere, and can we match a text and image together for presentation.
+++++

For me it is the balance of these, and as Eliyak said, it is not a policy matter alone. While what I do look out for is those works scanned at University of Toronto, as they were seemingly scanned with diligence. — billinghurst sDrewth 06:21, 29 April 2010 (UTC)

Wikisource:Scriptorium/Archives/2010-05

Contents