User talk:Ineuw/Archives/2022-12-31

Images for Index:The Posthumous Papers of the Pickwick Club.djvu

Seeing how nice your images for The Count of Monte-Cristo look, I was wondering if you could also do the plates for Index:The Posthumous Papers of the Pickwick Club.djvu when you have a chance. Fun fact, this particular copy has plates that no other copy in the world has. Languageseeker (talk) 00:46, 9 December 2021 (UTC)

@Languageseeker: I am downloading the files as we speak, but I must look at them if I can do a decent job, and get back to you.— Ineuw (talk) 04:12, 9 December 2021 (UTC)

@Languageseeker: uploaded 20 of the ~45 images to commons:Category:Posthumous Papers of the Pickwick Club (Book). But the rest will have to wait. Also,

Thank you! Languageseeker (talk) 00:47, 23 December 2021 (UTC)

Done.Ineuw (talk) 08:14, 10 January 2022 (UTC)

Lost in Space Episode 1:Proofread page changes

@Inductiveload First, apologies for my comments on Phabricator. They were the result of the shock experienced by unexpected changes and being unprepared for them. Also, thanks for the corrections, which I assume, were made based on my comments in the scriptorium.

I suggest that, if over/under editing in the previous manner is no longer available, consider dropping it altogether because it is useless and visually confusing as it's implemented.

Over/under editing is true WYSWYG line by line without wrap edit, which is now lost (even without vector.js and .css). Comparing the scanned text to the original line by line without wrap, was logical. Ineuw (talk) 23:03, 22 December 2021 (UTC)

@Ineuw I understand that you are frustrated, I am too. I'm not quite sure what you mean by corrections, but if you mean the scrolling stuff, then I hope the proposed patch is what you have in mind, and I hope that someone eventually merges it. I don't know if it's the ideal UX, but since you are the only person to even somewhat engage with the question, I guess that everyone else thinks it is fine.

As I have said many many times now, the H/V issue has been fixed and was actually fixed on the day that the issue was reported. The fix just wasn't merged for a week and change. To be clear, I did not write the fix, but I did +1 it ASAP to try to get it in so I could have it backported. I do not have (or want, actually) the ability to +2 it to actually merge it. The delay means it missed all the opportunities to deploy the change because there are no deployments at all scheduled this week or next, or even backport windows, due to the holidays.

if over/under editing in the previous manner is no longer available, no one is saying this and it is IMO unhelpful to act like that's what is happening. There was a bug, it was fixed on the day, and the fix is coming. In two more weeks: it is expected to deploy late on 5th Jan (n.b. every time I give a deploy date, the train ends up being blocked, or cancelled entirely). It could have been two weeks ago (the patch was available, substantially as eventually merged, exactly 14 days ago today), but it was not to be. If it had merged literally any day before last Friday, it would have been possible to deploy the fix as a backport. It did not, and now, it is not. Frustrating, yes, but that's what happens when there are no formal resources for these things. Inductiveload—talk/contribs 00:26, 23 December 2021 (UTC)

@Inductiveload: Much thanks for this detailed explanation and your patience. Patience is something I am still learning.

@Inductiveload: What is interesting about the scrolling issue is that in Firefox, the cursor navigates the image as if I was scrolling. Unfortunately, this requires a change from mouse to keyboard. It is just an observation.Ineuw (talk) 12:52, 26 December 2021 (UTC)

Full keyboard navigation is another thing OSD has permitted. The full keymap is here mw:Extension:Proofread_Page/Page_viewer#Keyboard_navigation. Inductiveload—talk/contribs 22:16, 26 December 2021 (UTC)

How we will see unregistered users

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:14, 4 January 2022 (UTC)

Lost in Space Episode 2:Proofread page changes

Episode 2:Proofread page changes this link to my post in the scriptorium Ineuw (talk) 04:53, 27 January 2022 (UTC)

Lost in Space Episode 3:Proofread page changes

@Inductiveload: The recent changes in the new Proofreading module seriously reduced my ability to contribute.

• The inability to scroll the image during editing is the ultimate loss. It was a most valuable tool. Scrolling and comparing the generated text, while matching it to the original, row by row, character by character, was invaluable in over/under editing mode.

• I tried side by side editing, but this also needs the image scroll to read the text. In addition, the text to be edited is also wrapped because the width of the editing window is narrower than the text.

• The contributions log is a witness to my efforts to reconfigure vector.css. Starting with a blank slate, meaning wmf defaults, and then, rebuilding changed font sizes, margins, textbox and header and footer box sizes to conform to the current modes, but nothing helped.

• The header/footer settings of Preferences/Edit is functioning in the French Wikisource. Are we not sharing the same Proofreading software? Perhaps, this setting was stored in cookies?Ineuw (talk) 04:48, 27 January 2022 (UTC)

I think I have made it repeated clear enough why the scrolling isn't implemented yet: the code wasn't reviewed and therefore isn't merged. Actually, a comment has come along since then, but 1) actually doing what that comment suggests is now a lot of work because it should have been said months ago before more work was done on top of it and 2) the patch no longer applies anyway because it needs rebasing. I do not have time now to deal with that long and unreasonably painful process. Hopefully someone will, but it won't be me for quite some time, unless you wish to buy out my contract from my employer. I did not expect when I started trying to build on OSD back in about June that hardly any of it would get looked at until I ran out of time in the new year, but here we are.

Header/footer toggling is working as far as I know. In my reply to the link above, I specifically told you it's stored in user option settings (you can see the current value with mw.user.options.get("proofreadpage-showheaders") in your browser's JS console). Nothing has changed with this setting recently, other than its location in preferences is now in "Preferences → Editing → Proofreading interface options". You'd only have seen it in preferences at all if you turn the edit toolbar off, otherwise it's where it always was, a icon in the "Proofread tools" sub-toolbar). Inductiveload—talk/contribs 10:45, 27 January 2022 (UTC)

@Inductiveload: Thanks for the update. I was expecting scrolling with the latest rollout. In any case, you have your work cut out.

I added mw.user.options.get("proofreadpage-showheaders") to my vector.js, and this works fine. This used to be controlled from the Preferences/Edit Menu, and is no longer there. I am using the sub-toolbar's manual header/footer control, but that is not what I was looking for. In any case, it is now resolved.

This is what my Profile/Edit Page looks like. Profile Edit options, I don't understand why there are two "Set a local Exception for this Global Preference" in the Proofreading Interface Options? What Options are being referenced? Ineuw (talk) 21:30, 27 January 2022 (UTC)

It sounds like you have somehow set a global preference, which you can change at Special:GlobalPreferences. "Normal" preferences look something like this: phab:F34936584. Inductiveload—talk/contribs 15:09, 30 January 2022 (UTC)

Page:The Conquest of Mexico Volume 2.djvu/483

Hi. Could you explain your thinking in formatting the index for this text? I see you put quite a lot of effort into its current state, but it doesn't seem to match what was actually published (but older revisions of these pages did match the scan). What was it you were trying to achieve there? Xover (talk) 15:24, 25 August 2022 (UTC)

@Xover: Sorry, but I have no clue to what you mean by "(but older revisions of these pages did match the scan)"? Can you please clarify? This is a five year old edit. — ineuw (talk) 17:23, 25 August 2022 (UTC)

I mean that the current revision splits each referenced page into a separate line, duplicating the headword for each page; but the earlier ("Under construction"/Not proofread) revisions of it match the scan (i.e. without these changes; see e.g. this old revision). Xover (talk) 17:32, 25 August 2022 (UTC)

At that time, I didn't know how to create a three column page, so I changed it to be more readable since I couldn't link the entries to the subject. — ineuw (talk) 18:21, 25 August 2022 (UTC)

Hmm. Ok, so it was a workaround rather than a goal in itself? So you would then perhaps not be averse to changing back to the original formatting (and in the process getting rid of the table-based formatting)? I'm asking because the long table with multiple {{ts}} template invocations is running into MediaWiki software-defined hard limits for execution time (a single page can only execute Lua code for a maximum of 10 seconds during rendering), so depending on the server load when the page is edited it periodically ends up with broken tables and big red error messages displayed. Xover (talk) 18:45, 25 August 2022 (UTC)

Of course I will redo it. Especially now that you mentioned broken tables. Please let me know where I can find the logs in which it is recorded. I already learned to fix then on my other projects. I also use different and simpler column templates for this. I will post a link later and pls tell me if it is acceptable. — ineuw (talk) 20:44, 25 August 2022 (UTC)

@Xover: Let me know if this format is acceptable. — ineuw (talk) 04:44, 26 August 2022 (UTC)

That format will avoid the technical problem with the tables. But it can also be further simplified. First because the general practice is to not reproduce multi-column layouts for this kind of thing (indexes generally don't need it and it's just a space-saving measure relevant for paper that is irrelevant in a digital medium, and it tends to cause problems on mobile devices and other places where width is constrained). Second because you can simply format it like this:

Source	Rendering
… Awash River, 379 Azania, 382 Babakoto Indris, 446 Ba-Bwero, 20 …	… Awash River, 379 Azania, 382 Babakoto Indris, 446 Ba-Bwero, 20 …

That is, one blank line between lines within a letter group and two blank lines between letter groups. This is very simple and straightforward when you're proofreading/formatting, and because it is so simple and uses no templates etc. it is extremely unlikely to run into any technical limitations or template problems. I'm quite fond of fancy formatting myself, but for this particular use case I think the simplicity and robustness far outweigh any other concerns and I strongly recommend it. It also combines well with, e.g., using {{gap}} or {{left margin}} for indents, or {{hin}} for a hanging indent (as the Conquest of Mexico does).

The logs for the issue are unfortunately restricted to (WMF) developers only, but when it happens it will add the page to Category:Pages with script errors (and if you enable showing hidden categories in your Preferences you can the category on the page, below the normal categories). This can be intermittent (come and go) for pages that are in the borderline: if the servers are under heavy load when the page is rendered it hits the timeout, and if they're lightly loaded it manages to squeak in just under the limit. For example, The Conquest of Mexico/Volume 2/Index 1 currently ends up generating 3940 calls to {{ts}}. If each of those calls takes 2.5ms it will hit the limit, but if they take just 2ms it probably won't (other templates need to be considered too, but on this page they are a minor factor). The Conquest of Mexico/Volume 2/Index 2 generates 3602 calls, which hits the limit at around 2.75ms per call, which in practice is the same situation.

I'm working on what optimizations I can in the on-wiki code to try to minimize the problem, but for things like this (many thousands of calls to a single template) it's always going to be a problem. --Xover (talk) 08:45, 26 August 2022 (UTC)

┌─────────────────────────────────┘
Your explanation is a gem. I can't thank you enough for answering many unasked questions I've had since the beginning. My real concern was again visual. It was about smaller font size and matching line height. These tables are constructed around the proofread text in a text editor with regex search and replace and macros. I am a big believer in automating repetitious tasks. Reversing the process is very easy, but I prefer to use the {{multicol}} format when there are more columns. I was surprised to see how well the page by page continuity displays in the main namespace. Also, my current experience with community network printers, and printing also alerted me to focus on printing and ePub as well. — ineuw (talk) 19:38, 26 August 2022 (UTC)

@Xover: When looking over the books, I remembered that the indexes are supposed to be linked and anchored to the text references. This was the Magnum Opus in English for User:Gumr51 where he tagged every reference to the text body and I was supposed to link the indexes to the reference for a two way lookup. He completed his task but I didn't. That is why it was designed so. To eliminate the {{ts}} calls, I terminated each table on its page. Years ago is how I was taught to create continuous tables for the main namespace, and it took me this long to very this. Now I looked at the main namespace, it looks just as continuous. Can I complain? On the other hand, Thanks for the reminder that I must complete this incomplete task. — ineuw (talk) 01:28, 29 August 2022 (UTC)

@Ineuw: The problem isn't the tables as such, but rather the use of a table forces the use of {{ts}} for formatting. The Conquest of Mexico/Volume 2/Index 1 currently ends up calling {{ts}} 3949 times, and the accumulated processing time for these is somewhere north of 10 full seconds. Since MediaWiki sets a hard limit of 10 seconds for this kind of processing, the rendering of the transcluded page is going to be completely broken at some random point in the index (currently thats around p. 475, but that's random and will change over time).

To avoid this problem we need to reduce the number of {{ts}} calls; and in practice this means not using tables for formatting the index. Not really because the table is a problem, but because in practice we can't use a table without also using tons of {{ts}} calls. That's why I recommend the very simple approach I outlined above: it renders very close to "perfect" (close enough for all practical purposes) and at the same time it is extremely simple both for the proofreader and for the software making it relatively "foolproof" (i.e. it will never make MediaWiki fall over).

In addition, I observe that for some reason this index has been modified relative to how it is formatted in the scan. The transcription currently lists headwords as separate lines:

Aborigines of America ii		383
	Aborigines of America ii	385
	Aborigines of America ii	386
	Aborigines of America ii	392
	Aborigines of America, ii, See Indians and Mankind	393

But in the scan they're formatted as:

Aborigines of America, ii, 383, 385, 386, 392, 393. See Indians and Mankind

That is, not only does it not match the scan (and there are some outright errors: "ii" is the volume number, not a part of the head word), but by splitting each page out onto its own line it also multiplies the number of table rows needed for each entry. And since each table row requires {{ts}} for formatting, this also multiplies the number of template calls.

My strong suggestion is therefore to code your formatting roughly like this:

Source

Rendering

{{hin|Ayllon, the licentiate, ii. 19, 21, 219}} {{hin|Azcapozalco, a slave-market, i. 83, 93; ii. 434}} {{hin|Aztecs, or Mexicans, civilisation of the, i. 9, 32, 1135 extent of their country, 93 il. 297; time of their arrival at Anahuac, 14, 241, 5 ii. 296; their migratory habits, i. 155 ii. 389; […] remarks on the fall of their empire, 296 essay on the origin of the civilisation of the, 383; traditions respecting their origin, 392}} {{hin|Babel, a temple of Cholula, ii. 387}} {{hin|Badajoz, Gutierre de, ii. 274}} {{hin|Balboa, Nufiez de, i. 122, 1353 ii- 434}} {{hin|Banana, 1. 773 fruit, 439}}

Ayllon, the licentiate, ii. 19, 21, 219 Azcapozalco, a slave-market, i. 83, 93; ii. 434 Aztecs, or Mexicans, civilisation of the, i. 9, 32, 1135 extent of their country, 93 il. 297; time of their arrival at Anahuac, 14, 241, 5 ii. 296; their migratory habits, i. 155 ii. 389; […] remarks on the fall of their empire, 296 essay on the origin of the civilisation of the, 383; traditions respecting their origin, 392 Babel, a temple of Cholula, ii. 387 Badajoz, Gutierre de, ii. 274 Balboa, Nufiez de, i. 122, 1353 ii- 434 Banana, 1. 773 fruit, 439

That's still going to generate a lot of template calls (to {{hin}} instead of {{ts}}), but it'll be a lot less of them and because {{hin}} is a much much simpler template it executes much faster and is a lot less likely to hit the MediaWiki limits. (we unfortunately can't do the hanging indents more elegantly because web browsers do not actually have support for hanging indents: we have to fake it with margins and text indent. if browsers had proper support for it we could have used just a single declaration at the top of the page and the rest would be automatic) --Xover (talk) 07:51, 29 August 2022 (UTC)

@Xover: I converted the list and eliminated the table codes. Did you find any others that need fixing? — ineuw (talk) 02:18, 5 September 2022 (UTC)

Awesome! As was the effect:

	Old version	New version
CPU time usage	12.590 seconds	0.434 seconds
Real time usage	12.646 seconds	0.507 seconds
Visited node count	21,391	4,178
Post‐expand include size	783,521 bytes	150,078 bytes
Lua time usage	10.072 seconds	0.024 seconds
Lua memory usage	4,878,249 bytes	1,759,546 bytes

And those numbers are with both Index 1 and Index 2 on the same page. It used to take way more than 10 seconds to render each of those two pages (can't tell how long really since they hit that timeout at 10 seconds), and now both of them together take less than half a second; and the time spent in Lua code fell from somewhere north of ten seconds each to just 24 milliseconds together. That's a pretty massive improvement!

There are no more pages like that in the tracking category just now (there are others but they aren't your texts, and they'll need different solutions), but it's possible some texts are borderline and may pop up when the servers are under heavy load and the page happens to be rendered at the same time. If any of "your" texts show up I'll be sure to let you know.

In any case, thank you so much for the effort here, and for getting it done so quickly. Very much appreciated! --Xover (talk) 11:11, 5 September 2022 (UTC)

Xabe

My previous question had a typo. Xabe shows up in the Chronicle's of the Coronado expedition as a Nahuatl speaking young man. Since one of your posts lists Xabe as a place name, I'm wondering where it was, or at least what source contained the name. 2600:100A:B003:A977:D094:AF15:569C:7AAB 12:02, 12 October 2022 (UTC)

Wish I had such a detailed knowledge. — ineuw (talk) 16:03, 12 October 2022 (UTC)

This info is available by placing the search template in the main namespace title/main page of the book. Unfortunately, I have no time to do it. I assume you found Xabe in Wiktionary of words extracted from my proofreading? — ineuw (talk) 18:53, 6 November 2022 (UTC)

Template:FIS

Moving here.. because it's about a template you wrote... Some test cases:- https://en.wikisource.org/w/index.php?title=User:ShakespeareFan00/Sandbox/sandbox2&diff=prev&oldid=12724718

FIS, as I am currently understanding have 3 widths/sizes involved.

1. Set by width?, is the size of the enclosing container? ('container width')
2. is the width of the image container (which is set how?) ('image viewport width'
3. is the width of image requested from the server? ('server image width')

What I'd like to do is set the 'container width', 'image viewport width' and 'server image width' seperately. Thus I can I have a 100% width outer container (including the caption) which spans the entire page, within which is a centered image region (using a mediawiki image syntax center here generates a DIV which is not desirable). In the image region is the actual image (at the size requested in imgwidth).One of my test cases was what I termed a half-scale request. Imgwidth, the image requested from the server and the sizing in the IMG tag genarted is always going to have to be a pixel value. Would it be possible to have some kind of intermediate container for the "image viewport" which could be set independently of the 'container' width and 'server image'?

ShakespeareFan00 (talk) 10:55, 6 November 2022 (UTC)

What I would also like is behavior in {{FIS}} like that in {{img float}} ( It uses a 100% width SPAN to fake block-like behaviour, see img-center class, Template:Img float/styles.css.

I have a confession to make. I don't think I used {{img float}}, nor looked at the CSS. In my impatience to get as many pages proofread, I avoided spending time understanding the inner works of templates and I can't comment. The truth is that, the FI and then FIS (a modified version of FI) were designed to help in my efforts to proofread projects with lots of images and I am grateful to everyone. What is important to me, is that the final result is pleasing to read on screen and in print. I only complain when changes affect my ability to proofread. — ineuw (talk) 18:44, 6 November 2022 (UTC)

There is a way to resolve it. And that's potentially to have an intermediate container around the img markup.

so you have

<span class="__outer">
<span class="__imgwrapper"><a><img .... /></a></span>
<span class="caption">Caption</span>
</span>

The current version of {{FIS}} puts the IMG markup in directly in "__outer".

By carefully setting up the style of the "__imgwrapper" in an appropriate way (ideally based on imgwidth) then the centered inline image is at least feasible. It would also potentially solve another use case issue I have in my sandbox. https://en.wikisource.org/w/index.php?title=User:ShakespeareFan00/Sandbox/sandbox2&oldid=12725773

ShakespeareFan00 (talk) 19:21, 6 November 2022 (UTC)

However, doing that introduces a level of complexity in the Module, which may be something you were trying to avoid of course. ShakespeareFan00 (talk) 19:23, 6 November 2022 (UTC)

I am beginning to sense that our approach to proofreading are guided by different interests. Prior to retiring, I worked as a database programmer for a commercial printing and mailing house. Training required that my focus is on the final result, and this is why my proofread order may seem quirky. I try to achieve this as close as its possible on Wikisource. I start with what I want to see displayed in both the page and main namespace screen, and try to correct pages that print incorrectly. I only know this, when someone is complaining about a printed page rendered poorly by my proofreading. I can't afford the time it requires to analyze a template in depth, and try to understand it at your level of knowledge. My guess is that User:Alex brollo or User:Inductiveload can give you the info

I am aware of issues in the main namespace display as well.

In your sandbox examples, if you are referring to floating an image in center with the text flowing uninterrupted on both sides, FIS cannot do that (in the Page namespace). If you see a such a page, please post me the link. — ineuw (talk) 20:22, 6 November 2022 (UTC)

Can you clarify what you mean by 'uninterrupted', Do you mean

<P>
text
<img>
<caption>
text
</p>

If so than I have clearly been trying to do something that isn't actually possible ( :blush ) and should be using {{imgfloat}} for those instances.

What I was suspect I was trying to do in the dressmaking book, was to use {{FIS}} as an inline version {{FI}}, which it clearly isn't.

In some places it's straightforward to move the {{FI}} outside of what would become a paragraph.

I solved the other issue (that of my sub-heading code), by removing it going back to simpler formatting.

Aside, it would be nice (but would probably break a LOT of pages) if the styles on img_float and FI/FIS were harmonised. I've been able to do that in the Dressmaking book, by means of the CSS IndexStyle I've linked previously.

Thank you for the clarifications by the way ShakespeareFan00 (talk) 20:35, 6 November 2022 (UTC)

Text can only float around an image on one side. To surround an image with text on both side requires two columns. I don't know if this can be done at the moment. — ineuw (talk) 21:00, 6 November 2022 (UTC)

I also owe you an apology, I was trying to do something complicated, that required me to do a little bit more reading of the documentaion in depth. That is however no reason for me to react in the way I did elsewhere. I hope that you can accept my views where out of frustration at my own lack of ability, and that I can continue contributing in a more positive manner. ShakespeareFan00 (talk) 20:03, 6 November 2022 (UTC)

Nonsense. Don't apologize, we are fellow sufferers of frustration. — ineuw (talk) 20:25, 6 November 2022 (UTC)

RFA for User:ShakespeareFan00 on English Wikisource

Whilst I appreciate and accept your reasons for considering nominating me, I feel I would at the present time have to respectfully decline on the basis of a lack of policy experience in specific areas, and a genuine "need" for the tools in respect of the majority of activities I have on Wikisource.

My other reasons for declining at the current time are:-

1. I was in the past briefly blocked on English Wikisource (due to concerns about competence) and on English Wikipedia (due to an "agressive" application of the copyright and fair-use policy.) It was and still is my opinion that the community has to have trust in those to whom advanced tools are granted.
2. English Wikisource is not short of administrators.
3. In some areas I still lack policy competence. Evaluating a work for concerns such as scope or educational value is very different from evaluating a work for copyright. Even in the area of copyright evaluation, my assessments are sometimes mistaken, and thusly a nomination might be seen as contentious by other contributors.
4. In some areas I still lack technical competence, minor repairs to templates and scan backed pages, or matching HTML tags, is considerably simpler than maintenance of Lua modules or UI components on which numerous pages may be dependent.

ShakespeareFan00 (talk) 18:17, 15 December 2022 (UTC)