I previousely asked, and I'm still wating for an explanation –

Why not using $wgMaxArticleSize as a limit for the page raw size, and 2*$wgMaxArticleSize as limit for the page post-expand include size?

According to Lighthouse Best Practices, document should have a meta description. See here. The meta description should include the page title or the content of the first header.

In T275319#9054277, @stjn wrote:

Wikisource editors can absolutely split pages into smaller ones, since those longer pages have sections and subsections. The community choice might be not to split them, but that’s not necessarily a technical problem.

We hit the fan once again with the Israeli Income Tax Ordinance. We cannot shorten the templates and we need an immediate solution.

Hi Alexandros. The permissions for he.wikisource.org were updated, but not for he.m.wikisource.org. Thanks.

In T238090#8448413, @jhathaway wrote:

@Fuzzy would you kindly email me your email address, jhathaway@wikimedia.org?

Okay, I sent you an email. Thanks!

I have problems with my Search Console permissions. I cannot use "Request Indexing" tool.
@jbond, can you check?
Also, can you specifically add the "http://..." properties?

There might be other causes which started earlier. Still, according to the Lighthouse analysis, the Central Notice added about 0.6 seconds to the CLS score. Also, the images in the banner lacked "width" and "height" properties, which also impacted the CLS.

According to the Page Experience chart, the problem started August 30th. I cannot say when the campaign was over since we had holidays the past week. But I think it ended the last few days.

Hebrew Wikisource was a target of the campaign first phase. I didn't keep screenshots of the page because I did not think this statement needs proof.

Possible duplicate: T280476.

This issue starts to be urgent. I just received an update from a state official. She said Parliament officials cannot use our files since the exported PDFs are invalid, and asked when the issue will be solved.

Why not using $wgMaxArticleSize as a limit for the page raw size, and 2*$wgMaxArticleSize as limit for the page post-expand include size?

This bug is a duplicate of T290146. Please mark this one as "duplicate".

As previously stated, when processing single page, WS Export should produce a PDF file which is visually equivalent to the file created by the browser "Print to PDF" function. WS Export may be useful when processing a collection into PDF/ePub/Mobi/rtf/docx files. The tasks mentioned in the comment above are merely the first few steps on the long path to a workable and useful extension. And for now they are not set as "high priority".

Are there any updates on the issue? I'm playing around the limit by removing functionality from some templates, but I cannot dodge the limit much longer...

We are still waiting for the WS Export extension to be disabled on the Hebrew Wikisource.

Thanks, I failed to find the other bug. The suggested change can improve search engine visibility, so it still may be a good idea to consider, regardless of the ancient bug reports.

Here is a list of open bugs with WS Export. I'll update the list when I have time.

• (block) Use specified font family and font size according to stylesheets. Import webfonts if necessary.
• (low) Import common.css and print.css in addition to epub.css.
• (high) Use @print { size: ... } as default page size.
• (high) Invalid ankors with external links. External links such as [[חוק העונשין#סעיף 61]] are converted to a the correct destination page (he.wikisource.org/wiki/חוק_העונשין) but with ankor #s_yp_61 instead of #סעיף_61. [Note: sometimes the ankors are kept, conversion is inconsistent.]
• (high) Keep internal links and ankors. Internal links are converted to the source page with invalid ankors.
• (medium) Don't include title page and "About" page when .printfooter has display: none; property.

As long as https://he.wikisource.org/api/rest_v1/page/pdf/חוק_זכות_יוצרים produces better PDF compared to https://ws-export.wmcloud.org/?page=חוק_זכות_יוצרים&lang=he&format=pdf, we insist on disabling the WS-Export extension on the Hebrew Wikisource. The WS-Export extension is immature for our use.

...although I also think the common.css on Hebrew Wikisource contains a lot of stuff that should probably be in templatestyles

We don't have problem of interface editors. The template styles extension seems to be nice hack to split Common.css for different sub-projects, and I will check it in the future. However, it doesn't matter much as WS-Export should handle both template styles and inclusion of common.css and print.css styles.

I stumbled upon a similar problem, with the Israeli Plant Protection Regulations (Plant Import, Plant Products, Pests and Regulated Articles), 5769–2009. A bidirectional template was using {{#if:{{{1|}}}{{{2|}}} | ... }} to check if the first and second parameters are given. The test is based on templates expansion, which, in this case, almost doubled the post-expand include size of the article. I had to remove the condition statement in order for the regulation file to remain within limits.

I'd suggest to move the discussion about suitability of the WS-Export extension to the Hebrew Wikisource limited to T280637, and keep this discussion to rendering bugs.

The WS-Export extension is not suitable from exporting single article as PDF. When exporting an article to PDF, our users expect a printable version of the article they are viewing. The WS-Export extension was designed differently: from the extension point of view, the exported file is expected to be used by eBook readers. Therefore, the extension assumes the text should be kept but its styling can be ignored. This design is not suitable for styled texts, such as those of the Hebrew wikisource.

The problem is not a specific font. The problem is ignoring CSS styles. As said, in order for the WS Export to work –

• It must import all Common.css and Print.css styles. Those styles are used when a page is printed on paper using physical printer, or to PDF file using a virtual printer.
• It should load Epub.css styles.
• It should load and render Webfonts properly.

Still, the fundamental issue is that WS Export is not suitable for exporting single articles. We asked to continue with Electron-PDFs as default method of export (see T280637).

Any update regarding the site request?

As partial solution, it is possible to use 2*$wgMaxArticleSize as limit for the page post-expand include size? The wgMaxArticleSize will continue to be used as limit for the page raw size, before template expanding.

See discussion in Scriptorium here.

@ifried – Boxes are Unicode characters not supported by whatever font is used (#4 in my list). This is not parser bug.
@dmaza – The tags failed to be parsed (#6 in my list) are <section begin> and <section end> of the Labeled Section Transclusion extension. This extension is widely used within the Hebrew Wikisource.

There are two apparent solutions to the effective limit for Hebrew pages:
A. Use mb_strlen instead of strlen to measure page size in characters rather than in bytes.
B. Use $wgMaxArticleSize as a limit for the page raw size, and 2*$wgMaxArticleSize as limit for the page post-expand include size.

Side note: We see a performance issue with the Module:String. The {{ח:צמצום}} template relies on {{#invoke:String|len|...}} which consumes most of CPU time.

Another example: https://he.wikisource.org/wiki/חוק_זכות_יוצרים and the PDFs of https://ws-export.wmcloud.org/?page=חוק_זכות_יוצרים&lang=he&format=pdf and of https://he.wikisource.org/api/rest_v1/page/pdf/חוק_זכות_יוצרים
Attached you may find three PDFs files. The first one was created by WS Export, the second one is the equivalent PDF file created by "Save to PDF", and the third PDF created by ElectronPdfService REST API.

The generated PDF file is so horrible in so many ways. Basicly WS Export should create a PDF file which is visually equivalent to a PDF file generated by the "Print to PDF" option of the browser.

Custom togglers are very useful when used properly (example). I think the best solution, which is also the easiest one in this case, is to use the same scheme for regular togglers and custom togglers. It's trivial to use the same default toggleARIA flag (true for both).

Thanks, @Urbanecm provided solution to the robots.txt issue.

Yep, now it works :) Thanks again!

It seems I don't have permission for the "REQUEST INDEXING" tool.

Thanks a lot, John!

I prefer setting no time limit. This is administrative task for the project, so access is required as long as I'm an administrator at the Hebrew Wikisource. If definite time limit is required, let's say three years, and renew access when expired.

Let's get one step at a time. Before getting into legal and technicality, WMF should assess and approve the request.

Hi Dzahn,

In T18036#5135002, @matmarex wrote:

With this patch, small categories (up to 100 pages) should be once again recounted whenever a page is removed from them. This should be deployed to Wikimedia wikis next week, per the usual schedule. Larger categories may still remain inaccurate forever.

In theory, redirects may increase the total number of pages by an order of magnitude. However, in practice, the average number of redirections per page is relatively small. For example, in my project a lot of pages have multiple redirections (alternative spelling and such). The total number of pages in the project category is 1190. The total number of pages including redirections is about 2000.

I guess a nice warning should be sufficient for now.

@MusikAnimal, I think you can close this task as T179113/T182103 are resolved.

I can confirm a regression in the Massviews tool. You can easily reproduce the problem by setting range = latest-1. The tool will stop when "processing page X of Y", where Y−X are the number of pages with no stats. Note that when a page has no stats, that is, zero pageviews for the given range, the API returns a 404 error.

Is there any workaround to force recount for a given category?

Thank you @MusikAnimal for the fast fix!

Edit notices reside in the MediaWiki namespace because all other user interface text lives in the MediaWiki namespace.

Editnotices are the edit-page counterparts of notice templates. A nicer solution is to implement editnotices via template inclusion. It's not possible with current design.

In T151408#2824828, @Platonides wrote:

@Fuzzy, you probably can solve it by adding on MediaWiki:Editnotice-0 a code like {{#ifexist:מקור:{{PAGENAME}}|Don't edit this, but [[מקור:{{PAGENAME}}]]! |}}

Nice, I should have thought about it... :) 10nx!

Following @Bawolff notice, I'm including brief info on the [[s:he:user:OpenLawBot | OpenLawBot]] in hewikisource.

In T151408#2819035, @Bawolff wrote:

Summary of the bot edits to NS_MEDIAWIKI

• hewikisource OpenLawBot - Making editnotice pages

The OpenLawBot is the the background process of the [[s:he:ספר החוקים של מדינת ישראל | Israeli Book of Laws' project]] in the Hebrew Wikisource. It provides the legal textbook of the State of Israel (laws, ordinances, regulations, decrees, etc.), in a readable manner, with interlinks between the legal documents. Each OpenLaw page is composed of two pages – the source text, stored at NS:116 (see T66353), and the formatted wiki text, stored and displayed at the main NS. The source page contains the actual legal text in a simplistic format, very easy to understand and edit. The wiki page contains a formated text derives from the source text, after sophisticated automatic editing. It is very complex due to the usage of templates for the visual presentation. The bot is making editnotices for each new article in order to prevent new users from trying to update the wiki (formatted) part of the text. The editnotice directs the user to the source text.

This is a technical issue, and there is a consensus it's worth trying to use Microdata attributes, as there's no cost.
Nevertheless, following your comment above, I asked at the Scriptorium for more votes on the request.