An update on Rawpedia

Software RawTherapee
1

Hi all!

I made the mistake of not communicating this clearly earlier (my apologies to the RT team) and wanted to give a quick update on the status of Rawpedia.

Rawpedia is the last vestige of very old infrastructure that we were running for the RT project. It’s a mediawiki installation running on our shared webhost (that everything else has been migrated out of to our own servers now).

I was asked to add a new user to the wiki software a few weeks back and decided it was a good time to upgrade the mediawiki software as well as the PHP being used to keep secure. In doing that I broke Rawpedia. Well, there’s a wonderful theme that @XavAL had built for the site a while back and something in the upgrade didn’t like one of the extensions that was being loaded for the site, so it didn’t render.

I have since reverted the mediawiki to use the default theme/skin monobook and that has it up and running at least (although not as pretty as the previous skin).

I’m going to poke the install and try editing out some of the extensions being used to see if I can get it back to looking like its former glory.

However
It’s always been my intention to migrate the wiki to something more secure, faster, and on our own servers. This felt like as good a time as any to start the process.

Note, this is a process we’ve done a few times already for many of the other projects. We’ve migrated websites to be static sites generated using the hugo static site generator. The reasons are the same for the myriad of website migrations we’ve done for other projects (and indeed for the original RT website, iirc).

  • Static sites are inherently safer for everyone involved. They are just static html/css/js assets being served by the webserver. There’s no server-side processing using anything like Python, PHP, Rust, Node, etc. Just plain 'ol html (css, js).
  • This reduces our required manpower to manage servers and interruptions (server upgrades, library upgrades, checking that stuff doesn’t explode, etc). This also reduces costs.
  • It provides an authentication workflow and history logging automatically when we use git to control the files and content.
  • The content itself is just a bunch of markdown text files.

My proposal is to migrate the content from Rawpedia into a static website and to manage the content through a git repo. There will be some adjustment to editing content files in this way, but honestly, there’s only a small handful of users on the site to begin with (less than 10) and there are web-based gitlab tools for editing content in a browser pretty easily.

There will be some migration pains, no doubt, but I think we’ll be in a better place to move forward in general.

Thoughts?

13 Likes
2

Many thanks Pat! To be honest, I am not even disliking the current plain style. :roll_eyes:

Something to consider is where the git repo will live. There are talks of setting up a RawTherapee organisational account on GitHub. It would be ideal if the documentation could become part of that, and the main site too perhaps in the future.
Ping @Morgan_Hardwood and @Entropy512 for input.

2 Likes
3

I’m fairly agnostic on the hosting, although we already have the website currently on gitlab if you wanted to use a non-microsoft platform:

4

It would be nice to keep RT-related things together under the RT umbrella which, for better or for worse, is currently on GitHub. But since you’re running the documentation server (and maybe at some point the website itself will migrate to your server), would hosting things on our GitHub soon-to-be organization complicate documentation deployment for you @patdavid ? It makes just about no difference to me whether the documentation uses GitLab or GitHub. If it complicates things for you then I have nothing against using GitLab.

The nice thing about git is its distributed nature, so if GitHub goes rogue we can pop over to GitLab or whatever the future holds with a hypothetical click.

On a related note, accepting documentation changes through PRs will improve the documentation, since someone from the core team will have to approve the changes and merge the PR. I’ve had bad experience with MediaWiki’s model, where contributors once approved can edit anything, so someone approved just to translate would go on and make changes to the source English text, and so I’d find that someone wrote pure nonsense a year or two after said nonsense was published.

2 Likes
5

It would be nice to keep RT-related things together under the RT umbrella which, for better or for worse, is currently on GitHub. But since you’re running the documentation server (and maybe at some point the website itself will migrate to your server), would hosting things on our GitHub soon-to-be organization complicate documentation deployment for you @patdavid ? It makes just about no difference to me whether the documentation uses GitLab or GitHub. If it complicates things for you then I have nothing against using GitLab.

The nice thing about git is its distributed nature, so if GitHub goes rogue we can pop over to GitLab or whatever the future holds with a hypothetical click.

On a related note, accepting documentation changes through PRs will improve the documentation, since someone from the core team will have to approve the changes and merge the PR. I’ve had bad experience with MediaWiki’s model, where contributors once approved can edit anything, so someone approved just to translate would go on and make changes to the source English text, and so I’d find that someone wrote pure nonsense a year or two after said nonsense was published.

6

Github is fine with me. Once you setup the org let me know and we can migrate the current website repo into the org. :+1:

7

@patdavid @Morgan_Hardwood @Thanatomanic

I’m not sure I understood everything (excuse my bad English, my age and my state of health…), but if the documentation must be written in English and subject to a global approval (pull request type), as we let’s say in French: “We are not out of the inn” (On n’est pas sorti de l’auberge)

Obviously on the general principle, I approve.

How is it currently, for LA or other complex subject (wavelets, etc.)

I make a French version that I put on Rawpedia (french). Knowledgeable people read it and 2 things happen:

  1. understanding of what is written, why, how?..with exchanges in French…
  2. then English translation (obviously not by me)
  3. proofreading by me (English), then correction again, to take into account 1 and 2 above.
  4. probable re-writing of the French version

It’s long, hard…
This will be considerably more difficult and time consuming if the proposed changes are made.

But we can say that this is only a special case!

A detail . We are currently working on paragraphs 5 to 7 of the LA English documentation, but impossible for me to make changes: login, password are not recognized…

Have a good day

Jacques

8

Github has an online editor that should make this relatively easy. Simply edit the file, make changes, commit changes. Rinse and repeat. Other users can contribute and discuss changes, just like any other discussion we have on code-issues on Github.
I don’t think it’s necessary to write English first and French second.

That has probably to do with the fact that the site is a bit broken now. Will be all right soon :slight_smile:

2 Likes
9

@Thanatomanic

Thank you :slight_smile:
But just recall, the first “PR” or something close, will be (at least for the documentation I write) in French…

Jacques

1 Like
10

Bien sûr!

11

I have one doubt, yet: there are a handful of translators, which in theory just write documentation in their native language, so they translate or create non-English documentation and put it on a PR. And then one core member must approve it and merge it to the non-English part of the documentation.

The big big question is: who is going to approve e.g. the japanese translation? Or the Spanish one, for the matter? If there’s no core member with quasi-native knowledge for some translation language, how are you going to honestly review it? The content, I mean.

12

If you trust your translator, then just merge thebPR without reading it, or use DeepL to make sure it doesn’t contain anything bad.

3 Likes
13

I agree with @paperdigits, we need to trust our translators. Currently any editor could write bogus on all articles in all languages. Working via PR’s is at least a little threshold to prevent that.

2 Likes
14

It is certainly easier to read.

15

I am currently doing translations for LA 4.0 (General principles and settings) to Japanese. So, I should wait to update (new system will be like one for GUI update, I suppose)?

16

It’s certainly easy enough to read, no problems for me. But I personally prefer the previous theme. It somehow looks less “online”, seems to come across more like a printed book. I always thought it was nice looking. But either is perfectly good.

17

A small update. I took some time this evening to see about getting logged in to rawpedia with the default skin - some accounts were not going to be able to do it as they had manually changed their default skin to the one that was causing problems, pivot.

I reset those accounts (Me, @Morgan_Hardwood and @XavAL specifically) to use the default vector skin and I was able to log in. A few edits later and I can edit a page. If anyone wants to try it out that already has an account please do and let me know.

I’ll start looking into getting a barebones static site translation done soon.

18

@patdavid
I was able to update Rawpedia, in English, of course I’m not the translator. Thank you.
But, I come back to the 2 problems I mentioned:

  1. understanding (assuming I am clear) of what I have written: this is far from obvious given the innovation side of certain algorithms (for example the term “attenuation response” with all the concepts behind it, which required several days of discussions at 3…)…I dare not think of an automatic translation and the answers that I could give badly if there are many of us
  2. the English translation, which will serve as a basis later, assumes that the translator has understood, and that the editor (me in this case) has sufficient knowledge of English.

Jacques

19

Moving rawpedia to something managed via PRs is, in my opinion, an excellent idea.

I also agree with @Thanatomanic that this is one of the many reasons for creating a github organization for RT - to handle ancillary repositories. I think most of the RT team is fine with github, after all everyone has been working with @Morgan_Hardwood 's repo there. I know I’ve been meaning to submit a few documentation tweaks regarding color profiling to rawpedia but never got around to requesting an account, doing a github PR is far easier for me at least.

(My personal stance on github and microsoft is that while MS has some really egregious behaviors in their history, I’ll give a company the benefit of the doubt if executive management has been changed out - post-Nadella MS is a lot better behaved and even friendly to FOSS vs. pre-Nadella. So I’m happy using github, VSCode, and WSL. :slight_smile: )

20

One might think, given my comments, that I am against this development.
It’s not, I totally agree.
But the experience of the documentation of Wavelet, Ciecam, Abstract Profiles, as well as that of Local Adjustments, lead me to the mentioned remarks.

:grinning:

Some additional details:

  1. How will the online text editor (Rawpedia or its replacement) be? Currently with Wayne we are doing the swapping - after many trials with the “Rawpedia format” used in Libreoffice. This allows comments to be made (understanding, clarifications, etc.) and collective validation of these modifications.
  2. I think it will be desirable to dedicate a pair of volunteers with the required skills. In the case of all the documentation that I mentioned above (transition from French to English) the cooperation of the first French editor (here me) and the proofreader / translator (here @Wayne_Sutton ) was exemplary , but is time consuming.

Jacques