It is certainly easier to read.
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)?
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.
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.
@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:
- 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
- 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
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. 
)
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.
Some additional details:
- 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.
- 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
I agree also. I think the main concern for Jacques is whether the PR for the English documentation needs to be available before the PR for the actual development code can be merged into dev. There is a good argument for doing it this way but it would rely on the translator being readily available because it is not a straightforward translation job. Using DeepL is not a solution.
Some thought also needs to be given to the documentation itself. At the moment* it is a combination of User Guide, Worked Examples, Technical Manual, notes for other developers etc., which doesn’t make it easy for the reader.
- EDIT: I’m referring mainly to the way the documentation is structured for the Advanced and Local Adjustments tabs
1 Like
As a side note on translations for the program itself, my conclusion after taking on the strings cleanup this release is: OH GOD PAIN. On my list is attempting to rework to GNU gettext which will hopefully allow for better/more commonly available tooling like Weblate.
Not sure if Weblate would really apply to translations of the manual though.
well … you do not have to reinvent the wheel if you dont want to. Just check how darktable docs are done.
the end result looks like this. (deployment is done per major version + current development branch). examples:
And as you see the dtdocs are on github too. They get deployed by a systemd timer every 15 minutes with some logic to only run the build when ever something has changed. So if you wanted to add RT to that code, all it would take is another few lines in the wrapper script.
3 Likes
We already have a weblate instance going for who ever wants to use it.
Yup. The problem is that using it with the current language/translations architecture in RT would be… challenging to say the least. I think it would be less effort to completely rework RT to use gettext than to try and get weblate to play nice with the current translations setup. Using the pixls Weblate instance is one of the main reasons I’m looking into gettext
In addition to the docs items @darix linked, I’m definitely going to be taking some inspiration from how darktable has integrated gettext with cmake too.
1 Like
Note that rawpedia on weblate won’t be possible, since authors write in several different languages. In fact, language management will likely be an issue, since there won’t be a primary authoring language.
I find Rawpedia to be quite helpful. Thanks for providing this resource.
Some (English) Rawpedia pages currently display long sections of “garbage” when I try to view in Firefox. (I tried multiple Firefox versions, all Linux).
Two examples are Saving Images and Sidecar Files - Processing Profiles.
The issue might be due to one of the templates. For example, Template:K
It is possible that it is something unique to my setup. If so, I apologize. Maybe someone can verify that these pages render correctly or not. But, it seems possible that the issues are related to the recent wiki software updates.
Again, thanks for providing this resource.
1 Like
Unfortunately, there’s been a slight hiccup with the site:
As such, it’s the same for everyone at present.
I can confirm they don’t render properly in Firefox on Windows 11. I have no other browsers installed, other than Edge (which I try to not run because it screws up defaults, etc., when it does).
Same problem in Edge in Windows 10.
Yep, I do see the same thing and you might be right with the template being the problem and not transcluding correctly. I’m back from vacation and will hopefully have some time to look at this more now.
It was indeed an extension that parsed those templates better ParserFunctions. I’ve just re-enabled that extension and it seems to have corrected the issue. Thanks for the heads up!
2 Likes