[QUOTE=Happy5214;588311][…] I don't know if German has separate words for those […].[/QUOTE]

You would always say [I]auf (engl. on) dieser Webseite[/I] and [I]in (engl. in) meiner Datenbank[/I], but [I]Ich las es in einer Webseite[/I] and [I]Meine Daten befinden sich auf einer Datenbank[/I] sounds definitely wrong to me. For local storage: [I]Ich speichere meine Daten auf einer Festplatte/SSD[/I] or [I]auf meinem Computer[/I], but [I]Meine Zwischenergebnisse befinden sich im (engl. in the) Arbeitsspeicher[/I] (in RAM).

For "Wiki", it is more complicated. While you would say [I]Auf [der Seite] Wikipedia konnte man sich darüber informieren…[/I] (you could inform yourself on Wikipedia about…), you would likely say [I]In diesem Wiki(pedia)-Artikel geht es um Käse[/I] (this Wiki(pedia) article is about cheese) like if you would say [I]In dieser Anleitung erkläre ich euch, wie man einen Fisch entgrätet[/I] (in this manual I tell you how to remove fish bones).

I should probably clarify about "on a database". That would be for something like a searchable database, such as one you'd find at an online library, rather than an SQL database you'd maintain for a website. I definitely would never say something like "The data on my database went missing," unless I was speaking metonymically about the server it was on, i.e. "The data on my database [I]server[/I] went missing." Now, running queries "on a database" is a different thing entirely.

Although it's only one letter (difference in wording of "in" instead "on") where I thinks it's not worth to discuss, but I've done this:

I've changed the phrase on top of the table in "There are currently xxx entries".
A template for such information is not required I think, because:
- it's only a small notice
- it depends on the table if the notice is given by the DPL-command or with an own command (differs, too)
- this is only a quick notice for not counting by yourself
- this notice could be omitted, when looking at the category (the counting is given there)
And yes, such phase is not the only one in/on this Wiki.

The description is given in the page title and the line above, so no need to repeat it in that phrase again.

I've inserted 'scope="row"' for this DPL-command, too.

[QUOTE=kar_bon;588451]Although it's only one letter (difference in wording of "in" instead "on") where I thinks it's not worth to discuss, but I've done this:

I've changed the phrase on top of the table in "There are currently xxx entries".
A template for such information is not required I think, because:
- it's only a small notice
- it depends on the table if the notice is given by the DPL-command or with an own command (differs, too)
- this is only a quick notice for not counting by yourself
- this notice could be omitted, when looking at the category (the counting is given there)
And yes, such phase is not the only one in/on this Wiki.

The description is given in the page title and the line above, so no need to repeat it in that phrase again.

I've inserted 'scope="row"' for this DPL-command, too.[/QUOTE]
The lead wasn't addressed, so I took that into my own hands and expanded that myself. Some new members to the project might want an explanation as to why there are so many missing ranges.

Understood on the notice. I didn't know if the "in"/"on" was a typo or a common translation error, since I've seen it before (not necessarily from you, but I wanted to rule it out).

The DPL template still needs the exclamation point for the [c]scope="row"[/c] to be useful. That's what makes it a row header (and semantically correct). You'll be able to override the default gray coloring using CSS.

The abbreviations inserted in the table header cells seems helpful on one side but explodes the code and makes it harder to read/edit on the other side.
Another question on my side: It seems self-explanatory so is it really needed here?

A more easier way to do this is to create a page, where such a table (and there're many others) are explained like the table headers (Nash), or the sorting ability or colouring.

If you only want to make those things more 'readable' for visually handicapped people (tools for reading out loud) or controllable it's too much to handle. The same is for building all pages to be accessible for mobiles, where I say strictly 'No' then.
I want to bring in more information and still have to make my mind, how to do this in many cases.

The (Generalized) Fermat Numbers are now manageable including there "GF Divisors" with links to the Proth prime pages and many historical data maintained by W.Keller's pages.
He only gave lists for Fermat numbers and for GFn-bases for 2,3,5,6,7,10,11,12 but no others (especially 8). More lists can be created by the new templates not available on any other internet page so far.
This Wiki is still not fully implemented and it could take years until all data are available so those table enhancements have to wait on my side.
I got more ideas to handle with like including references to online books and articles of authors to suppress the history of findings (like [url='https://www.ams.org/journals/mcom/1998-67-221/S0025-5718-98-00891-6/']those[/url], many articles of "Mathematics of Computation" are available as PDF).
Counting primes and creating downloadable LLR-type resultfiles or prime listings are another topic to do.
How to handle the check of Twin primes? Is it done always for any new Riesel prime found?
What about new Proth primes? Are those always checked for GFN divisibilities? How to manage this in the Wiki?
So way more work to do than those detailing.

I created a template in my user sandbox ([url]https://www.rieselprime.de/ziki/User:Happy5214/sandbox/Template:Riesel_list[/url]) in order to standardize the primary Riesel prime lists. Most of the pages would now become calls to this template, which would only require a few lines, while the logic would be in the template. I also included support for bases other than 2 via an extra parameter.

My Lua rewrite of the NVal and NVal list templates is complete enough to share. I achieved a speed improvement of over 5x vs. my copy of the current code (pre Gen. Fermat) on my personal server. This may help with the exorbitant load times on the Riesel [I]k[/I] list pages. Since my wiki is behind a firewall, I've attached the code here. Its only dependencies are those which come with Scribunto (the MediaWiki Lua extension) itself.

I think I've brought this issue up before, maybe via PM (I don't feel like searching for it now). The wiki license is CC-BY-NC-SA 3.0, which I believe was inherited from the old Mersenne Wiki. I have several related questions following on from that basic premise:[list=1][*]Is this the desired license for the wiki, if we were to have a free choice?[*]If not, is it worth deleting/rewriting from scratch the imported Mersenne Wiki pages to allow for a relicense? Is that even possible?[*]Is the potential ability to import templates/modules/CSS from Wikipedia/Wikimedia/MediaWiki enough of a reason to pursue a relicense?[*]The purely mathematical data pages (e.g. Riesel prime ###) are currently under the same license as the mostly text pages. Given that the mathematical data should not be eligible for copyright/should be PD, Is a dual license of CC0 (for safety, would have the same effect as PD) for the data pages and another license for the text pages appropriate? This is an argument in support of putting the data in a separate subsystem, e.g. Wikibase.[*]In fact, I could argue that the current license of the Prime-Wiki prevents its use by GIMPS users whose primary reason for contributing (and using the Prime-Wiki to look for related information) is to win a GIMPS research award or an EFF prize, since any editor of the wiki (as a copyright holder of some text) could consider that to be "commercial use". I don't think it would hold in court, and I hope none of us would be that nefarious, but it's sufficiently murky that it ought to be considered.[/list]

Karsten has indicated to me that a full migration to Wikibase is not in his current plans. However, Wikibase would be an excellent tool for some of the structured data in the Prime-Wiki. The multi-reservations specifically come to mind. Storing them in a Wikibase item would allow all of the fields to be edited on the same page, and it would eliminate the reuse of IDs for new projects, which is poor design. I'll design a rudimentary Wikibase instance focused on just the multi-reservations and related items on my personal wiki and publicize it.

I just finished importing the Riesel even-[I]n[/I] Liskovets-Gallot [I]k[/I]'s from the old RPPDb page into the wiki, and I wanted to add a table to the CRUS project page using a CSV file (attached). However, I'm getting a MIME error whenever I try to upload the file:

[quote]File extension ".csv" does not match the detected MIME type of the file (application/csv).[/quote]

I don't know whether this is a browser issue (both Chromium and Firefox gave me the same error, and I also tried uploading it in Firefox as a plain txt with similar results), a server issue, or an upstream MediaWiki issue.

[QUOTE=Happy5214;602851]However, I'm getting a MIME error whenever I try to upload the file.[/QUOTE]

I've updated the extension ExternalData to the newest version, but this did not eliminated the error.
I've inserted into the mime.types file of the MediaWiki source the line
[code]
application/csv csv
[/code]
there was only an entry with "text/csv csv".
I've uploaded a new version of the data file for [url='https://www.rieselprime.de/ziki/Proth_prime_small_bases_least_n']Proth primes of the form k*b^n+1, least n-values[/url] and no error occured.

Try again now if the issue is solved for now.

I've searched for an error like this, but found no solution, an update to a newer MediaWiki version is not needed (and could also create other issues then).