Sometimes starting from scratch is the best option and I think in this case that is a good idea.
It has come up that the documents should be published on blender.org. Is this something that we would actually want? If so I would be willing to help to set that up on a buildbot slave.
Please note that a task has been created for this maybe we should move discussion to https://developer.blender.org/T73140
Hmmm, I have a patch but can’t seem to get it through by following instructions found at wiki. I don’t have the answers for all questions so I get errors from web-pages.
What’s the best way forward?
Another Question:
Is there a visual designer behind blender.org that I should talk to for
qualified input regarding visual identity?
I’d probably start by explaining what the problem is? hard to assist otherwise, if you don’t want to pollute the thread too much you can also ask on chat.
On the other hand - asking in this thread will potentially result into some solution that can be linked to in the future.
@billrey is probably the closest person, I’d guess, though I know the website isn’t his area, I would say he likely has a reasonable grasp of the visual identity of Blender.
I actually have nothing to do with that. Not involved with any branding or website stuff. Check with @pablovazquez perhaps.
Ah, apologies, I thought you would be doing that side of things too.
Hello,
Thank you for your efforts to make the technical documentation more accessible.
Sometimes I have to use Google Translate on such documentation.
Yes, my level in English is average and Translate’s AI sometimes understands better than I do.
I ask him for help when I have doubts,
unfortunately, Translate only recognizes the <code> tag as a different language.
many documentation generators or Javascript colorization libraries use only <pre>.
Documentation of source code with incorrect function names is not necessary, so Translate is of no use.
The solution is really simple. you have to think of surrounding <pre> with <code> in your template generator.
<code><pre> ... </pre></code> for blocks or simply <code>inline_name</code> for names in a text
(note: The only use of <pre> to define a block of code language is a semantic error of the w3c standard.)
Ahh, now I see your dilemma, @jmv.
I wasn’t aware there was a way to suppress the translation like that.
Thanx for the tip.
I will do my best to include such a solution in doxygen if I can verify it.
It also has to pass through doxygen without being messed up.
Cheers!
So, it would appear that the teams are so busy it’s a bit hard to start now.
If you have responsibility for someblender module(s) and have some interest in
doxygen improvements, tag me here and I’l re-appear!
In the mean-time I’l amuse myself with rewriting WM and GHOST in modern C++.
… just for fun maybe I’l add some API documentation for Doxygen to extract …
On my computer that is.
@JonasPrintzen I’m not sure where you get this impression.
I replied to https://developer.blender.org/D6625 - which changes multiple unrelated things - which happened to fail to properly build on my computer - making the patch difficult to properly review.
It’s reasonable that changing the doxygen structure makes minimum necessary changes elsewhere - this patch down-grades the Doxyfile version, removing settings, changes warning & verbosity levels, things which aren’t related to what you’re proposing.
I’ve listed smaller areas you could help with above and am available to spend some time reviewing improvements here.
