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
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.
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.
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.
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).
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.
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).
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!
I think part of it was waiting for a creation of/migration to a RawTherapee github org - I know @Morgan_Hardwood wanted to do some thinking along those lines as far as actual org naming the last time the topic was discussed?
Hopefully Iāll have more time to actually do coding contributions again (as opposed to just popping in here to discuss things) starting sometime in March.
Sorry for the radio silence all. Iāve been pushing hard to do a website migration for my job that is consuming my time at the moment. This is near the top of my personal projects list when I can find some time!
Heh, it happens. Actually this discussion has inspired me to push for an internal wiki at work to potentially get migrated to a similar implementation (git + hugo). For our software teams I think itās a no-brainer, but the whole concept might get sunk by the problem of git being alien to non-software types. Politically I think sharepoint is going to win in the end.
Sharepoint. From the company that just yesterday told me in my wifeās Excel spreadsheet that it was read-only, had to save it as another file name, and I went alooking in the ACLs and NOWHERE FOR ANY USER OR GROUP WAS IT MARKED READ-ONLY!!! AAIIIEEEEEAAAA&%^&^&@$!!!
Going downstairs now to install larger hard drives for our picture repository, in nice, simple, easy-to-understand Unixā¦
Yup. MS has improved greatly over the years (I like VSCode, and WSL2 is a wonderful thing if youāre in a primarily Microsoft shop or are stuck using software that is Windows-only and will likely remain that way for a LONG timeā¦), but Sharepoint is one of their ālegacyā products that I dislike.
Thereās been a slow push towards containerization/linux/etc in my company, but in general thatās happening within engineering and product development, and IT considers that āengineeringās problemā or āwell weāll hand that to our dedicated engineering support team who are vastly understaffedā.
My old employer was a big user of Sharepoint. On my program, however, it was good old SMB that saved the day, network file shares we could see across the time zones.
I channel my son for āmodernā IT vibes. Heās worked for small companies, getting them into the VM/containerization world. His world is all Windows though, Azure and such. He comes to me when he needs Unix stupid pet tricksā¦
Heh. Big pressure to consider Azure DevOps, I have major concerns it might be too āwindows-yā. Thereās some discussion of Github Enterprise which I would not mind. Thereās no way weāll be leaving Atlassian JIRA, but frankly Iām hoping that the rest of our Atlassian infrastructure (originally chosen because āintegrates with JIRAā but honestly JIRA will integrate equally as well with other solutionsā¦) gets replaced with anything else. I have grown to really hate Bitbucket as a git frontend (per-file history UI/UX is garbage for example, cannot check out a pull request without read access to the PR issuerās fork, etc.)
(big red flag for ADO that Microsoft has two almost entirely parallel product lines thereā¦)
