The temporary logo change won't be implemented before its scheduled end date.
The request will soon expire, but it shouldn't be marked as "declined" as that wouldn't accurately reflect the situation.

@Hamishcn mentioned that adding a yellow ribbon to the logo could be considered a "regional religion" matter, and thus not "neutral". If a request remains unresolved by the due date, it can reasonably be interpreted as being refused.

So we can reopen this task, and continue the discussion why WMF personnel refuse to apply a requested change to $wgLogo, since the yellow ribbon symbolizes the call for the safe return of the citizens who where kidnapped from their houses by the Hamas on October 7th.

The activation date is due, so we used local settings to apply the temporary change.

The temporary logo change will be applied locally tomorrow, as updating it through the configuration file will take longer. However, it was recommended to submit a request for the temporary logo change via site-request.

I'm admin at the Hebrew Wikisource, so I have reviewing permissions.
Here are two similar pages from the Hebrew Wikisource (Mandatory Education ordinances for different years).

New page – without reviewing panel	Old page, previously reviewed – reviewing panel exists

And yet another law – The Israeli Pharmacist Ordinance – has just fallen over the limit...

I kindly request to reopen this bug as it is not a duplicate of T366083 but rather a regression caused by T365736/T367601.

I get the point of external class, but I don’t get the point of the internal one. The code in the template is [[{{{1}}}|<span title="{{{1}}}"> — why is that needed? The link itself generates title="{{{1}}}", this is just duplication for no reason.

When {{{1}}} contains an anchor, for example when the link points to [[Transportation Regulations#article 7]], the hint (title) shows "Transportation Regulations" instead of "Transportation Regulations#article 7". The destination might differ from what the text implies, so it's important to display it as a hint.

What would you suggest to reduce the template size? The external <span class="..."> is necessary for styling the <a> tag, and the internal <span title="..."> is needed to override the partial hint created by the [[Link target]], which generates an <a href="..." title="Link target">.

@cscott, thank you very much for your work on this issue. I completely agree that changing the maximum article size is not the right approach. Instead, we need to adjust the measuring scheme so that non-Latin texts are not penalized. Your patches, which replace strlen() with mb_strlen() and measure page size in characters instead of bytes, effectively resolve the issue for Hebrew Wikisource. Given this, perhaps "Change $wgMaxArticleSize limits from byte-based to character-based" would be a more appropriate title for the task.

I would like to point out that a similar issue arose a long time ago, regarding the length of custom signatures, which was expressed in bytes rather than characters (see T12338: Length of nickname and rSVN23389: * (bug 10338) Enforce signature length limit in Unicode characters instead of…). This precedent demonstrates that addressing size limits in a way that accounts for non-Latin characters is not without foundation.

In T275319#9819103, @cscott wrote:

[...] Appropriate metrics are not easy to find, because ideally they must be computed *before* spending the compute resources that a full computation of the desired result would achieve. [...] At every point we try to avoid spending the resources to do the actual expansion if it is likely based on "what we already know" that the other limits would fail. If we do the entire expansion and rendering to HTML and *then* check to see if it turned out to be too big we're already too late to reclaim the resources spent.

I've compiled a table detailing some of the largest legislative texts found on Hebrew Wikisource. Before drawing any conclusions, it's essential to carefully examine the data:

In the case of Israeli laws, their length consistently falls below the intended limit. But we use complex templates for the presentation of the legal text, which may expand above the limit. For instance, the Income Tax Ordinance is 1,512,975 bytes (896,491 characters), expanding to 2,230,303 bytes; the Planning and Building (Application for Permit, Conditions and Fees) Regulations, 5730–1970 is 1,225,044 bytes (750,579 characters), expanding to 2,044,793 bytes; and the Transportation Regulations, 5721–1961 is 1,252,942 bytes (756,967 characters), expanding to 2,096,963 bytes.

In T275319#9813686, @Ladsgroup wrote:

In T275319#9813641, @Fuzzy wrote:

I wish to avoid the discussion what "should be" the limit of the page length, in characters.

For a database or CPUs characters don't matter, bytes do.

I wish to avoid the discussion what "should be" the limit of the page length, in characters.

It still appears broken. Adding Web-Team-Backlog for further investigation.

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,